Quote:
Originally Posted by thiggins
I don't know how Windows calculates its throughput. Vista contains numerous file copy optimizations. Mark Russinovich's blog post is probably the best reference for details.
You can look at the iozone data for different record sizes and see if that supports your theory. Our NAS Charts report only the 64 KB file size, which is what Windows used to use.
If you manually calculate the transfer rate by doing a timed drag-and-drop, does it correlate with the speed that Windows reports?
I'll check with Don Capps and see what he has to say about Windows' reported file copy Stats. |
I tested iozone using sizes from 16k to 16MB and looked at the trace data provided by the Process Manager program that was in the article you linked to. Along with this I did a normal file copy and used Process Manger to trace what happened.
According to the trace data my drag and drop file copies are using a 32k request size and are doing multiple request to the network sequentially to my Win XP server. Which is keeping the network pipe full. Once the data arrives from the network it is written directly from memory to the disk sequentially in 32k blocks.
The trace data for reads shows iozone is requesting the size I set, but directly from memory. The system looks to be reading ahead of these requests but not at a quick enough rate. So what happens is the system requests the data from the network then iozone requests the data but the data has not actually arrived from the network. This means iozone has to wait until the data arrives before it will issue another read request. So multiple requests are not being made at a time and in turn the network pipe is not being kept full. My results testing with 8MB request sizes show much faster reads but much slower writes. I believe the faster reads are because the network pipe can stay full. I will explain the slow writes in a bit.
It looks like when iozone writes it writes directly to memory using the request size set. From what I can tell the whole file is written to memory if possible, then the file is flushed to disk or in this case the network. When this happens the system sequentially writes the data to the network in 1 MB blocks as fast as possible. I think the write results shown by iozone are only measuring how long it takes to write the file to memory that is why they are so high. I believe this can be fixed by using the -e switch on the command line. When using request sizes of larger than 256k with iozone for writes, Vista breaks them down into 256k blocks and writes them directly to the network. I believe this extra processing is what was causing my slow write speeds using larger than 256k record sizes.
I did test with 16MB request sizes and found that reads were much slower than with 8MB. This larger size should help keep the network pipe full but when I looked at the Process Monitor trace I found that the requests were being broken down into 64k request sizes to the network. Whereas the 8 MB requests were being broken down into two 4MB requests. On a side note I did try some of the larger sizes with iozone running on a Win XP Pro machine and did not see any increase in read speed.
This is of course just my conclusions based upon my own testing and understanding of how this stuff works. I gladly welcome any feedback.
00Roush
Linear Mode
