Conference 7.286::fddi

What is the topology of the extended LAN?  Will you be placing the VT1000s
on the LAN in such a fashion that their traffic must always traverse the
backbone?  The handling of the VT1000s should not be much different than
the addition of workstations that are either members of a VAXcluster or
that are accessing the majority of their storage via NFS.

Looking beyond the VT1000s, what growth do you expect to see?  If the future
growth is not clear, you may be able to afford a lot of reconfiguration
of your current extended LAN for much less than the cost of FDDI hardware.
As an example, Spitbrook managed to survive for years without FDDI with a
load much greater than 40 VT1000s.  On the other hand, if you expect to
see a significant increase in traffic overall, then perhaps it makes sense to
incorporate FDDI sooner, buying DECbridge 500s instead of LANbridge 200s at
about 6 times the cost.

    Topology......one segment extending thru 4 SER's and one segment
    thru two computer rooms, each segment connected via LANbridge100.
    The VT1000's will be located in office's which are connected to
    the various SER's.
    
    Growth at this point in time is unclear.  I'm monitoring my
    segments with LTM, and am wondering at what point I should
    begin to be concerned about traffice load...40%, 60%----->??

    in response to .1's reference to the Spitbrook LAN, I remember a
    paper by John Lewis called "Measurement of a Large LAN" which
    effectively described utilization statistics for that LAN.
    
    Now that client-server computing is becoming much more prevalent
    (DECwindows applications, X-terminals, PCSA, etc...), the traffic
    model has changed considerably from those Spitbrook days 3 years ago.
                                                         
    Any pointers to similar measurement papers in today's client-server 
    environment that is able to be passed onto customers?
                                                 
    					Thx, Stan

Well, the Spitbrook LAN has always functioned in something of a `client-server'
fashion.  We started out with the mail clients sending mail to the mail servers
that delivered it to the users.  We had the file transfer clients that used
moved files to and from file servers, and a major specific catagory of file
server in Spitbrook was the kit servers - they served up terabytes of data.
Then there were the notes clients and notes servers.  And then finally there
were the LAT servers and clients.

Then NI based VAXclusters entered the picture.  The VAXcluster model is one
of VAX computers accessing MSCP storage servers.  The boot nodes are the
MSCP servers in most cases, and they are seen by the clients as being only
slightly different than HSC which are classical special purpose disk servers.
The NI load jumped by orders of magnitude.  NFS has entered the picture, but
I think that by and large, the majority of these systems use local system
disks and consequently are not as heavy a load as VAXclusters.  The same is
true for PCs.

The next major technology is going to be the data that feeds the window systems.
X Windows is beginning to have its impact, but the major change is going to
be the applications that use images, whether computed or scanned.

  Up to this point everyone has been discussing the distribution of the 
window servers (VT1000). 

  Eventhough you distribute the VT1000s out over many Ethernets around an FDDI.
If the client system(s) is on a single Ethernet (we currently have no means
to put this system on the FDDI) the traffic level on this network will be the 
sum of all of the servers traffic.

  When we get the server systems (or window clients) on the FDDI then we'll
be in "Fat City".

  regards

	RE: .2

>    Growth at this point in time is unclear.  I'm monitoring my
>    segments with LTM, and am wondering at what point I should
>    begin to be concerned about traffice load...40%, 60%----->??

	I'd say you should start to be concerned when load tries to
	exceed 60%.  Many of our older NI adapters just don't function
	very well above that level and the rate of collisions, even for
	the newer adapters, is starting to take a bite out of through-put.

    
    	If you have traffic hovering over 40% on a consistent level, its 
     a good idea to analyze what the traffic is actually doing rather just
     look at the over all utilization figure. Maybe you can "tune" your 
     Ethernet. For instance if you are running RSM backups on an 8800
     on Node A connected to Segment X and backuping a 100 microVAXen on 
     Segment Y, you should move Node A on to Ethernet Segment Y. Of course
     all this is based on how the LAN is configured and where is the traffic
     really going. Also characterize the types of user communities which 
     will move in or out of your particular facility (i.e. CAD people, people 
     using TCP/IP, Imaging, Large LAVC's or MIVC's ??) ? All this data once 
     collected (not a small task) should give you a better idea what your 
     growth will be.
    
    								Rene'