Conference bulova::decw_jan-89_to_nov-90

    The most troubling aspect of your question is:
    
    ``What  will  the  impact  on  performance  be   if  we  have  say  300
    workstations  connected  on Ethernet all running DECwindows with  their
    client running on a big VAX?''
    
    I'd be concerned that the big VAX had sufficient  capacity  to  provide
    the  needed responsiveness.  I don't believe that the network  will  be
    the limiting factor in the system, especially if the big VAX  has to do
    compute  intensive  activities  for  each of the 300 users.  I'd better
    quantify the  application  - for instance how many terminals are active
    concurrently.  What  are  the  usage  patterns  for any given terminal.
    What is the expected  level  of  interactive feel?  What is the maximum
    time allowed for updating the  screen or servicing a request?  I really
    don't think that the network capabilities  are  an  issue  until  these
    other questions are answered.
    
    When a configuration is found which meets  the  performance criteria of
    the  application, I believe that you will find  that  simply  following
    good  Ethernet design rules (installing bridges, isolating high traffic
    areas from the backbone, etc.) the Ethernet will be more  than adequate
    for the application. 
    
    You  might  want  to  mention  the  experiences  that  we  have here in
    Spitbrook (which  is  rumored to be the most densely populated Ethernet
    in the world).  The network here has over 2048 nodes in 3 DECnet areas,
    all attached to a  single logical network.  The topology is critical to
    making this environment work.   The  basic design is that each floor is
    isolated from the backbone of the building  via  a  briged and that the
    backbone of each of our three buildings is  isolated from each other by
    a bridge.  Also key to making this environment  work is the locality of
    traffic.    Resources  that  need  to  exchange messages frequently are
    placed on  the  same  side  of the bridges (for instance all nodes of a
    LAVC must reside  on the same side of a bridge).  The message is clear,
    following good network design will  provide  good  performance.    This
    starts by completing a network survey  and  understanding  the  traffic
    patterns.
    
    Still before you attempt to answer the  network  question,  you need to
    get a good understanding of the application.
    
    James
    

    In addition to the comments in .1, remember that no Ethernet adapter is
    capable of running at full Ethernet capacity.  So if you have only one
    "big VAX", then its Ethernet adapter will be a problem long before the
    wire itself.
    
    This may not be the best news you wanted to hear, but such is life.
    Perhaps you could also ask in MOUSE::ETHERNET, sometimes there are
    technical reports on this topic and the readers there may be better
    able to answer that part of your inquiry.
    
      John

I doubt you could run 300 users's applications off a single "big VAX".  You'd
need several of them.  As far as ethernet traffic goes, strategic use of bridges
can keep this manageable.  The ZK ethernet runs with at least that much load
all the time.

--PSW

I've heard of situations where hundreds of users have had to share an 11/780...

I have done some non-systematic testing and have found that with DECnet you
see about 3-6 packets per second averaging about 100 bytes per active
workstation with the majority of the applications remote.  So, if you use that
as the mean load with activity, then 300 users would be offering 180,000 bytes
per second and 1800 packets per second to the Ethernet and would seen some
noticable service degradation.  I beleive tho, that the delays caused would
result in fewer, but somewhat larger packets per second, so this traffic
would not result in instability of the network.  If you assume that the
users are only likely to offer this load 50% of the time (a very high average)
then the probability that all 200 users were offering this load would be very
small and the upper bound on network load would be around 120,000 bytes (which
is 100% utilization of an Ethernet), so while I wouldn't recommend building
a single system in this fashion I wouldn't be surprised if it worked.

It is important to note that 300 workstations doesn't necessarily mean 300 users
using the system.  A number of years back I monitored the ZK Ethernet (before
workstations and LAVCs) and based on the number of terminals and offices,
estimated that the average user typed 10 characters and read 100 characters
per minute.  The only reasonable explanation is that the majority of users
were not at their terminals, but were instead in meetings of one sort or another.

If the 300 workstations were being used for data entry or telephone order
processing, then I'd worry, but for engineers and managers doing a normally
days work, I'd guess that the load won't be much worse than for LAT.

I will note that I said much the same about the load situation in ZKO a number
of years ago.  For a long time, there was considerable concern about overloading
the ZKO Ethernet with LAT traffic, but that never happened.  In fact, for quite
some time ZKO got along fine with a single Ethernet segment and I questioned
whether the predicted load would ever arrive.  Then in the span of 6 months,
the load reached almost crisis conditions, partially due to LAVCs, but also
due to DECnet and QNAs that couldn't handle more than 20% load and so on.
The point is that things can change very rapidly, so beware of any absolute
answers.

    re .3: ``I doubt you could run 300 users's applications off a single
    "big VAX".''

    Not even a VAX 8978?  (I know it's really a cluster.)

    re .4:
    
> small and the upper bound on network load would be around 120,000 bytes
> is 100% utilization of an Ethernet), so while I wouldn't recommend building

    120KBps -> .96Mbps
    
    Isn't that more like 10% utilization?

re:.6

Thanks.  I thought that the load shouldn't be a problem on the Ethernet, but
I was tired and not thinking straight so I shifted digits too far.  I couldn't
figure out why a load that wasn't much greater than LAT was overloading the
Ethernet...

So that makes the whole thing much more reasonable all around.