home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10476 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  4.4 KB
  1. Xref: sparky comp.arch:10476 comp.unix.bsd:8537 comp.os.linux:15921 comp.arch.storage:749
  2. Path: sparky!uunet!cbmvax!jesup
  3. From: jesup@cbmvax.commodore.com (Randell Jesup)
  4. Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux,comp.arch.storage
  5. Subject: Re: IDE faster than Mips SCSI disk
  6. Message-ID: <36775@cbmvax.commodore.com>
  7. Date: 6 Nov 92 21:06:02 GMT
  8. References: <1992Nov6.033942.21194@ntuix.ntu.ac.sg>
  9. Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
  10. Followup-To: comp.arch.storage
  11. Organization: Commodore, West Chester, PA
  12. Lines: 82
  13.  
  14. eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
  15. >These figures are not meant to be a thorough study. More of a provocation
  16. >for more soul searching. The widespread belief that SCSI-2 is "defininely
  17. >faster than IDE" is questionable, in fact under some circumstances, entirely
  18. >false.
  19.  
  20.     Yes, with MAJOR qualifications (below).
  21.  
  22. >    The results are not surprising for those who study the technical
  23. >specs of these disks. IDE has more potential for high speed because of its
  24. >lack of protocaol overhead. Its closeness to the disk also make it very
  25. >reliable and efficient.
  26.  
  27.     This is an advantage for very small reads.  For larger reads, the
  28. protocol overhead is minimal compared to transfer time.  Also, protocol
  29. overhead can vary by orders of magnitude depending on the SCSI chip used,
  30. the driver, and the hardware around it.
  31.  
  32. >    There are advanced disks which can do simultaneour multiple-head reads,
  33. >but these techniques can also be used for IDE as well.
  34.  
  35.     No they cannot (or at least not as well), since IDE doesn't support
  36. the equivalent to the SCSI disconnect.  With SCSI, you can burst at 10MB/s to
  37. drives that can only sustain 1-4MB/s, and keep several of them busy at a time
  38. on a single bus.
  39.  
  40. >    IDE is just a simple interface definition, just like SCSI-2, but IDE,
  41. >is optimised for HARD DISKS, SCSI is not. SCSI is more general purpose.
  42.  
  43.     SCSI is more general purpose, but a good scsi implementation should
  44. only add a small number of microseconds to each IO.  A slow or old or poor
  45. implementation could easily add 1-5 milliseconds to each IO (a lot if you're
  46. doing 512 bytes/IO).
  47.  
  48. >The mips machine under test runs on ultrix. Although it has up to 10Gbyte 
  49. >of hard-disk, it is not so heavily loaded. We only use it for email and
  50. >news feed. Fragmentation can be severe because I cannot even have 32 
  51. >megabyte free space in /usr/tmp , only 30 Mbytes.
  52.  
  53.     Well, this certainly can affect your tests A LOT.
  54.  
  55. >    IOZONE writes a 30 Megabyte sequential file consisting of
  56. >    61440 records which are each 512 bytes in length.
  57. >    It then reads the file.  It prints the bytes-per-second
  58. >    rate at which the computer can read and write files.
  59.  
  60.     512 byte reads aren't exactly large.  Most Unix FS's use larger blocks
  61. than that, and most stdio packages use large BUFSIZ's than that, I think.  The
  62. difference in IO speed between 512 byte IO's and 32K IO's (at the SCSI level)
  63. can easily be 1:20.  Actually, your kernel/fs is probably doing 1-8K transfers
  64. to the Unix buffercache, and filling from that.  Also, Unix always uses a
  65. buffercache and copies to user-space in the kernel, while some micro's (such as
  66. the Amiga) will DMA direct to user space whenever possible.
  67.  
  68. >    345684 bytes/second for writing the file
  69. >    641985 bytes/second for reading the file
  70.  
  71.     These aren't real fast times.  I have a 1gig disk on my Amiga which
  72. does 4MB/s through the filesystem for large reads (the disk can only sustain
  73. about 4.3MB/s off the platters).  Times like this tell you nothing about the
  74. interface unless you (a) have SCSI and IDE versions of the SAME MODEL drive,
  75. and (b) are running them under the same OS.  You still have to factor in
  76. the hardware to implement both.  For example, and 53c80 SCSI chip will be
  77. slow regardless, since it's a glorified parallel port, while an 53c720 will
  78. push the SCSI interface to it's limits.
  79.  
  80.     When you use a benchmark, you MUST understand it's limitations to
  81. interpret the results.  IOZONE is a very crude benchmark, especially for
  82. making cross-interface or worse yet cross-OS comparisons.
  83.  
  84.     I advise you learn more about how things work before you go making
  85. blanket statement like the ones above.  Also, comp.arch.storage is more
  86. appropriate than comp.arch.
  87.  
  88.     Followups to comp.arch.storage.
  89.  
  90. -- 
  91. To be or not to be = 0xff
  92. -
  93. Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
  94. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
  95. Disclaimer: Nothing I say is anything other than my personal opinion.
  96.