home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / ibm / pc / hardware / 37301 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  4.2 KB
  1. Path: sparky!uunet!tcsi.com!iat.holonet.net!news.cerf.net!usc!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!cronkite.Central.Sun.COM!texsun!exucom.exu.ericsson.se!pc254167.exu.ericsson.se!exuptr
  2. From: exuptr@exu.ericsson.se (Sunbird a la 400ci)
  3. Newsgroups: comp.sys.ibm.pc.hardware
  4. Subject: Re: local bus hard disk
  5. Message-ID: <exuptr.762.0@exu.ericsson.se>
  6. Date: 26 Jan 93 23:04:58 GMT
  7. References: <1993Jan23.231824.24755@rose.com> <1993Jan24.014406.27423@mlb.semi.harris.com> <C1E0sw.I4o@unix.portal.com>
  8. Sender: news@exu.ericsson.se
  9. Organization: Ericsson Network Systems, Inc.
  10. Lines: 74
  11. Nntp-Posting-Host: pc254167.exu.ericsson.se
  12. X-Disclaimer: This article was posted by a user at Ericsson.
  13.               Any opinions expressed are strictly those of the
  14.               user and not necessarily those of Ericsson.
  15.  
  16. In article <C1E0sw.I4o@unix.portal.com> danb@shell.portal.com (Dan E Babcock) writes:
  17. >In article <1993Jan24.014406.27423@mlb.semi.harris.com> sonny@trantor.
  18. harris-atd.com (Bob Davis) writes:>>In article <1993Jan23.231824.24755@rose.
  19. com> gyl.midroni@rose.com (gyl midroni) writes:
  20.  
  21. >>       Even the fastest single drives can only spin the bytes under
  22. >>the drive's head at around 3 million bytes/sec.
  23.  
  24. >That's about right. A few can break 4MB/s.
  25.  
  26. Can you say "on-board cache"?
  27.  
  28. >>       So, isn't a 5.33 million bytes/sec 16-bit slot on the ISA bus pretty
  29. >>much up to the task of delivering and retrieving data to and from a
  30. >>single hard drive that is only capable of spinning the data off or onto
  31. >>the platters at a 3 million bytes/sec rate?
  32.  
  33. There's no such animal on an AT.  5.33 MB/sec would require absolutely no 
  34. interruptions and no wait-states on an IO cycle at 8 MHz.
  35.  
  36. This rarely happens, especially if you are copying a file, for example.  The 
  37. file must go in and out over the same bus.  As you say, if it goes back to 
  38. the same drive, then the drive could be a limitation, also, but if you are 
  39. pumping it out over a network or to your screen or something else, the drive 
  40. is not getting full bus utility anyway.
  41.  
  42. >>       And isn't it expensive overkill to provide a 132 million bytes/sec
  43. >>truck (local bus) to haul 3 million bytes/sec freight ( a fast hard drive's
  44. >>maximum, spin-limited data transfer rate)?  Seems like that expensive local 
  45.  
  46. Yes, no.  You hardly ever get to use 100% of what is there.  33 * 4 MBytes/
  47. sec may indeed be overkill, but it will definitely give you more throughput 
  48. even on a single drive, especially if there is any cache involved.  The 
  49. cache will transfer at the full speed of the bus, plus any wait states.
  50.  
  51. >The "132MB/s" figure is just for marketing. The actual transfer rate is
  52. >limited by the speed of DRAMs. 20-30MB/s is realistic.
  53.  
  54. This depends.  If you have near 0 wait-state operation, you can pump this 
  55. stuff off the bus back into RAM at 4 bytes / clock cycle on a 486.
  56.  
  57. But again, your bus may have wait states, and if memory is not interleaved 
  58. and fast, you won't really get close to 0 ws operation.  If you figure 1 bus 
  59. ws and 2 mem ws, then you can transfer 4 bytes from bus to mem in 5 cycles.  
  60. This is indeed within the quoted range.
  61.  
  62. But remember the AT bus is subject to all that limitation also.
  63.  
  64. >You hit the nail on the head: all this only matters if you're using an
  65. >OS that will take advantage of it (i.e. not MSDOS :-))
  66.  
  67. This doesn't figure with my experience.  Improvement under DOS is not as 
  68. dramatic as you would conclude from the figures, but it is significant.
  69.  
  70. >>system without heavy multitasking requirements. Certainly, I am not going
  71. >>to improve the prolonged data transfer rate onto or off the disk -- 
  72. >>3 million bytes/sec is as fast as data physically can be sucked up or spewed
  73. >>out.
  74.  
  75. >Right. It goes without saying that a faster bus is not going to improve
  76. >single-drive performance.
  77.  
  78. Not true.  Bus delay is ON TOP of the disk access speed.  You will in any 
  79. case increase total throughput because the data spends less time on the bus, 
  80. all other things being equal.
  81.  
  82. Not only that, I have seen it :-D
  83.  -----------Visit the SOUNDING BOARD BBS 214-596-2915, a Wildcat! BBS--------
  84.  ObQuotes:
  85.  "Quick to judge, quick to anger, slow to understand..."
  86.  "Ignorance and prejudice, and fear go hand-in-hand..."
  87.  
  88.     Patrick Taylor, Ericsson Network Systems
  89.     exuptr@exu.ericsson.se                    "Don't let the .se fool you"
  90.