• Content count

  • Joined

  • Last visited

  • Days Won


garycase last won the day on March 8

garycase had the most liked content!

Community Reputation

13 Good

About garycase

  • Rank
    Advanced Member
  • Birthday 12/22/47


  • Gender
  1. My D525 system is still just fine for my needs -- a basic NAS. Not likely to change it out anytime soon. The one thing I HAVE done is leave it on v5, which performs FAR better than v6 on that hardware. As landS knows, I tried v6, but after a bit of experimentation I simply decided the much longer parity checks and notably slower read speeds simply weren't worth the nicer GUI.
  2. 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
  3. 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
  4. 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]
  5. Clearly something is very wrong here. I'd reformat your flash drive and reload the latest download. Be sure to save your key file and to note your disk assignments before doing that. You might also try a different USB port on your computer.
  6. Thanks for confirming that Johnnie. I actually thought you had to reboot, so it's a bit easier than that.
  7. 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
  8. I believe that's correct. I don't think the protocol actually changes until a reboot -- but as I noted above I'm not certain of that. But I do know that some folks have experienced slower transfers when using SMB v3 (I think this is primarily with Windows 10 clients). I'd reboot after your parity check and see if anything changes.
  9. ... Not sure, but I think you have to reboot the server for that change to take effect.
  10. Try adding these lines to the "extra configuration" section for SMB (on the Settings page) max protocol = SMB2_02 allocation roundup size = 4096
  11. I have noted that syncs tend to be faster than checks -- I suspect it's because there's less rotational latency delay since the writes to the parity drive can be asynchronous r.e. the other drives. And in this case, the last 5TB of the process only involves 8TB drives. It's not likely a "clearing" of the drive, since a parity drive wouldn't be cleared.
  12. What SMB version are you using?
  13. Not surprising => as I noted above, they've significantly reduced the power consumption ... and power draw directly correlates to heat. The helium-filled design also helps. In fact, ALL of WD's new data-center oriented drives are going to be helium filled in the future.
  14. If the cables were faulty (a discontinuous pair) I'd expect the transfers to revert to 100Mb speed (e.g. 11MB/s) -- transfers in the range you're seeing aren't likely due to bad cables. What is the SOURCE of the MKV's? Are you certain it can "feed" the data at higher rates? e.g. have you tried copying them to another PC ... and do you get 100MB+ rates with those copies? If so, I suspect your issue is a networking parameter issue. But first, confirm you get the higher speeds when copying to a different PC.
  15. NO => the spinners can easily exceed Gb speeds for writes. This may be a network issue; or it's possible the shares aren't configured to be cached -- in which case the writes are directly to the array ... in which case 40-50 MB/s is a reasonable speed (actually it's fairly good). If switching to reconstruct write mode (aka "turbo write") speeds things up, then that's indeed the problem. allischalmersman => Are you sure the shares are configured to use the cache? They have to be configured on a share-by-share basis.
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.