JorgeB Posted April 2, 2017 Share Posted April 2, 2017 SMB extra settings take effect after stopping and restarting the array. Quote Link to comment
allischalmersman Posted April 2, 2017 Author Share Posted April 2, 2017 1 minute ago, Frank1940 said: It has been several months (and, in those days, my systems was AMD MB's with Intel NIC cards --which were needed because of other issues) since I was working on a download issue to my PC's that I was playing around with those parameters and I seem to recall that changing some of those Tips and Tweaks NIC 'tunables' would affect those types of errors. That is why I suggested playing with them... Do you by chance know if changes require a reboot? I have been playing with them non stop since your post with no positive results. Quote Link to comment
garycase Posted April 2, 2017 Share Posted April 2, 2017 It's been a long time (sometime last year) since I was having a similar issue, and I don't recall exactly which thread I saw it discussed in; but I remembered I had to change an SMB setting, so I looked at my server and it has the two lines I noted above, which resolved the transfer speeds for me with my Win 10 clients. Hopefully they'll do the same for you Quote Link to comment
garycase Posted April 2, 2017 Share Posted April 2, 2017 3 minutes ago, johnnie.black said: SMB extra settings take effect after stopping and restarting the array. Thanks for confirming that Johnnie. I actually thought you had to reboot, so it's a bit easier than that. Quote Link to comment
allischalmersman Posted April 2, 2017 Author Share Posted April 2, 2017 (edited) 10 minutes ago, Frank1940 said: It has been several months (and, in those days, my systems was AMD MB's with Intel NIC cards --which were needed because of other issues) since I was working on a download issue to my PC's that I was playing around with those parameters and I seem to recall that changing some of those Tips and Tweaks NIC 'tunables' would affect those types of errors. That is why I suggested playing with them... Also, you mention the Intel NIC cards were needed because of other issues? Curious what those were. The reason I stopped using the Realtek 8111E onboard was because of a stuttering issue using my Dune when playing full quality BluRay rips. It was recommended I try an Intel NIC, the Intel NIC seemed to help, but I never did get that problem resolved (kept the intel installed). It occurred immediately after upgrading to V6. Never had an issue with V5. I would like to think my Dune is bad but I haven't been confident enough to drop $300 or more on a new network media device not even sure if it will work. We have since been using Plex which is awesome for mobility, friends, etc. I would eventually like to go back to watching my full BD rips. Edited April 2, 2017 by allischalmersman Quote Link to comment
JorgeB Posted April 2, 2017 Share Posted April 2, 2017 Oh, and you just need to add max protocol = SMB2_02 like it's mentioned in the FAQ, I didn't mention it before since it only appears to affect read speed, but it certainly won't hurt to try. Quote Link to comment
Frank1940 Posted April 2, 2017 Share Posted April 2, 2017 (edited) 1 hour ago, allischalmersman said: Also, you mention the Intel NIC cards were needed because of other issues? Curious what those were. The reason I stopped using the Realtek 8111E onboard was because of a stuttering issue using my Dune when playing full quality BluRay rips. It was recommended I try an Intel NIC, the Intel NIC seemed to help, but I never did get that problem resolved (kept the intel installed). It occurred immediately after upgrading to V6. Never had an issue with V5. I would like to think my Dune is bad but I haven't been confident enough to drop $300 or more on a new network media device not even sure if it will work. We have since been using Plex which is awesome for mobility, friends, etc. I would eventually like to go back to watching my full BD rips. Basically, it was 'stuttering' playback of BluRay ISO's though the Netgear NTV-550 media players. You are right in that the problem started in the early beta stages of version 6. My personal opinion is that LimeTech changed some compiling options to optimize the handling of VM's and Dockers that triggered the issue. As I far as I could tell, it only really affected low-power CPU's (like AMD Semprons) and RealTek NIC chip sets. (That was further verified when I obtain a compiled version of the RealTek Chip Driver for that version of the Linux kernel to replace the default Linux RealTek Drivers. RealTek Linux drivers were a major source of confusion and problems in unRAID for several years for many, many reasons...) I have a feeling that you are seeing the same (or similar) issue with the Dune media player. Edited April 2, 2017 by Frank1940 Quote Link to comment
allischalmersman Posted April 3, 2017 Author Share Posted April 3, 2017 Ok. Well after stopping the array, and enabling direct IO, and restarting to make the SMB changes take effect there are no positive changes. Results are the same. I also ran smbstatus to verify I am now using SMB2 protocol. Thanks for the ideas. Any other ideas / input? I can't believe I could be so unlucky to have a weird unexplainable issue like this. I have no dockers, no VMs, etc. This is a simple NAS. Quote Link to comment
garycase Posted April 3, 2017 Share Posted April 3, 2017 Well, you've eliminated just about every likely cause => the cables; the SMB level; direct IO; etc. I think Frank has the right idea -- you need to determine WHY you're getting so many dropped packets. And that, of course, can be VERY tricky to isolate without an ethernet link analyzer [typically $1500 and up]. Without re-reading the thread, I've forgotten whether or not you've tried alternate topologies -- e.g. eliminating as many switches as possible -- just to be sure this isn't a "squirrely" switch port. Actually the test you noted a few posts back with a different computer connected to the same switch you use for the server should have confirmed this isn't the issue (assuming it was plugged into the same switch port you usually use for the server). Any chance your ethernet goes through a UPS ethernet surge protection port? If so, take it out of the picture and see if that makes any difference. [I don't expect it will; but might be one more thing to try] Quote Link to comment
allischalmersman Posted April 3, 2017 Author Share Posted April 3, 2017 (edited) Well I'll be. Re-enabled the onboard Realtek NIC and BOOM. Saturated gigabit speed! Hard to believe the Intel Pro 1000 cards (3 of them) were my problem since they are so highly regarded. Must be some kind of compatibility issue with my motherboard / cpu? Also, zero dropped packets so far. Thanks for all that helped @garycase @johnnie.black @Frank1940 @BRiT Guess I will figure out if the stuttering issue returns with use of the Realtek if and when I purchase a newer media streamer. Since the Intel didnt actually fix that problem maybe I'll be fine. Edited April 3, 2017 by allischalmersman Quote Link to comment
garycase Posted April 3, 2017 Share Posted April 3, 2017 Glad you figured it out. I'm also surprised that the very-well regarded Intel cards were the culprit. Must be a "noisy" PCI bus or some electrical noise that interfered with those card and resulted in the dropped packets -- which were almost certainly the reason for the much slower rates. In any event, all seems just fine now Quote Link to comment
allischalmersman Posted April 3, 2017 Author Share Posted April 3, 2017 Glad you figured it out. I'm also surprised that the very-well regarded Intel cards were the culprit. Must be a "noisy" PCI bus or some electrical noise that interfered with those card and resulted in the dropped packets -- which were almost certainly the reason for the much slower rates. In any event, all seems just fine now Yea. I almost wish I had tried a difference PCI port. Thats one thing I hadn't done yet. Tower is using a Gold certified Seasonic power supply and is plugged into a APC Smart UPS so I would hope the power quality is good. I could bring a ln o-scope home from work and tinker. But probably wont lol. I'm happy for now!No trees were harmed in the sending of this message, however, a significant number of electrons were terribly inconvenienced. Quote Link to comment
garycase Posted April 3, 2017 Share Posted April 3, 2017 Agree ... it's be interesting to know just what the underlying cause was; but there IS a limit on how much time it's worth spending to isolate it => especially since it's resolved Quote Link to comment
Frank1940 Posted April 3, 2017 Share Posted April 3, 2017 7 hours ago, garycase said: Glad you figured it out. I'm also surprised that the very-well regarded Intel cards were the culprit. Must be a "noisy" PCI bus or some electrical noise that interfered with those card and resulted in the dropped packets -- which were almost certainly the reason for the much slower rates. In any event, all seems just fine now This may be a bit of 'noise'. I had dropped received packets with both of the Intel Network cards that I had in both of my AMD Sempron servers. I did a lot of research (both Google and observational) into this problem and found two things. First, most of the time dropped packets are 'harmless'. UNLESS, there is another identifiable problem (and, in this case, the OP had one)! Second, what I found was that I got most of mine when I was playing BluRay ISO's with the Netgear NTV media players. What I surmised was happening was a two fold effect. (1) the Netgear NTV would flood the server with for multiple requests for the next block of data (these media players have 100Mb Ethernet ports) to assure that NTV receive bluffer never be emptied! (Think about it, the max data for a BluRAY ISO is about 50% of the total bandwidth of the 100Mbps bandwidth.) (2) The Intel card has a processor chip on it and that chip was recognizing that it was receiving duplicate data requests and was dropping them rather than forwarding them to the CPU which would require the MB to take some sort of action with those requests. (That is one of the reasons that the cards are more expensive than many other Ethernet cards is because they don't use as many CPU cycles to handle the handshaking and data protocol. This ability was a big performance boast back in the days when CPU's didn't have the horsepower that they have today! For whatever reason in my case, the Linux driver for the RealTek chip combined with the Sempron CPU were simply unable to handle this particular combination of events and the stuttering resulted. This was why I went to the Intel card in the first place. The RealTek problem must have been limited to a small set of hardware configurations as I have only heard of two or three other folks with it.) Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.