Date: Sun, 14 Sep 1997 22:49:07 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: tm@blom.co.id Cc: toor@dyson.iquest.net, current@FreeBSD.ORG Subject: Re: FYI: Interesting IDE-Ultra/33 results Message-ID: <199709150349.WAA00530@dyson.iquest.net> In-Reply-To: <H00001440015d830@MHS> from "tm@blom.co.id" at "Sep 15, 97 09:53:05 am"
next in thread | previous in thread | raw e-mail | index | archive | help
tm@blom.co.id said:
>
> > 64 512 10475529 24612993
> > 64 1024 10412041 39584952
> > 64 2048 10250518 56886984
> > 64 4096 10361802 68719476
> > 64 8192 10299681 78090314
> > 64 16384 10336864 85048857
> > 64 32768 10238301 88556026
> > 64 65536 10324440 89478485
> > 128 512 10141599 10494727
> > 128 1024 10330648 10494727
> > 128 2048 10268899 10481921
> > 128 4096 10207884 10559231
> > 128 8192 10165603 10552745
> > 128 16384 10159591 10559231
> > 128 32768 10129639 10552745
> > 128 65536 10189720 10598315
>
> How much memory have you got in this machine? Or rather,
> what is the size of the filesystem cache? Numbers like
> 89MB/sec reads only tells me that you are testing FreeBSD
> filesystem cache performance rather than disk speed.
>
That is expected, of course, but once the cache is overrun,
you can see the actual read performance through the cache.
The FreeBSD buffer cache size is almost totally dynamic,
and is optimized in such a way that there are few odd
performance degrading effects (like system becoming very
sluggish during only one or two concurrent write operations.)
>
> I've never studied what FreeBSD does write (and I don't
> have any FreeBSD systems available at the moment to study it
> on). How aggressively are they cached?
>
The FreeBSD buffer cache is write through, with some write
gathering also. The system tries to gather 64K chunks to
write (and is successful much of the time.) There is an
-async mount option that loosens the write scheduling,
but not quite to the level of Linux.
If you look at the 128MB measurements above, you can see that
the system actually starts doing reads somewhere between 64MB
and 128MB. The cool thing is that I am *really* getting
10MB/sec on an IDE drive!!! The buffer cache performance
issues are pretty well understood by the intended audience.
(I am running with a little less than 128MB of RAM, FYI.)
Not only does the drive measure fast, but it actually seems
very fast in actual use. I am now running with 6 EIDE (and
1 SCSI, 2 SCSI CDROM) drives, all PCI BUS interfaced. I think
that I will be adding the new support for all of this stuff
into the tree right after the middle of the week.
Here is another interesting performance result:
Command overhead is 188 usec (time_4096 = 317, time_8192 = 446)
transfer speed is 3.17146e+07 bytes/sec
^^^^^^^^^^^ Really Ultra/33 rates...
It shows that the drive buffer/application transfer rate is
31.7MBytes/sec. Not too awful bad. It would be very interesting
now to get one of those really cool Deskstar-5 drives. Those
are supposed to be even better.
For those who might try to blow off the transfer rate issue,
remember that slow transfers can add to the latency of a I/O
transfer request. The faster the transfer rate from the drive, the
shorter the channel will be busy, and the quicker the total
response time can be. As I commented on earlier though, my
(limited) experience has shown that Ultra-33 is very sensitive
to drive cable length, and once the driver backed off from Ultra-33
to a more sane PIO mode, the errors went away. With the shorter
cable, I have not had any errors since.
--
John
dyson@freebsd.org
jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709150349.WAA00530>