From: hart@waterloo.hp.com
 (Tony Hart)
Subject: Re: Xterminal-Server ratio wanted
Date: Wed, 16 Sep 1992 04:24:40 GMT
Organization: HP Panacom Div Waterloo ON Canada
X-Newsreader: TIN [version 1.1.1 PL6]

Cy Foughty (cy@solbourne.com) wrote:
: 
: I have performed some tests using a network monitor that also can 
: generate traffic. The rules I came up with usually give a good response
: time on Xterminals.
: 
: 			Xterminal Configuration Rules
: 
: 1. Separate ethernet segments for Xterminals and ONLY Xterminals!!!!!!
:    Ratio: 1 ethernet segment for
:    every 100 Xterminals with no more than 40 to 50 Xterminals having 
:    heavy graphics programs running. If ALL of your Xterminals are running
:    a lot graphics then reduce the ratio to 1 enet segment for every 30-50
:    Xterminals. You'll need to experiment. 

Yup. We generally recommend no more than 40 HP 700/RX's per lan segment.

: 2. Because the X protocol trys to use commands instead of transfering images
:    use RISC based Xterminals such as the NCD 19c (19" color). The draw functions
:    will be performed faster. This is one of the most important rules!!!!!

Yup. RISC is the way to go if you want the highest-performance graphics and 
LAN thruput. That's why all our X terminals are RISC-based :-).

: 3. When setting up the Xterminals DO NOT USE NFS for anything!! NFS is a pig!!
: Use the tftp protocol!

Maybe. NFS is sure a lot faster than TFTP when booting the X server or loading
fonts.

: 4. Xterminals require SYMMETRIC MULTIPROCESSOR SERVERS for good response time.
:    A SparcStation 2 or and HP 7xx are not good Xterminal servers. I/O on the
:    server side must be fast. Also configure the SYMMETRIC MULTIPROCESSOR SERVER
:    with enough memory and cpu's. This can only be determined by analysis of the
:    applications running on the server. Suffice to say uniprocessor boxes and
:    ASYMMETRICAL MULTIPROCESSOR SERVERS (can you say "SUN") are the worst for 
:    Xterminals.

Hmmm. We have a lot of satisfied customers using HP 9000/7xx hosts and 700/RX
terminals. Solbourne wouldn't happen to make SYMMETRIC MULTIPROCESSOR SERVERS,
would they :-) ?

: 5. Broadcast packets will kill the network. Xterminals seem to show it more.
:    Keep the segments free from broadcast packets. Like, xdm access should be
:    direct rather than through broadcast packets. Use routers to clean up the
B
:    segment if needed.

Maybe. I find it very handy to run my terminal in XDM broadcast mode and 
choose from a list of available hosts, based on current load.

: Comments:
: 
:    I have used workstations for years and also Xterminals. There are cases
:    where workstations are the solution. However, Xterminals provide great 
:    service and you have access to the entire server resources. This is good
:    only when the server is a SYMMETRIC MULTIPROCESSOR SERVER that has the
:    memory, cpu's, and I/O controllers on separate boards. Because if the 
B
:    server goes down, all that is needed is to pull the failing board and
:    reboot the server. Performance might decrease while awaiting the new
:    board, but the system will be running. 
: 
:    While developing software on a VAX with several hundred other engineers
:    the performance went in the gutter. Compiles took hours instead of minutes.
:    The solution the MIS department came up with: buy a bigger VAX. OK, fine.
:    for about 6 months, then the same thing again! Same solution! The VAX 
:    upgrades were in the millions of dollars!! The UNI-processor VAXes
:    with I/O to multiple processes chokes. There is a bottleneck, it is
:    called I/O!
: 
:    With SYMMETRIC MULTIPROCESSOR SERVERS that have multiple I/O channels
:    (not all do) most of the bottlenecks vanish. 
: 
: 
:    Xterminals work great if setup correctly with the correct server!!!!!!

I keep seeing "SYMMETRIC MULTIPROCESSOR SERVERS" (all caps); is this some sort 
of registered trademark of Solbourne Computers :-) ?

Tony Hart,
Panacom Automation Division,
Hewlett-Packard (Canada) Ltd.

Standard Disclaimer:
All opinions expressed are my own and do not represent an official statement of
the Hewlett-Packard Company.
Newsgroups: comp.unix.admin