home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 6795 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  2.8 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!caesar!drew
  2. From: drew@caesar.cs.colorado.edu (Drew Eckhardt)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: SCSI vs IDE speed difference
  5. Message-ID: <1992Jul27.195851.20374@colorado.edu>
  6. Date: 27 Jul 92 19:58:51 GMT
  7. References: <14ve4sINNci7@agate.berkeley.edu>
  8. Sender: news@colorado.edu (The Daily Planet)
  9. Distribution: usa
  10. Organization: University of Colorado at Boulder
  11. Lines: 48
  12. Nntp-Posting-Host: caesar.cs.colorado.edu
  13.  
  14. In article <14ve4sINNci7@agate.berkeley.edu> vojta@powdermilk.berkeley.edu (Paul Vojta) writes:
  15. >Various messages on comp.os.linux seem to indicate that it's faster to have
  16. >a SCSI disk than an IDE.
  17.  
  18. Not with the current SCSI drivers.  The "normal" disk driver will tell
  19. the disk controller to read  X contigous blocks with one command, and 
  20. will interrupt for each sector.  Since the Minix fs code does a two 
  21. block read ahead, that will typically be 6 sectors.
  22.  
  23. The SCSI code needs to do one command per block, which means 2 sectors
  24. per command, and it will interrupt once per command.
  25.  
  26. You loose a lot from the overhead of one command per block (ie, having to go 
  27. through ARBITRATION / SELECTION / MESSAGE OUT / COMMAND OUT phases) as opposed
  28. to one command per X blocks.  This means the current SCSI drivers are 
  29. slower by almost a factor of 3.
  30.  
  31. The new SCSI drivers (under development) will scatter / gather, and 
  32. do all contigous reads as one SCSI command.  With a bus mastering controller
  33. like the Adaptec, you'll see one interrupt when it's done, use a minimal amount
  34. of CPU time, and will see considerably better performance than IDE.
  35.  
  36. I suspect that a larger block size, and bigger read ahead, will give 
  37. better performance under both SCSI and IDE.
  38.  
  39. >Yet, in the second-most-recent PC magazine, IDE drives come out best, unless
  40. >you have a caching controller on an EISA bus.  They state that the faster
  41. >transfer speed of SCSI is not a factor, since the transfer speed is limited
  42. >anyway by how fast the disk spins.  Their benchmarks were for DOS, but it
  43. >seems to me that their comment would apply to Linux, too.
  44. >
  45.  
  46.  
  47. Both SCSI and IDE can have on board buffers.  If your drive is doing 
  48. readahead, like most modern disks do, the faster transfer speed will
  49. be an issue.
  50.  
  51. Also, IDE does not make sense in multiple disk installations.  With SCSI,
  52. the drive will DISCONNECT when it is seeking, and another disk can use 
  53. the bus.  With IDE that doesn't happen.
  54.  
  55. >So, since I am currently shopping for a system to run Linux on, which should
  56. >I get?  Specific benchmarks, if available, would be appreciated.
  57. >
  58. >--Paul Vojta, vojta@math.berkeley.edu
  59.  
  60. Unless you want to wait for a SCSI tape driver, or need a single large disk
  61. (large defined as > 300M), IDE is probably your best bet.
  62.