Network File Copy Performance.

[Moezilla]

This is a continuation of a discussion in another thread. Link

Basically the reason I set the request size to 32k on network drives is because it has given me the best performance. Vista also uses this size when copying files from SMB1.0 computers. SMB1.0 is limited to a max of 60k reads across the network but if I use that size reads and writes will be odd sized. I believe this odd size causes performance to suffer due to the read actually being broken up into 32k, 16k, 8k or 4k reads by the system. I can explain more in depth if you would like. Also currently all reads are set to unbuffered no matter the drive type. Writes are set to be buffered except when transferring between two local disks. I have tried to use unbuffered writes when writing to a local drive and reading from a network drive but performance has always been worse. Still working on it. (and still learning) Anyway... feel free to try any sizes you want.

I got myself caught up a bit on XP/Vista and SMB1/SMB2 by reading these threads (great stuff):
How To Build a Really Fast NAS - Part 6: The Vista (SP1) Difference
Building High Performance NAS / HTPC

00Roush, based on your quote above and what I read in the links, if I set the request size to 128K for a SMB1.0 transfer the requests will most likely be broken down into multiple 32K or 64K requests. So I won't actually get true 128K blocks which might help with my apparent HDD performance problem. I think I would only benefit from changing the request size if I had a Vista SP1 client (per one of your posts in the linked threads) as it's kernel can handle the larger block sizes. Am I getting this right or have I got mixed up?

My head is spinning and I think it might be from beating my head against XP32. I think I'll go back to basics and try and find another client machine with a fast hdd setup and Vista SP1.

For your information, here are the results I got with test2.exe (a modest improvement with a 128K request size but nowhere near the expected 70-75MB/s indicated in the ATTO benchmark):

[Conclusion]
If my understanding of how files are transferred in my setup is correct, I definitely think I'm up against two interconnected issues:
1. My HDD and/or I/O controller are not happy with writing buffered 32K/64K chunks.
2. Using an XP client in a SMB1.0 transfer is going to limit you to 32K/64K chunks.

Thanks for all your help 00Roush, and congratulations on your program! I think it definitely improves "push" performance and will probably improve "pull" performance on other systems.

Any thoughts on the above?

Moezilla

[[[EDIT]: Based on this post Link I enabled the LargeSystemCache registry setting and these are the results:

Seems that setting is important and in conjunction with 00Roush's program I can now get speeds very close to the maximum the drive can produce.
]]

 

[00Roush]

I had a whole big reply for you but I accidentally closed by browser and lost it. Had more information about how the request sizes work, SMB1.0, XP, and Vista.

Hell ya... Now that is the performance I am looking for. The interesting thing is that usually the LargeSystemCache setting is used to increase performance on the server not the client. Either way I will keep that in mind when testing. Glad to see you got it working as it should. So the real question is how does it compare to the standard drag and drop copies now that the drive is performing as expected.

Thanks,
00Roush

 

[00Roush]

I tested out the LargeSystemCache setting on one of the Win XP SP3 computers I have here at home and found it does change performance with my program. My guess is it has something to do with me using overlapped (asynchronous) IO. Windows XP has support for it but it was originally designed to be more synchronous. I believe this setting allows for much more memory to be used for the file cache instead of just for programs.

FYI It might be a better idea to change to LargeSystemCache by using the method shown in Post #8 of this thread... http://forums.smallnetbuilder.com/showthread.php?t=736 That is instead of changing registry settings.

00Roush

 

[Moezilla]

I had a whole big reply for you but I accidentally closed by browser and lost it.

That sucks. Really makes you want to kick something.

FYI It might be a better idea to change to LargeSystemCache by using the method shown in Post #8 of this thread...

I used ProcMon to monitor any changes to the system when trying the method you referenced and it only seems to effect that single registry setting. The CPL -> System -> Advanced method is definitely more user-friendly and probably quicker than manually editing the registry. A couple of .reg files would be even quicker.

So the real question is how does it compare to the standard drag and drop copies now that the drive is performing as expected.

ProcMon was useful here again with a filter added to exclude all events except those referencing the path I was copying to. It was easy enough to spot the beginning and end of the copy process and get a reasonably accurate time. Also the request sizes were visible and I could see (as you pointed out) that the drag-and-drop copy was limited to 60K lengths and would sometimes request some strangely sized chunks.

LSC enabled - Simple drag-and-drop copy: 44.90MB/s (avg of 3 700MB files)
LSC enabled - test2@32K copy: 65.67MB/s (avg of 3 700MB files)

Avg. Improvement using test2: 20.77MB/s or 46.26%!
Worst DnD copy to Best test2 performance: 27.2MB/s or 60.58%!!

Very promising results 00Roush!

 

[00Roush]

Excellent! Nice summary there... up to 60% faster!

00Roush

 

[Moezilla]

Possibly more depending on the part of the disk being read/written.

Any other tests you would like me to do?

 

[00Roush]

Well now that you mention it... Could you take a look at your network throughput while you are copying a file from your server? Basically I am wondering if it is erratic or if the flow is fairly consistent.

Constant...

Or a bit erratic

00Roush

 

[Moezilla]

Here are two quick and dirty tests. The first image shows a 700MB file being copied by native drag-n-drop, totalcopy and then test2. TotalCopy is an old program I had floating around on my pc which claims to speed up the copying process. The second image shows a test with a 3195MB file. The direction of all copy operations is NAS -> XPSP3.

700MB

3195MB

 

[00Roush]

Thanks. Haven't spent much time on my program this last week but I appreciate the information.

00Roush