With write speeds in the 30's-40's (without cache drive active), I've been curious where the bottleneck is.  IE is there something you can do to make it faster without the use of a cache drive.  With a cache drive I'm getting reasonable speeds from the mid 50's to mid 60's.

 

unMENU has a "Top Services" display under the "System Info" section.  Watching it during a write During a write, my processor never gets above 50% total usage.

 

Question 1 - Does unRAID make use of dual / triple / quad processors?  Does usage in the high 40's and never above 50% mean its about tapping out one core, but not using the 2nd?  (I have a Athalon II x2 3.0)

 

The top two processes during a write are one called "smbd" and one called "unraidd."  Everything else on the list is minimal usage or 0 usage.  smbd is using more than twice the processor capacity that unraidd is.  The processor usage runs at a low of around 25 up to a peak in the upper 40's (total for everything).  "smbd" is always around twice "unraidd"  

 

Question 2 - Am I assuming correctly that unraidd is the function running the parity calculation and smbd is managing the overhead associated with smb shares?  I've always heard smb had a lot of overhead, but the fact that it takes more effort to handle sharing, than it does to crunch parity was a little surprising (if I have that right).

 

Question 3 - If the above two are correct, and smb is using so much load on the processor and it can't access the 2nd core than would NFS copy faster?  I think the overhead is lower correct?  I would have to get a Win7 driver for NFS though.

 

I also notice it runs pretty fast till it fills the 4GB RAM then it slows down.  For the rest of the write time, the RAM is nearly maxed.  This may shoot a hole in my SMB theory as it is able to write to the memory faster than i can the drive.

 

My 2nd reaons for asking about this is I used to have issues gettign to 8 Mb / Sec on my Dune player when I would stream from Win 7, unless I turned on what the Dune calls "Fast SMB." It does fine with unRAID though, and I was pretty convinced it was trying to stream SMB that caused the issue.

With write speeds in the 30's-40's (without cache drive active), I've been curious where the bottleneck is.  IE is there something you can do to make it faster without the use of a cache drive.  With a cache drive I'm getting reasonable speeds from the mid 50's to mid 60's.

 

unMENU has a "Top Services" display under the "System Info" section.  Watching it during a write During a write, my processor never gets above 50% total usage.

 

Question 1 - Does unRAID make use of dual / triple / quad processors?  Does usage in the high 40's and never above 50% mean its about tapping out one core, but not using the 2nd?  (I have a Athalon II x2 3.0)

Yes, it uses all cores. Processes get allocated to the most idle core. No, 50% could be split among all cores but a single process can only operate on a single core at a time.

 

The top two processes during a write are one called "smbd" and one called "unraidd."  Everything else on the list is minimal usage or 0 usage.  smbd is using more than twice the processor capacity that unraidd is.  The processor usage runs at a low of around 25 up to a peak in the upper 40's (total for everything).  "smbd" is always around twice "unraidd"  

This relation makes sense. unraidd and smbd are servicing requests and smbd uses double the resources as unraidd. They are most likely running on different cores.

 

Question 2 - Am I assuming correctly that unraidd is the function running the parity calculation and smbd is managing the overhead associated with smb shares?  I've always heard smb had a lot of overhead, but the fact that it takes more effort to handle sharing, than it does to crunch parity was a little surprising (if I have that right).

Yes. (Close enough.) Parity is a trivial operation.

Question 3 - If the above two are correct, and smb is using so much load on the processor and it can't access the 2nd core than would NFS copy faster?  I think the overhead is lower correct?  I would have to get a Win7 driver for NFS though.

All cores are used. NFS may be faster.

I also notice it runs pretty fast till it fills the 4GB RAM then it slows down.  For the rest of the write time, the RAM is nearly maxed.  This may shoot a hole in my SMB theory as it is able to write to the memory faster than i can the drive.

Linux uses all available memory as disk cache; however, the disk cache has the lowest priority for RAM allocation. I.e., the disk cache allocation appears as available for any other process.

 

My 2nd reaons for asking about this is I used to have issues gettign to 8 Mb / Sec on my Dune player when I would stream from Win 7, unless I turned on what the Dune calls "Fast SMB." It does fine with unRAID though, and I was pretty convinced it was trying to stream SMB that caused the issue.

Only Macs have demonstrated performance issues with SMB. Although Lion may fix this.

With write speeds in the 30's-40's (without cache drive active), I've been curious where the bottleneck is.

 

The bottleneck is the fact that you have to read and then rewrite the same sector under uRAID's parity scheme.

 

For your drive's specs, calculate the time to read 100MB, and add the time to write 100MB.  Divide that number into 100MB.  The result is the theoretical maximum unRAID write speed for that drive.  Do the same for the parity drive.

 

Your theoretical max will be the slower of the two.  A well-tuned system might get to over 90% of that theoretical max, and you will have to be satisfied with that.

 

 

Drive A reads at 110 MB/sec and writes at 85MB/sec.  That gives you 0.9091 + 1.1765 = 2.0856 sec ==> 48MB/sec.

It's actually a little worse. See here for a more complete analysis: http://lime-technology.com/forum/index.php?topic=9989.0

It's actually a little worse.

 

Certainly... the calculation I posted gives you an ideal theoretical maximum throughput.  It ignores all the other issues that will always make the real world performance slower than the ideal theoretical max.

 

My point was that if your ideal theoretical max is 48MB/sec, and you are getting 44MB/sec in actual usage, you don't have much room for improvement from a practical standpoint.

Yes.

 

Engineering Trilemma: Speed, size, cost. Choose any 2. unRAID chose size and cost.

With write speeds in the 30's-40's (without cache drive active), I've been curious where the bottleneck is.  IE is there something you can do to make it faster without the use of a cache drive.  With a cache drive I'm getting reasonable speeds from the mid 50's to mid 60's.

 

unMENU has a "Top Services" display under the "System Info" section.  Watching it during a write During a write, my processor never gets above 50% total usage.

 

Question 1 - Does unRAID make use of dual / triple / quad processors?  Does usage in the high 40's and never above 50% mean its about tapping out one core, but not using the 2nd?  (I have a Athalon II x2 3.0)

 

The top two processes during a write are one called "smbd" and one called "unraidd."  Everything else on the list is minimal usage or 0 usage.  smbd is using more than twice the processor capacity that unraidd is.  The processor usage runs at a low of around 25 up to a peak in the upper 40's (total for everything).  "smbd" is always around twice "unraidd"  

 

Question 2 - Am I assuming correctly that unraidd is the function running the parity calculation and smbd is managing the overhead associated with smb shares?  I've always heard smb had a lot of overhead, but the fact that it takes more effort to handle sharing, than it does to crunch parity was a little surprising (if I have that right).

 

Question 3 - If the above two are correct, and smb is using so much load on the processor and it can't access the 2nd core than would NFS copy faster?  I think the overhead is lower correct?  I would have to get a Win7 driver for NFS though.

 

I also notice it runs pretty fast till it fills the 4GB RAM then it slows down.  For the rest of the write time, the RAM is nearly maxed.  This may shoot a hole in my SMB theory as it is able to write to the memory faster than i can the drive.

 

My 2nd reaons for asking about this is I used to have issues gettign to 8 Mb / Sec on my Dune player when I would stream from Win 7, unless I turned on what the Dune calls "Fast SMB." It does fine with unRAID though, and I was pretty convinced it was trying to stream SMB that caused the issue.

 

unRAID isn't meant for speed. Not at all. Even in one of the FAQ's it indicates if you are worried about speed then unRAID may not be necessary for you. You are already luck to get those write speeds without a cache drive. I have not opted to use a cache drive since write speeds of 30 or 40 are good enough for what I'm using the server for.

 

 

Sorry, after posting this originally I have been really tied up for a while and wasn't able to come back and read this till late last night. 

 

Thanks to everyone who responded, it was informative.  I did know I would not get full write speeds before going with unRAID and am not displeased.  I just wanted to see if there was anything I could do to speed it up, but better understand the source of the limitations now.

 

Still is a great solution for my needs.

 

Thanks.