I think since you have sequential read on, you getting a major advantage from the read-ahead algorithm on the filer. I would also suspect, if you just wrote the file, the entire file could be in the client's cache (unmount and remount to clear that) and a major portion could be in the filers cache (make the working set large enough to use more than system memory)
--tmac
On 9/22/06, Willeke, Jochen Jochen.Willeke@wincor-nixdorf.com wrote:
Hi folks,
i am still thinking about some figures which help me considering different fileservers. After doing some research i think one point is the response time given by the system.
I did a lot of testing with sio and but the results i got are some kind of strange.
A test with SIO e.g. brings following result:
./sio_ntap_linux 100 0 8k 100m 10 1 /mnt/test15 Version: 3.00
SIO_NTAP: Inputs Read %: 100 Random %: 0 Block Size: 8192 File Size: 104857600 Secs: 10 Threads: 1 File(s): /mnt/test15 Outputs IOPS: 114578 KB/s: 916626 IOs: 1145782 Terminating threads ...Killed
First there are the KB/S. Much to fast even for a 1Gbit network. And the second is the response time. I calculated the following:
1s / 114578 (IOPS) = 0,00872 ms (response time)
This cannot be true at all :-) Does SIO read the same block all the time (due to 0%random read), or do i have any kind of mistake in my test?!?
Perhaps someone can help.
Best Regards and a nice weekend
Jochen
--