home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / admin / 5054 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  4.4 KB
  1. Xref: sparky comp.unix.admin:5054 comp.windows.x:16722
  2. Newsgroups: comp.unix.admin,comp.windows.x
  3. Path: sparky!uunet!wupost!sdd.hp.com!scd.hp.com!cupnews0.cup.hp.com!hppad.waterloo.hp.com!hart
  4. From: hart@waterloo.hp.com
  5.  (Tony Hart)
  6. Subject: Re: Xterminal-Server ratio wanted
  7. Sender: news@waterloo.hp.com (NetNews)
  8. Message-ID: <BunLL5.2rq@waterloo.hp.com>
  9. Date: Wed, 16 Sep 1992 04:24:40 GMT
  10. References: <Bun4Cu.Ft5@solbourne.com>
  11. Organization: HP Panacom Div Waterloo ON Canada
  12. X-Newsreader: TIN [version 1.1.1 PL6]
  13. Lines: 87
  14.  
  15. Cy Foughty (cy@solbourne.com) wrote:
  16. : 
  17. : I have performed some tests using a network monitor that also can 
  18. : generate traffic. The rules I came up with usually give a good response
  19. : time on Xterminals.
  20. : 
  21. :             Xterminal Configuration Rules
  22. : 
  23. : 1. Separate ethernet segments for Xterminals and ONLY Xterminals!!!!!!
  24. :    Ratio: 1 ethernet segment for
  25. :    every 100 Xterminals with no more than 40 to 50 Xterminals having 
  26. :    heavy graphics programs running. If ALL of your Xterminals are running
  27. :    a lot graphics then reduce the ratio to 1 enet segment for every 30-50
  28. :    Xterminals. You'll need to experiment. 
  29.  
  30. Yup. We generally recommend no more than 40 HP 700/RX's per lan segment.
  31.  
  32. : 2. Because the X protocol trys to use commands instead of transfering images
  33. :    use RISC based Xterminals such as the NCD 19c (19" color). The draw functions
  34. :    will be performed faster. This is one of the most important rules!!!!!
  35.  
  36. Yup. RISC is the way to go if you want the highest-performance graphics and 
  37. LAN thruput. That's why all our X terminals are RISC-based :-).
  38.  
  39. : 3. When setting up the Xterminals DO NOT USE NFS for anything!! NFS is a pig!!
  40. : Use the tftp protocol!
  41.  
  42. Maybe. NFS is sure a lot faster than TFTP when booting the X server or loading
  43. fonts.
  44.  
  45. : 4. Xterminals require SYMMETRIC MULTIPROCESSOR SERVERS for good response time.
  46. :    A SparcStation 2 or and HP 7xx are not good Xterminal servers. I/O on the
  47. :    server side must be fast. Also configure the SYMMETRIC MULTIPROCESSOR SERVER
  48. :    with enough memory and cpu's. This can only be determined by analysis of the
  49. :    applications running on the server. Suffice to say uniprocessor boxes and
  50. :    ASYMMETRICAL MULTIPROCESSOR SERVERS (can you say "SUN") are the worst for 
  51. :    Xterminals.
  52.  
  53. Hmmm. We have a lot of satisfied customers using HP 9000/7xx hosts and 700/RX
  54. terminals. Solbourne wouldn't happen to make SYMMETRIC MULTIPROCESSOR SERVERS,
  55. would they :-) ?
  56.  
  57. : 5. Broadcast packets will kill the network. Xterminals seem to show it more.
  58. :    Keep the segments free from broadcast packets. Like, xdm access should be
  59. :    direct rather than through broadcast packets. Use routers to clean up the
  60. B
  61. :    segment if needed.
  62.  
  63. Maybe. I find it very handy to run my terminal in XDM broadcast mode and 
  64. choose from a list of available hosts, based on current load.
  65.  
  66. : Comments:
  67. : 
  68. :    I have used workstations for years and also Xterminals. There are cases
  69. :    where workstations are the solution. However, Xterminals provide great 
  70. :    service and you have access to the entire server resources. This is good
  71. :    only when the server is a SYMMETRIC MULTIPROCESSOR SERVER that has the
  72. :    memory, cpu's, and I/O controllers on separate boards. Because if the 
  73. B
  74. :    server goes down, all that is needed is to pull the failing board and
  75. :    reboot the server. Performance might decrease while awaiting the new
  76. :    board, but the system will be running. 
  77. : 
  78. :    While developing software on a VAX with several hundred other engineers
  79. :    the performance went in the gutter. Compiles took hours instead of minutes.
  80. :    The solution the MIS department came up with: buy a bigger VAX. OK, fine.
  81. :    for about 6 months, then the same thing again! Same solution! The VAX 
  82. :    upgrades were in the millions of dollars!! The UNI-processor VAXes
  83. :    with I/O to multiple processes chokes. There is a bottleneck, it is
  84. :    called I/O!
  85. : 
  86. :    With SYMMETRIC MULTIPROCESSOR SERVERS that have multiple I/O channels
  87. :    (not all do) most of the bottlenecks vanish. 
  88. : 
  89. : 
  90. :    Xterminals work great if setup correctly with the correct server!!!!!!
  91.  
  92. I keep seeing "SYMMETRIC MULTIPROCESSOR SERVERS" (all caps); is this some sort 
  93. of registered trademark of Solbourne Computers :-) ?
  94.  
  95. Tony Hart,
  96. Panacom Automation Division,
  97. Hewlett-Packard (Canada) Ltd.
  98.  
  99. Standard Disclaimer:
  100. All opinions expressed are my own and do not represent an official statement of
  101. the Hewlett-Packard Company.
  102.