🚀 go-pugleaf

In article <1992Aug15.032753.15794@shaman.com> jiro@shaman.com (Jiro  
Nakamura) writes:
> My own tests using SCSI SpeedGun which access the "sg" SCSI generic  
driver  
> directly gives some of the following numbers.

You are using the wrong driver. Your tests are irrelevent to the speed of  
the SCSI disk driver (the sd driver) since you are benchmarking a  
different driver.

> Note that I am using the  
> SCSI read command directly at the driver level, avoiding the caching  
> problems noted by other posters.

Note that using the "read" menu command from within the /etc/disk program  
supplied by NeXT uses the same mechanism with the sd driver. Without being  
an OEM/VAR, waiting 4 months, or paying Jiro a nickel, you can do the same  
thing, and with the right driver to boot!
 
> Disk throughput was computed by reading 5000 blocks from block 0 with a  
10  
> block incremement on each read.

This "benchmark" would be irrelevent even if used with the correct driver.  
Notice that it does reads in 10 block chunks. Because some of the disks  
use 512 byte blocks and others use 1024 byte blocks, reads are either 5K  
or 10K. The sd driver uses 8K reads for filesystem access, so in neither  
case is real-world performance indicated. If 8K reads were used in testing  
the same disks that Jiro tested, the numbers would be significantly  
different.

As I posted before, I have yet to see a reasonable benchmark run on a NeXT  
and another workstation using the same SCSI disk that shows NeXT's SCSI  
driver to be inferior. If and when I do, I will lobby NeXT to write better  
drivers. For now, I see no reason to do so.

M Carling
Director, Bay Area NeXT Group
--
Save a SCSI driver, shoot an evil benchmark.