On Sunday 30 November 2008 11:50:18 Daniel Iliev wrote: > > > real 0m26.747s > > > user 0m2.110s > > > sys 0m1.450s > > > localhost test # time cat test2 > /dev/null > > > > > > real 0m29.825s > > > user 0m1.780s > > > sys 0m1.690s > > > > This is not a test unfortunately. You did one run on one file and one > > run on another file. We do not know what else the machine was doing > > at that time, and that unknown is a considerable one. > > This result is from the last of three repetitions. Its values were in > the middle (not average). The deviations were in the range 1 to 1.5 > seconds. Every time reading the more fragmented was slower.
That's a HUGE deviation, I assume it's real time. What's the difference in user and sys time? Those are much more important here. > The system was idle in level 3, no X running. I used iostat before > the tests and it registered several tens of KBs written for 1 min before > the test. Compared to the size of the test files and the speed of the > disk it is insignificant. You didn't remove the effect of buffers and caches. The only way I know of to test this correctly is to reboot the machine after every run, start no services and run the test with a cold cache. Otherwise you don't really know what you are measuring. > > Repeat your test eliminating this factor. Preferably, remount the > > filesystems after each run and repeat 1000 times. Then analyze the > > statistical distribution of your results. This should eliminate most > > random factors and give a more realistic real-world view. > > I'm not willing to waste time for 1000 repetitions, but why don't you > do the test yourself just a couple of times and see if there will be a > case when the more fragmented file gets read faster? You are the one making them claims! You do the test! > Actually my results are a little lower than what I expected but enough > for me to say that fragmentation matters. At least until proved > otherwise. Fragmentation leads to seeks. The average seek time on > modern disks is several milliseconds. Yes, there are algorithms > reordering the I/O requests to minimize the seek penalty, but still > seeks are there and they hurt performance. Buffers and cache? You have two files of 1.2G each. I have more free RAM than that for buffers and cache easily 90% of the time my notebook is on. -- alan dot mckinnon at gmail dot com
