🚀 go-pugleaf

In article <1992Aug17.172755.161@leland.Stanford.EDU> m@crito.stanford.edu (M Carling) writes:
>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.

I agree with your comments on using "disk" to benchmark disk performance;
however, I disagree with your conclusions.  When I upraded the original Maxtor
XT-3830S in my cube to a Seagate ST41650N (Wren VIII) last year, I used the
test you advocate to check the before and after performace.  While I did see
a substantial improvement (~400kB/s with Maxtor; ~1.1MB/s with Seagate),
these numbers are still *far* below the specified theoretical throughput
from these devices.  The Wren VIII has a sustained transfer rate of
1.83 to 3.5MB/s for data coming *off the media* and asynchronous SCSI
transfer rates of 1.65 to 3.0 MB/s.  The problem with the NeXT SCSI
driver is that it doesn't take advantage of various features of SCSI II
like tagged command queueing and sychronous transfer (for which the
drive can support transfer rates up to 5MB/s (which is faster than the
4MB/s max that the old '040 cubes can do because the 53C90A is only
clocked at 20MHz).  The current driver operates in lock step with the
drive, waiting for one command to complete before issuing the next, rather
than overlapping them and allowing the drive to optimize its performance.
The inside story from NeXT is that improving disk performance, while it
certainly could be done, is simply not a priority in a resource-strapped 
development environment.

--Marc