>>>>> On Wed, 16 Nov 1994 04:27:46 -0500,
>>>>> In message <199411160927.KAA04366@euler.cs.kuleuven.ac.be>,
>>>>> Geert Uytterhoeven <Geert.Uytterhoeven@CS.kuleuven.ac.be> wrote:

Geert> - NetBSD seems to be faster, except for small blocks

Probably because Linux wasn't using small blocks at the disk level,
since Linux has no concept of a "raw" disk interface.  I/O always goes
through the buffer cache.  The buffering you were controlling was only
the user level buffering (i.e. how many bytes transferred per
individual read/write call).

With the NetBSD raw disk interface, this buffering also becomes the
write size for the disk (in general).

For Linux, your I/O gets written to the 1K pages, and then 1 or more
pages are written when the buffers are flushed to disk.

Geert> - I used `sync' in between the test commands under NetBSD to invalidate
Geert> the diskcache (seemed to work),

You avoid the NetBSD disk cache when using /dev/rsdxx.

Geert> for Linux `sync' didn't seem to flush read caches, 

Nope, it would be a bad thing if it did that; it would destroy the
usefulness of the disk cache.

Geert> - Running the test with 4K blocks a second time without sync
Geert> under NetBSD didn't matter, while it boosted the Linux read
Geert> performance from 611343 b/s to 1031738 b/s.

Because the data was in the buffer cache for Linux.

Unfortunately, there isn't an easy way to compare the "raw" disk I/O
for Linux and NetBSD that isn't comparing apples and oranges.

One could use the buffer cache (but not the filesystem) by reading
/dev/sdxx under NetBSD and Linux.

I would expect NetBSD/Amiga to have better I/O performance than
Linux/68k currently for two reasons:

 1) We don't have synchronous SCSI yet for Linux/68k.
 2) I suspect that NetBSD does a better job of setting up
    scatter/gather I/O than Linux/68k does.  This may be less of a
    factor once Linux/68k has been upgraded to compatibility with
    Linux/386 v1.1 or v1.2 which contains the I/O "clustering"
    mechanism.

It's too bad Linux/68k doesn't have a "raw" block I/O interface,
though.