home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8687 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  7.2 KB
  1. Xref: sparky comp.unix.bsd:8687 comp.benchmarks:1636 comp.arch:10587 comp.arch.storage:755
  2. Newsgroups: comp.unix.bsd,comp.benchmarks,comp.arch,comp.arch.storage
  3. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!darwin.sura.net!sgiblab!sgigate!sgi!igor!jbass
  4. From: jbass@igor.tamri.com (John Bass)
  5. Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
  6. Message-ID: <1992Nov10.170022.21624@igor.tamri.com>
  7. Organization: DMS Design
  8. References: <1992Nov7.102940.12338@igor.tamri.com> <36794@cbmvax.commodore.com>
  9. Date: Tue, 10 Nov 92 17:00:22 GMT
  10. Lines: 136
  11.  
  12. From: jesup@cbmvax.commodore.com (Randell Jesup)
  13. >    You're right about the early SCSI days - for example, scsi got zone
  14. >recording earlier, etc.  The base technology in IDE/SCSI is now the same, so
  15. >it comes down to software and interface issues.  I'll agree that for a single-
  16. >disk system and small transfers, IDE has a slight margin in speed over SCSI,
  17. >due to lower command overhead.  This may change as SCSI-fast becomes more
  18. >universal, especially in large transfers and as drives get into >4MB/s
  19. >sustained rates.
  20.  
  21. Given small transfers qualification, "Slight margin in speed" is highly
  22. debatable .... The ability to do read scheduling and write placement
  23. based upon knowing geometry and current head/spindle position allows for
  24. 30%-700% better semi-random small file I/O with the right filesystem design.
  25. The SCSI abstraction hides this important performance information. In addition
  26. the command overhead differences mean significant request interleaves for
  27. high transfer rate drives, for current fast SCSI drives often greater than
  28. 6-12 sector times. In theory, IDE would be 0 with passthru buffering, and
  29. 1-3 with buffer flipping (most current designs require 1 or 2).
  30.  
  31. While burst transfer rates (the raw drive rate) may be of interest in some
  32. areas, most files/directories are under few K. Drives and filesystems should
  33. be optimized to handle multiple small requests.
  34.  
  35.  
  36.  
  37. >>First, dumb IDE adapters are WD1003-WHA interface compatible, which means:
  38. >>
  39. >>    1) the transfer between memory and controller/drive are done in
  40. >>    software .... IE tight IN16/WRITE16 or READ16/OUT16 loop. The
  41. >>    IN and OUT instructions run a 286-6mhz bus speeds on all ISA
  42. >>    machines 286 to 486 ... time invariant ... about 900us per 16bits.
  43. >>    This will be refered to as Programmed I/O, or PIO.
  44. >
  45. >    I think you mean 900ns, or you have very slow drives... :-)  This gives
  46. >a max burst rate of around 2MB/s.
  47.  
  48. Slip of the cortex ... and 2MB/s is about right with a highly optimized
  49. driver interrupt routine plus streamlining of the common interrupt handler.
  50. When I did this for SCO's UNIX 3.2v2 two years ago it made a big improvement.
  51. With standard interrupt handlers and driver coding practices, the number
  52. is is closer to half that, and quite noticable on current high performance
  53. IDE drives with buffering.
  54.  
  55.  
  56.  
  57.  
  58. >    Once per sector?  Don't PC's use the ReadMultiple/WriteMultiple
  59. >commands?  I guess not (which matches what I've heard elsewhere).  Our IDE
  60. >implementations will use read/write multiple to reduce CPU interrupt and
  61. >task-switching overhead on longer reads, and we transfer up to 16 sectors per
  62. >interrupt.  BTW, we have on occasion found bugs in some drives' RWMultiple
  63. >commands, or funny performance results, like slower throughput with larger
  64. >transfers.
  65. >
  66. >    I don't understand your comment about "poor man's disconnect".  While
  67. >you may be waiting for an interrupt, unless you have multiple IDE busses you
  68. >can't use your second IDE drive until the IO on the first is complete.
  69.  
  70. Yes, Yes ... the interrupt for WD1003/IDE interfaces means the 512 byte sector
  71. buffer is full, and must be emptied. R/W Multiple are used, but it requires
  72. handling a transfer request interrupt for each sector, or busy waiting on
  73. data_request in the command status register ... hence poor man's disconnect
  74. from the processor bus. For WD100? cards, there is a single buffer per
  75. controller ... on the IDE model there is a buffer per drive ... and each
  76. can be active from what I can tell selected by the drive select bit(s).
  77.  
  78.  
  79.  
  80.  
  81. >    Write-buffering (starting to be commonly available as an option on
  82. >SCSI drives) can help in avoiding slipping revs.  So long as ordering is
  83. >maintained, write-buffering in practice is fine for most uses of desktop
  84. >systems.  Of course, this can apply to either IDE or SCSI, but for IDE you'll
  85. >have to add commands to turn it on, or have it default to on, or use jumpers.
  86.  
  87. While some speed can be gained by this practice, all ability to handle
  88. error conditions responsibly is generally lost. I am not a big fan of
  89. lookaside bad block handling to a slow microprocessor ... it only
  90. SIGIFICANTLY reduces throughput when important data gets spared ... leading
  91. to difficult to understand IN-FIELD performance problems. Filesystems
  92. should know and deal with media problems ... even though most UNIX's
  93. either don't or have the drivers do the fix ups.
  94.  
  95.  
  96.  
  97. >As a multi-disk interface, or generalized IO interface (tape drives, CDROM,etc)
  98. >SCSI has a large edge.  Also, IDE can only handle 2 devices.  Even if IDE
  99. >tape drives and CDROMs were available (they're not), you'd rapidly start
  100. >needing multiple IDE interfaces. Tapes are (or will be) here, and I
  101. expect CDROMS (now partly proprietary & SCSI) to be mostly IDE & SCSI
  102. in the future. IDE is already extending the WD1003 interface, I expect
  103. addtional drive support will follow at some point, although multiple
  104. hostadapters is a minor cost issue for many systems.
  105.  
  106.  
  107.  
  108. >>All IDE and SCSI drives have a microprocessor which oversees the bus and
  109. >>drive operation. Generally this is a VERY SLOW 8 bit micro ... 8048, Z80,
  110. >>or 8085 core/class CPU. The IDE bus protocol is MUCH simpler than SCSI-2,
  111. >>which allows IDE drives to be more responsive. Some BIG/FAST/EXPENSIVE
  112. >>SCSI drives are starting to use 16 micro's to get the performance up.
  113. >
  114. >    Right.  This is the reason IDE is slightly faster for small, frequent
  115. >IO's.
  116.  
  117. But I again contend "slightly faster" is wrong ... the gains can be much more
  118. significant as stated above for "small frequent IO's".
  119.  
  120.  
  121.  
  122.  
  123. >>Even the fastest 486 PC UNIX systems are filesystem CPU bound to between
  124. >>500KB and 2.5MB/sec ... drive subsystems faster than this are largely
  125. >>useless (a waste of money) ... especially most RAID designs. Doing
  126. >>page flipping (not bcopy) to put the stuff into user space can improve
  127. >>things if aligned properly inside well behaved applications.
  128. >
  129. >    This is a combination of poor interfaces and the OS interface.
  130. >AmigaDos tries to do transfers direct to user buffers where possible,
  131. >especially for large reads, and reserve most of it's buffer space for
  132. >small (<1 block) reads and filesystem structures (file headers, etc).  This
  133. >can provide very low-overhead IO for the common cases.  For example, with
  134.  
  135. What I said was enough ... the UNIX interfaces are more general by DESIGN
  136. and a simplistic OS can surely take additional short cuts beyond page
  137. flipping ... AND SOME UNIX's do, and in some cases more should. Other than
  138. pushing your product, I don't see the utility in knocking UNIX and pumping
  139. AmigaDos. But thanks for your posting anyway.
  140.  
  141.  
  142. As a side note, I saw a reference a while back to the IDE standard in
  143. progress ...  How can I get a copy?
  144.  
  145.  
  146. John Bass, Sr. Engineer, DMS Design                  (415) 615-6706
  147. UNIX Consultant             Development, Porting, Performance by Design
  148.