home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / benchmar / 1732 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.1 KB
  1. Xref: sparky comp.benchmarks:1732 comp.arch.storage:787
  2. Newsgroups: comp.benchmarks,comp.arch.storage
  3. Path: sparky!uunet!cs.utexas.edu!uwm.edu!caen!destroyer!ncar!csn!teal.csn.org!milton
  4. From: milton@teal.csn.org (Milton Scritsmier)
  5. Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
  6. Message-ID: <BxyD5p.5z3@csn.org>
  7. Sender: news@csn.org (news)
  8. Nntp-Posting-Host: teal.csn.org
  9. Organization: Colorado SuperNet, Inc.
  10. References: <sc77t04@zuni.esd.sgi.com> <1992Nov16.031850.9663@igor.tamri.com> <se37imk@zuni.esd.sgi.com>
  11. Date: Thu, 19 Nov 1992 07:37:00 GMT
  12. Lines: 45
  13.  
  14. In article <se37imk@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
  15. >
  16. >Another reason for not doing it on the host at all.  Newer (read, more
  17. >or less high performance) drives tend to have hardware dedicated to the
  18. >block translation to sect/head/cyl, etc.  Granted that the drives often
  19. >have rather underpowered CPU's for all that they are asked to do, they
  20. >usually throw enough hardware at it to overcome the problems.  I'm sure
  21. >this isn't the case for most IDE drives though.
  22.  
  23. I am familiar with the design of several drives (and have done firmware
  24. for a couple of drives and controllers), and the only special hardware
  25. I know of to do the logical to physical mapping is the CPU. In fact,
  26. while WD's SCSI chip does (or at least did originally) have a divide,
  27. it is so slow that even WD doesn't use it. While some drives have a
  28. DSP chip, the communication path between it and the CPU is usually
  29. so tedious that a divide done on the DSP and sent back to the CPU is
  30. slower than one done by the CPU itself. Most microcontroller chips
  31. used on drives these days can do a 32 x 16 divide in less than
  32. 4 us. That's a crawl by computer CPU standards, but certainly
  33. doesn't affect command overhead that much.
  34.  
  35. I also don't consider most drive CPU's to be underpowered. They are
  36. chosen quite carefully for what they need to do. The problem with
  37. designing drives is that you have long periods of little to do
  38. interspersed with short periods of frantic activity. If the
  39. CPU can't handle the short bursts of activity quick enough, you
  40. find yourself losing revolutions. As you mentioned, most CPUs have
  41. support chips to help them deal with much of this problem. A
  42. well-designed drive architecture thus has plenty of horsepower
  43. to do caching and sector mapping. After all, microcontroller
  44. designs have ridden the same technology curve that computer CPUs
  45. have ridden. If disk drive purchasers required more CPU intensive
  46. features in their drives, then drive manufacturers would be able
  47. to find a microcontroller which provided the needed horsepower
  48. (with the usual mark-up, of course :-).
  49.  
  50. I also think that many IDE CPUs are just as powerful as the ones on
  51. SCSI drives. I know that WD, for example, uses the same Intel 80196
  52. processor on its IDE drives as it does on its SCSI drives. The reasons
  53. are that most of the real-time interrupt requirements are the same,
  54. and that the volume discounts a drive manufacturer gets for using the
  55. same CPU on all of its drives helps offset the fact that in one
  56. application the CPU may be somewhat overpowered. Besides, 80196's
  57. are *cheap* these days. :-)
  58.  
  59.