User Shares “cost” is >20% transfer rate drop!


17 posts in this topic Last Reply

Recommended Posts

Hi,

 

After running multiple tests using SSDs on both client and server (7+1 disk), I can confirm that transfers to/from user Shares are more than 20% slower comparing to transfers to/from directly shared disks. All that on SMB network.

 

I think this is inherited issue from previous versions. User shares is a very important feature, but loosing >20% of transfer rate is pretty bad. Is there any chance to have that fixed in release?

 

Cheers.

 

 

Test setup


Server

  • unRAID - Server Pro, Version 5.0-rc5
  • Processor - Intel® AtomTM CPU N450 @ 1.66GHz
  • Cache - L1 = 24 kB  L2 = 512 kB 
  • Memory - 1 GB - DIMM0 = 667 MHz
  • SSD - Verbatim 2SSD64 64GB * 8

 

Network

  • Speed - 1000Mb/s Full Duplex
  • Switch - Cisco SLM224P

 

Client

  • OS - Windows7
  • Processor - Intel Core I7 @3.40 GHz
  • Memory - 16 GB
  • SSD - M4-CT256M4SSD2

 

Testing method

  • Software - NAS performance tester (http://www.808.dk/?code-csharp-nas-performance)
  • File size - 4000 MB
  • Loops -10
  • Network mapped drive "Y" - directly shared empty SSD "drive 5"
  • Network mapped drive "Z" - user share "test" with single included "drive 5" (same as directly shared)
  • No cash drive

 

Link to post
  • 2 weeks later...

P13, how did you test this? I'd like to try and do some tests myself. Maybe switching to disk shares would increase performance? I don't use a cache drive or anything so I'm not sure my performance would increase anyway.

 

Link to post

I think  this is an issue with low end processors. User  shares result in very high processor load when written to.

This has gotten slightly better with the latest release candidates,  though but performance is still way below of writing directly to a disk share.

Link to post

i'm experiencing the same issue with a Supermicro X7SPA-HF-D525, with an 1.8 Ghz Atom cpu. Writing to a user share is significantly slower then to a shared disk. Also, when using an SSD cache drive, writing to a cached user share is almost 50% slower compared to witing to the ssd directly (on my system, 80MB/s to the ssd/cache, 50MB/s to a cached user share.

 

I have ordered a X9SCM / i3 2120T to replace the X7SPA... i let you know what the outcome is.

Link to post

This is just due to the fact there is an additional layer to the IO operations.

 

Even my 4Ghz Quad Phenom II has a not insignificant drop in performance via accessing the disk directly.

 

As such, I only now write to the drive, not the share when transferring files.

Link to post

I have ordered a X9SCM / i3 2120T to replace the X7SPA... i let you know what the outcome is.

The above combo has no problem at all. Copy speeds to a cached disk directly is as fast as to a cached user share, at about 110MB/s. Writing to a non cached user share is about 40MB/s. Choose your CPU's wisely, gents... not everything will work as advertised.

Link to post

I suspect it's important with the lower powered processors to set processor affinity for IO code. Disk and network should probably each stick with a single core. This is speculation, but I'm thinking the effects of caches being invalidated could increase with user share layers, resulting in more work/less results. My smallest box is now an i3. Would any e350/450/Atom users care to test?

Link to post

Updated initial post with test method.

 

Also, some people are saying that this is low-end CPU issue. I disagree. First of all, I didn't notice higher CPU load when accessing to user shares comparing to disk shares. Secondly, my CPU was not even 100% loaded on either share access. I believe, problem lies somewhere else...

 

Besides, unRAID is advertised as "low hardware requirement". If to have same performance on user shares as on directly shared drives one needs a XEON E7 or something alike, this is not good for "home" server. Home server supposes to be low power, noiseless (read passive cooling), and that means low power/performance CPU.

 

As it was said:

... it flies in the face of years of unRAID recommendations.

 

I really wish (hope) to hear something from developer...

Link to post

Also, some people are saying that this is low-end CPU issue. I disagree. First of all, I didn't notice higher CPU load when accessing to user shares comparing to disk shares. Secondly, my CPU was not even 100% loaded on either share access. I believe, problem lies somewhere else...

Could be... but the moment i replaced my X7SPA/Atom with an X9SCM/i3 board, all problems with slow and erratic speeds dissapeared... That should tell you something.

Link to post

It could be a simple matter of tuning. While the CPU may be idle the chipset could be experiencing a train wreck of interrupts and memory transfers from a non-optimal configuration. Yes, this is still speculation. I apologize for not even trying multiple configs on my i3. Too much else fighting for time right now.

Link to post

Updated initial post with test method.

 

Also, some people are saying that this is low-end CPU issue. I disagree. First of all, I didn't notice higher CPU load when accessing to user shares comparing to disk shares. Secondly, my CPU was not even 100% loaded on either share access. I believe, problem lies somewhere else...

 

When you say access, is that read or write?

Link to post

When you say access, is that read or write?

 

In both cases, and it even seems that load is less when accessing user share. I know its weird, but that is what i see... maybe better CPU load tool needed.

Link to post
  • 1 month later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.