From: root@hip-hop.suvl.ca.us (Remco Treffkorn) Subject: Re: SCSI Performance (Yet Again) Date: Sat, 21 Aug 1993 16:47:58 GMT
soup@SonOSam.execnet.com (John R. Campbell) writes:
: I keep seeing bitching and moaning about "poor SCSI performance" during
: reads with all kinds of hand waving and inconsistent numbers.
Yes, the numbers are not the same as mine. I think theirs must be
inconsistent ;-)
:
: Please- Remember something called a Buffer Cache? If you've got a 16MB
: box, up to 6MB can be (and, if no programs take up the space, will be)
: the Disk's Buffer cache.
Isn't that the thing that makes writes lightning fast as compared to raw
writes ?-)
But without slowing down reads?
:
: Sure, it can take < 30 seconds to write a big 8MB file and 45-50 seconds
: to read it, since the write() system call merely delivers it to the buffer
: cache; the read() call may have to wait for the disk to come around before
: it returns to the user. If you watch the little disk intensity light and
: time it, the numbers should be about even.
If a memory move from user space to kernel space and queing it in the
buffer cache takes 30 seconds without the actual write taking place then
I would consider that a major slowdown. I might agree with your reasoning
regarding reads taking longer then writes *but* only if the program doing
the write does not do a (f)sync. There is a compiletime option in iozone
to do that. If the (f)sync is properly done reads should *not* take longer
than writes.
:
: Linux's performance is EXTREMELY respectable against $CO. I'm not even
: counting Bang for the Buck, either.
I could not agree more! It is that way because people were not happy with
the prformance of the early drivers and bitched about it. Thanks to all
the developers who would listen and finding ways to tweak performance!
:
: Remember that the buffer cache can be VERY BIG on a Linux system and that
: this will screw up any attempt to measure performance on a disk drive.
Agreed, but normally the existence of a cache gives you numbers that are
an order of magnitude too high. It makes things *look* better than they
actually are. That is their purpose. I would find cache code that makes
things look worse than the raw device pretty useless, unless it does other
things that are worth the penalty.
:
: Of course, if we had raw drives, we'd be able to get better numbers...
Maybe so, but that is not how it should be.
:
: --
: John R. Campbell soup@sonosam.execnet.com
:
Listen, the point here is simply that some people are wondering if the
SCSI performance is all the way up there *or* if it could be improved.
Natually they are comparing notes. The problem is only that nobody
can agree on the correct way to measure performance. Iozone is certainly
not perfect, but gives you a relative measure if compiled correctly.
Again, nobody (I hope!-) is whining. I am subjectively happy with the
disk performance, but after having seen some people with IDE presenting
numbers that beat the sh*t out of my setup with an Adaptec SCSI controller
I am certainly motivated to look into the matter a bit further.
I think your understanding of how the buffer cache affects (should affect)
performance is just wrong. But then, maybe things have changed since I left
the university ;-)
Cheers
Remco remco@hip-hop.suvl.ca.us <<<== use this one for replies