home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / software / 1197 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.1 KB  |  52 lines
  1. Newsgroups: comp.sys.next.software
  2. Path: sparky!uunet!stanford.edu!leland.Stanford.EDU!news
  3. From: m@crito.stanford.edu (M Carling)
  4. Subject: Re: SCSI drivers
  5. Message-ID: <1992Aug17.172755.161@leland.Stanford.EDU>
  6. Sender: news@leland.Stanford.EDU (Mr News)
  7. Organization: DSO, Stanford University
  8. References: <1992Aug15.032753.15794@shaman.com>
  9. Date: Mon, 17 Aug 92 17:27:55 GMT
  10. Lines: 40
  11.  
  12. In article <1992Aug15.032753.15794@shaman.com> jiro@shaman.com (Jiro  
  13. Nakamura) writes:
  14. > My own tests using SCSI SpeedGun which access the "sg" SCSI generic  
  15. driver  
  16. > directly gives some of the following numbers.
  17.  
  18. You are using the wrong driver. Your tests are irrelevent to the speed of  
  19. the SCSI disk driver (the sd driver) since you are benchmarking a  
  20. different driver.
  21.  
  22. > Note that I am using the  
  23. > SCSI read command directly at the driver level, avoiding the caching  
  24. > problems noted by other posters.
  25.  
  26. Note that using the "read" menu command from within the /etc/disk program  
  27. supplied by NeXT uses the same mechanism with the sd driver. Without being  
  28. an OEM/VAR, waiting 4 months, or paying Jiro a nickel, you can do the same  
  29. thing, and with the right driver to boot!
  30.  
  31. > Disk throughput was computed by reading 5000 blocks from block 0 with a  
  32. 10  
  33. > block incremement on each read.
  34.  
  35. This "benchmark" would be irrelevent even if used with the correct driver.  
  36. Notice that it does reads in 10 block chunks. Because some of the disks  
  37. use 512 byte blocks and others use 1024 byte blocks, reads are either 5K  
  38. or 10K. The sd driver uses 8K reads for filesystem access, so in neither  
  39. case is real-world performance indicated. If 8K reads were used in testing  
  40. the same disks that Jiro tested, the numbers would be significantly  
  41. different.
  42.  
  43. As I posted before, I have yet to see a reasonable benchmark run on a NeXT  
  44. and another workstation using the same SCSI disk that shows NeXT's SCSI  
  45. driver to be inferior. If and when I do, I will lobby NeXT to write better  
  46. drivers. For now, I see no reason to do so.
  47.  
  48. M Carling
  49. Director, Bay Area NeXT Group
  50. --
  51. Save a SCSI driver, shoot an evil benchmark.
  52.