Conference bulova::decw_jan-89_to_nov-90

    X protocol on a LAN should be no problem.  
    
    I ran a series of experiments in which I captured and timestamped every
    protocol packet going between a server and all of its clients.  As
    expected, the packet arrival rate was bursty but relatively sparse, the
    packet sizes varied but were generally small.  (As always, your milage
    may vary...)
    
    I know of at least three clusters in which a number of workstations run
    remote clients routinely.  One of these clusters is the subject of a
    LAN monitor most of the time.  No problems reported.
    
    If you are designing a DECWindows client, be aware of two protocol
    issues: MotionNotify and synchronous round trips (XGetMumble and
    XQueryMumble).  
    
    If your application needs to turn on MotionNotify, do it.  But don't
    turn it on if you don't need it.  MotionNotify can generate as many as
    50 protocol messages per second when the user is moving the pointer
    around.
    
    Again, if your application needs to do XGetSomething or
    XQuerySomething, do it.  But if you don't need to, don't.  When the
    call is made, a blocking read is issued; your application will stall
    until the server gets the request (one transport), processes it, and
    returns the reply (second transport).
    
    
    John B.

    John,
    
    Thanks very much for the info.  If I understand you correctly, X
    isn't too much of a network hog.  Sounds like the X traffic is similar
    in nature to LAT - true?
    
    You mentioned remote clients serviced by a cluster.  Were they
    async connections or Ethernet based?  If async, what was the line
    speed?  And how heavy was the traffic?  What was response time like?
    
    I figured MotionNotify was a heavy consumer, but didn't realize
    to that extent!  Do you know of any documentation that can provide
    that type of resource usage data?  I'd like to get a copy to read.
    
    Thanks again.                                                        
    Stan Valencis

    Stan
    
    To what degree X is an network hog depends on the application.  There
    have been discussions on the internet recently about how bad the window
    manager 'uwm' can be when performing an interactive operation such as
    resize or move window.  As John said, "mileage may vary" and that's
    rarely truer than with X.
    
    						m

    I completely understand that resource consumption is application
    specific.  What I'm trying to find out is how much resources are
    used (for remote calls) by the window manager, Xget/query calls
    etc.  And perhaps some guidelines/gotchas to follow when developing
    networked based X solutions.  With 100 work stations all talking
    X, I want to be sure nothing chokes.  If you have any information
    like that, please let me know.  
    
    Thank very much.
    Stan Valencis

Unless you are using techniques to increase the effective bandwith of the 
ASYNCH channel (compression or some such) or just pay for the higher speed
lines, then I'd advise against it. Some early experiments were done using 
low speed lines (2400 baud) and the performance was not acceptable. I've 
heard that 9600 will work, but its still slow and depends on having the
compression hardware. 38.4K should be reasonable if it's a dedicated line.
You might want to ask the people working on the DECwindows terminal.

There's not any intrinic problem with the X protocol, it's simply the nature of
the task.

James

    Re .2 by CTOAVX::VALENCIS
    
    > You mentioned remote clients serviced by a cluster.  Were they
    > async connections or Ethernet based?  
    
    The data I collected was all Ethernet based.  I've never seen an async
    DECWindows connection.  
    
    Remember that the data I saw indicated that X protocol traffic is
    bursty.  Peak rates will be important...
    
    > I figured MotionNotify was a heavy consumer, but didn't realize
    > to that extent!
    
    Oops!  MotionNotify has the *potential* of generating a lot of small
    packets.  ~50/sec is the *peak*, not the average.  And even at the peak
    rate, the actual data transfer rate is not all that high.   50/sec * 32
    bytes = 1600 bytes/sec.  (32 bytes is just the size of  the X protocol
    packet, not the full network packet.)  
    
    I didn't want to startle you, just to instill a little caution.
    
    Another thought occurred to me just now.  The X programming style seems
    to encourage the use of lots of special purpose windows.  Functionally,
    that's very useful; it provides excellent mechanisms for controlling
    the display.  But be warned: TANSTAAFL -- There Ain't No Such Thing As
    A Free Lunch.  Lots of windows means lots of resources; in this
    discussion it means lots of protocol messages to create and manage each
    of those windows.  (In one protocol survey, ExposeNotify was the most
    frequently occurring event.)
    
    If you use the toolkit for menubars, pushbuttons, so on and so forth,
    you need not worry about this issue directly.  The toolkit folks work
    hard to pick the right number of windows to implement each individual
    feature.  
    
    But when you start designing how your application will look (total
    number of widgets you will use, etc.) keep TANSTAAFL in mind.  If you
    need a widget or a window, use it; that's what they are for.  Just
    don't go hog wild...
    
    > Do you know of any documentation that can provide that type of resource 
    > usage data?
    
    None that is up-to-date or public.  Sorry...
    
    
    John B.
              

    Thanks very much for all the info.
    
    On note .5, you mentioned "data compression" over Async lines to
    maximize throughput.
    
    Can you explain how compression is accomplished?  Is compression a function
    of the modem or some software technique/parameter? 
    
    Thanks,
    Stan Valencis

There are modems available today that attempt to gain higher effective baud 
by doing various forms of data compression. The most frequent is run-length
compression. Usually this is done entirely in the modem-to-modem link and is
not visible to the software or user. The drawback is that you must have a 
pair of similar modems to ensure that you can get the benifit.

James