home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8442 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.8 KB
  1. Path: sparky!uunet!decwrl!infopiz!lupine!motcsd!starnet!jpp
  2. Newsgroups: comp.arch
  3. Subject: Re: BUSES
  4. Message-ID: <1992Jul28.180537.14749@StarConn.com>
  5. From: jpp@StarConn.com (John Pettitt)
  6. Date: 28 Jul 92 18:05:37 GMT
  7. References: <1992Jul23.092211.18462@nuscc.nus.sg> <1992Jul23.191927.1181@pcnntp.apple.com> <1992Jul27.191347.4485@ksmith.uucp>
  8. Organization: Starnet-Public Access UNIX--Los Altos, CA  415-949-3133
  9. Lines: 51
  10.  
  11. keith@ksmith.uucp (Keith Smith) writes:
  12. >Is it not also true however, that the current disk devices can't even
  13. >swamp an ISA bus?  The average desktop doesn't have multiple striped
  14. >disks and whatnot.
  15.  
  16. >Even the new crop cannot swamp an EISA bus.  Video may soon go another
  17. >route, we will see.  Memory is already localized, as part of the CPU on
  18. >most products, with a SIMM pinout becomming a local memory bus of sorts.
  19.  
  20. Not true - on a 486 multi processor system running UNIX (an extreme
  21. example I will admit) bus bandwidth for disk, network and serial I/O is
  22. a major concern.   
  23.  
  24. On a more normal level an ISA bus will peak out at around 3.3 MB a
  25. second half duplex (600 ns per transaction 2 bytes per).  In the real
  26. world where things don't run 0 wait and you have to do read modify write
  27. transactions on byte registers things slow way down and just over 1Mb /
  28. second is about all you get without using bus mastering.
  29.  
  30. EISA is a better proposition but even their the 33 MB/sec theorectical
  31. max is not attainable on any system I know of.  ~10Mb sec is more
  32. normal.    
  33.  
  34. In paractice the pure data rate is often not the issue - you don't want
  35. to more more than a 2 megs a scond on a PC that often.  However as most
  36. PC's either don't have write buffers or have at most 4 levels of
  37. buffering the main x86 CPU is held in wait state while the bus
  38. transaction finishes.  This significantly impacts performance.   For
  39. example a 486/25 Micro Channel system (ALR in this case) running 128
  40. serial ports at 38.4K baud (~5 mbits /sec) takes a 60% of the CPU.  If
  41. you look further into this of that 60% some 2 thirds (40% of real time)
  42. is spent waiting for the bus to finish a transaction.   Whilst in the
  43. real world people don't run all terminals at 38.4 100% duty you can see
  44. that bus speed does make a difference.  N.B. these numbers are from a
  45. real live set of tests done during the design of a fault tolerant I/O
  46. solution. 
  47.  
  48. So waht to do about it.  Well fistly keep things in balance - EISA is
  49. fine for most PC applications.   Beyond that more write buffering or a
  50. separate I/O controller with high speed access to memory and it's own
  51. EISA or ISA bus may be the way to go (similar to the channel controller
  52. concept in mainframe systems).
  53.  
  54. Regards
  55.  
  56. John Pettitt  I/O system designer (retired :-)
  57.  
  58. -- 
  59. John Pettitt                    jpp@starconn.com
  60. Archer N81034                    apple!starnet!jpp
  61. Me, say that, never: It's a forged posting!    Fax: +1 415 949 2037
  62.