chrisv@cmc.COM (Chris VandenBerg) (03/30/91)
Good morning all!
Several weeks ago I floated a query to both the TCP-IP and the X list looking
for information about the network load imposed by X. I received some great
responses, which I have summarized here for general consumption. I have included
all the respondents e-mail addresses if you wish to contact someone directly.
Thanks,
Chris VandenBerg
CMC - A Rockwell Intl Co. 125 Cremona Dr. Goleta, CA. 93117
Internet - chrisv@cmc.com ma-bell - 805-562-3127
-----------------responses start here----------------------------
From: tmallory@BBN.COM
Status: R
Chris,
While not very sexy, performing file system backups over the net is a
necessary and bandwidth hungry application. Our corporate communications
folks are concerned that an FDDI backbone might be not be enough to get all
remote systems backed up to come central site in the not too far distant
future. You might consider loading up 50% of the ring with this sort of
traffic, and then run some of the apps that other people will be suggesting.
Tracy
---------------------------------
From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
Subject: Re: bandwidth usage for X applications?
To: Chris VandenBerg <chrisv@cmc.com>
In-Reply-To: Your message of Tue, 5 Mar 91 08:21:06 PST
Status: R
Actually, I think you will find things are not as bad as it seems.
I have been testing recently to see about running X over 9600 baud
slip links. This was brought about by an ad for an X-terminal that
runs off of a terminal server over an async line. I didn't believe
it until I tried it myself.
---------------- -------- --------
: SPARCSTATION :_________: PC : SLIP : PC :________ Campus
: Running X : Ethernet: :---------: : Network
---------------- -------- 9600 -------- :
:
:
------------------------ :
: VAX 6320 :________:
: Running :
: DECWINDOWS :
------------------------
Using the above scenario, I had no problem running DecWindows applications
from the SUN. I started up VUE$MASTER (The DECW Session Manager) and
proceeded to launch applications. I tried the BOOK READER which is a DEC
interface into their online documentation, and even had a spirited game of
SOLITAIRE, graphics and all. There was only marginally noticable latency,
and that could probably be tuned out by playing with network parameters or
maybe running CSLIP or PPP instead of old-fashioned SLIP. This was a test
that was set up in a lab in about 30 minutes. I am sure we can do better.
Of course, this is just one mans findings. I would be very interested in
hearing anything negative you hear.
All the best.
bill
bill gunshannon
702WFG@SCRVMSYS.BITNET
--------------------------------
From: kwe@bu-it.bu.edu (Kent England)
Some people here in Information Technology at Boston
University set up a test to measure network load from one X terminal
doing specific X things. Here is an excerpt of what they did:
+------------+ +--------------+
| | | |
| diskful | | Visual |
| server | | |
| | | X19 turbo |
| | | |
+------------+ +--------------+
|| ||
=================================================================
||
subnet +--------------+
| |
| LANalyzer |
| |
+--------------+
They ran some test cases for a variety of X terminal
activities. The only traffic on the network was traffic from the X
terminal and the diskful server, including all X traffic and some NFS
traffic for diskless font service on the X terminal. The window
manager, twm, was running on the diskful server and not on the X
server. All X clients are running on the diskful server.
TEST pkts/sec kBytes/sec
maze 425 30
xterm tftpboot 303 92
twm:
move win 220 18
resize 220 18
hold button 220 18
plaid 220 17
ico 67 12
xbench 50 20
2 xtermwins cat'ing 45 23
xclock 0.0166-1 ~~
move mouse
out of win 3-5 pkts ~~
These numbers from the LANalyzer measure Ethernet frame data;
source and destination MAC addresses, protocol type field, user data
payload and CRC, but do not include the preamble or interframe gap.
For reference purposes, Ethernet at 10Mbit/sec can transfer
about 1,000 kBytes/sec of Ethernet data in maximum sized frames, after
subtracting the preamble and minimum interframe gap times. The
maximum number of Ethernet frames per second, assuming minimum sized
legal frames, is 14,880 frames/second.
These tests do not factor in the presence of routers between
the X terminal and server, nor do they account for the diskful server
load, given that the diskful server is bootloading, running all window
managers and all X client processes and all processes under the
clients (such as shells). These tests do not measure actual usage
patterns.
Those who really did the work:
Mike Amirault (ambi@bu-it.bu.edu)
Jason Heirtzler (jdh@bu-pub.bu.edu)
Chuck von Lichtenberg (chuckles@bu-it.bu.edu)
--------------------------------------------
From: droms@pollux.bucknell.edu (Ralph E. Droms)
I have co-authored a paper to appear "soon" in Software: Practice &
Experience that describes an X protocol bandwidth utilization tool,
and reports the results of several experiments in which we measure the
protocol usage of several clients across an Ethernet. We found:
* Some applications, like xdvi and xbench, may use as much as 15% of
an Ethernet in bursts.
* Mouse tracking through polling (e.g., twm click-and-drag) may
generate as many as 200 packets per second.
* Text-oriented applications like xterm and GNU emacs do *not* add
significant overhead relative to telnet and emacs-across-telnet.
We did not measure any serious drawing tools like CAD/CAM
applications. I would like to hear of suggestions for experiments we
might conduct. We did write a *very* simple polling program that
generates ~200 poll requests/second.
I'd also appreciate hearing of any other responses you might receive.
I know there was a paper this past year in Digital Technical Review
(perhaps summer 1990 - the reference is back in my office) measuring
diskless workstations generating DecWindows + distributed file system
traffic.
- Ralph Droms Computer Science Department
droms@bucknell.edu 323 Dana Engineering
Bucknell University
(717) 524-1145 Lewisburg, PA 17837
------------------------------
From: "Eric A. Anderson" <ea08+@andrew.cmu.edu>
The question of how much an application uses in bandwidth depends on
the application. On the other hand, I have succeeded in running
real-time games (such as Xtank) across the internet backbone, and it
hasn't seemed really bad(although it is noticable). The thing I would
suggest is getting the program xmon from expo.lcs.mit.edu, and running
your sample application through it, then look at how much of the
bandwidth is being used. Alternately, watch packet counts.
-Eric
--------------------------------------------------
From: santa@hemlock.cray.com (Dave Sadler)
I'm curious if you got any response to your e-mail request about X-Windows
network bandwith needs. We get asked this question occasionally and have
provided information about very specific examples. I would be interested to
see whatever info you were aable to collect.
The short answer to this question is that it depends entirely on what kind
of application is using X and how the application is using X Windows. Sounds
like a generic answer, but it is really true. It the application is trying to
chase mouse motion around, then X-Windows will be sending alot of mouse
position packets across the network. But, the application doesn't have to do
it this way. Instead, the application can let the server chase the mouse, then
send over a mouse postion packet when the button is hit. Another example is
where the application is trying to product real time animation - 20 frames per
second. But even in this case an Ethernet network could pretty much keep up
with one application cline/server pair doing this. A 512x512 8 bit color
window yields about 2 megabits of data (512x512x8) or about 262 eithernet
packets ( 2mb/8,000). Then doing this as fast as you can, can produce
reasonable animation sequences depending on what is being shown.
Our experience shows that the biggest bottleneck in this animation scenerio is
the CPU and memory speeds of the system creating the images and not the
network (if you can belive that). In this example, a SUN to SUN demo can
yield some pretty slow results, while a Cray to SUN can yield much better
results (and also max out the network). For instance, Cray-to-SUN over
Ethernet, memory-to-memory transfers rates can run in the 4 to 8 megabit
range. While the same over FDDI can run in the 10 to 20 Mbit range. With these
rates then, you can actually do color animation for one application client-
server pair.
Deputy Group Leader
Cray Research, Inc.
santa@cray.com
612/683-5879
--------------------------------------------------------------
From: ty@styx.desktalk.com (Tyson M. Kostan)
Your right on. We recommended 8 to 10 workstations per workgroup in the
environment we were working with. When doing our modeled stress tests, I was
finding a Sun 4/490 was starting to drop packets at about 380pps, where the
ethernet was starting to saturate (i.e. lots of collisions) at just over
500pps (I could convert pps to MBPS for you, but for the purpose of my model,
that wasn't necessary).
Interestingly enough, when testing Sun SLCs and comparing them to the NeXt
stations, it was quite obvious how well performing the Sun ethernet subsystems
can be. I could saturate the ethernet with 3 SLCs but it took about 8 NeXt
stations to do it. Oh well...
-------------------------------------
From: der Mouse <mouse@lightning.mcrcim.mcgill.edu>
> How realistic is it to run X sessions across the Internet?
I have a program that I regularly run on a McGill machine connected to
a display in Switzerland. The same program is occasionally used
running in Rhode Island displaying here at McGill. I sometimes have
terminal windows running at various distant places. I find latency
more important than bandwidth, unless you're doing something like
displaying pictures that involves shovelling large amounts of data
around.
> If one proposed to give people access to a resource by making a
> client available on a machine near a network hub, should one's
> proposal be dismissed out of hand?
Not for any reason related to what you've said so far. (There may be
other reasons for so rejecting it, such as administrative or political
reasons on the proposed machine, but that's another issue.)
> For 5 simultaneous users? 100?
It depends entirely on how many computrons the machine in question has
available and possibly also on the characteristics of its network
connectivity. (You probably don't want to annoy your regional net by
eating up large chunks of its bandwidth. And regardless of how fast
the machine is, if it hangs off a 4800bps SLIP line, you won't get
tremendous performance! :-)
der Mouse
------------------------------------
From: lupine!klein@uunet.uu.net
NFS and big file transfer apps (ftp, rcp, etc.) seem to have done an
incredible amount of damage to everyones' faith in Ethernet capacity
:-). This is a common misconception about X traffic. Turns out that
it (typically) fits very well into the Ethernet model, and rarely
taxes the cable at all. What we have found, as I mentioned above, is
that it *does* tax most U*IX systems interfaces and kernels.
There is an interesting article in last year's 'Digital Technical
Journal' (Vol 2, Number 3) on X traffic and the capacity of Ethernet.
It basically predicts that you won't see noticable degradation until
you reach numbers in the 200-300 range of active remote clients.
Assuming that most users only really use one client at a time, this
gives you a capacity well beyond what a normal networking person
would recommend per cable anyways.
As the X world ventures into the imaging and/or live video arena,
bandwidth considerations may come into play. Some of these concerns,
though, are being actively addressed by such things as XIE, the 'X
Imaging Extension'.
-----------------------------------
From: robp@anubis.network.com (Rob Peglar)
Just get yourself a bunch of ico's all going at once (helps to have
a graphics card on the client) and watch the packets fly.
-------------------------------------
From: lstowell@pyrnova.pyramid.com (Lon Stowell)
I can do a pretty good job of choking an Ethernet by running
Framemaker on a X-windows terminal...particularly just paging
through a document with (in order of increasing severity) drawn
images, imbedded postscript, or high-density bitmapped images in
it.
I have some images which take 500,000 (yes, half-meg) bytes PER
PAGE on Frame.
Our Ethernet can crank 700+ Kbytes with low station counts, but
these high-resolution documents really have response times that
are, IMHO, "less than optimal".
Copying a bitmap (in the process of composing a document) is
even worse.
Just about any profession publishing package with bitmaps over
X-windows can flood an ethernet. Have you tried the folks at
Moffet...for their color bitmaps of satellite or Magellan
photos? Frankly FDDI is too slow for X-window resolution and
color.
----------------------------------------------------
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
The "Verilog" simulator from Cadence seems to send a goodly number of
packets whenever you're using the "$gr_waves()" feature (which gives
you a logic-analyzer-like display of the variables in your simulation).
You might look at that one.
Also, there's a thing called "xperf" which comes with the X distribution
which runs a series of X functions and times them. (Sorry, I don't know
any more about it. See your local X-head...)
-----------------------------
From: shl!phil@uunet.uu.net (Phil Trubey)
I did a quick and dirty 'bandwidth benchmark' a few weeks ago to determine
how much bandwidth a typical X session takes up.
Following is a synopsis of what I did. Please keep in mind that I was
using an NCD X Terminal which was *not* blindingly fast. A faster X terminal
could easily double the bandwidth requirements (I would think). I'm going to
be performing these tests again sometime in the next few weeks with a fast
SparcStation acting as an X terminal to see what changes.
For those that don't want to wade through this, I found that I used about
68 kbps average bandwidth for screen redraws.
----
A series of tests were performed and the results analyzed. The test
environment consisted of a Sun 4/260 Unix computer on an ethernet along
with an NCD X terminal. A LAN protocol analyzer and a network monitoring
package was also attached to the network.
The protocol analyzer was set up to record all packets going to or
coming from the X terminal. The Ingres 4GL Windows environment was run
on the Sun computer with all output being directed to the X terminal.
A sample Ingres Windows/4GL database application was run under the
Motif window manager during the tests.
Four sampled tests were conducted:
- Initiation of the application program. This involved invoking the
application through a pull down menu. The application drew a full screen form
consisting of about 10 buttons, 3 scroll bars, 15 boxes, and 20 text fields.
This is a fairly representative X window database form. The test stopped
after the form had been completely drawn.
- Data entry. Using the above form, the test caught about 1.5 minutes of
fairly rapid data entry activity which included entering text and numbers,
checking boxes, and pressing buttons. Part of the test included pressing a
button that displayed a 1/2 screen size pop up window with a histogram
displayed.
- Switching between two windows. This test caught the activity that was
generated when switching between two large and complex windows.
- Switching between multiple windows. This test caught the activity that was
generated when switching between multiple windows in rapid succession.
Results
Following are the outputs of each test (the times are measured in seconds,
and the network utilization in kilobits per second):
awk -f awk.prg form.txt
Total bytes: 240554 Total time: 34.92 Avg utilization: 68.89 kbps
awk -f awk.prg entry.txt
Total bytes: 281998 Total time: 96.70 Avg utilization: 29.16 kbps
awk -f awk.prg switch.txt
Total bytes: 25630 Total time: 6.65 Avg utilization: 38.54 kbps
awk -f awk.prg switch2.txt
Total bytes: 107276 Total time: 30.24 Avg utilization: 35.47 kbps
-------------------------------------------
From: ckollars@East.Sun.COM (Chuck Kollars - Sun Technical Marketing - Boston)
I tried to run some benchmarks, and found it really is true that there is no
such thing as a "typical" X application. For applications that are constrained
by typing speed (ex: Frame), I could get a lot more clients on one Ethernet than
I thought -- several tens, probably less than 100. _With_today's_applications_,
the worry about X overloading an Ethernet appears to be "greatly exxagerated".
Turns out most CAD applications aren't bad. X does a reasonable job of
compressing instructions to draw simple geometric figures (e.g. straight lines
and circles). Since most CAD pictures are actually built up of very simple
items, they compress fairly well. The limit is usually either the drawing speed
of the server or the processing speed of the client, not the Ethernet itself.
Do something that manipulates a bit map. Medical imaging is a good one. The _best_
thing I can think of is to get a 24-bit deep true color image of the "Mandrill",
blow it up to near full screen size, and then resize the window it's in. You'll
see the yellow insulation melt right off your Ethernet cable.
-----------------------------------------