[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

5304.0. "GIGAswitch & *****mcc" by DAGWST::SITZ () Tue Jul 06 1993 14:03

Sandia National Labs, Livermore California is a Beta test site for the
GIGAswitch.  One of the goals of this Beta test program is to examine the
behavior of a GIGAswitch when a serious load is applied.  Toward this goal,
the following configuration is being used for testing:

1)   1 GIGAswitch with 11 two-port line cards
2)  10 DEC AlphaAXP upgrade systems (AKA DECstation 5000/133)
3)  10 SGI Iris 4000's
4)  10 IBM R6000's
5)  10 SUN Sparc 10's
6)  10 HP workstations (I don't know what model)
7)   1 DECstation 5000 running POLYcenter Network Manager V1.3
8)   9 DEC FDDI concentrators

Sandia personnel have written some programs and shell scripts to initiate data
transfers between individual systems, a vendor specific pair at a time or all
at once.To date, "base rate" tests have been run between pairs of like systems to
determine the memory to memory transfer rates each vendor's systems could
achieve on an idle FDDI network. There are two modes for this testing.  The
first mode will cause traffic between individual pairs of systems on an idle
FDDI network; the second mode will run between two like systems seperated by the
GIGAswitch.  A comparison of the two sets of results from these tests (actually
10,000 iterations of each test) should yield a measure of GIGAswitch induced
latency.

A second set of tests uses a Sandia written program to start the transfer of
data through the GIGAswitch between 25 pairs of workstations.  In effect, this
produces 25 pairs of machines doing memory to memory transfers via the
GIGAswitch. Each test runs a little over 70 seconds.  The intent here is to
study the performance of the GIGAswitch in a high traffic condition.

Data from most of these tests has been collected and will be analyzed over the
next week or two.  As results become available I will add replys to this note.

Now for the questions:

	If you had this configuration and any Polycenter products you wanted,

		1. Which products would you configure?
		2. What alarms would you use?
		3. What information should I trap/export/record/graph... to show
		   how well Polycenter*** will work to monitor high performance
		   networks?

Regards,

Glen R.

T.RTitleUserPersonal
Name
DateLines
5304.1Alarm rules for GigaswitchCUJO::HILLDan Hill-Net.Mgt.-Customer ResidentWed Aug 18 1993 01:4130
    Glen,
    
    What can be monitored by the Network manager is largely dependent on
    what the agent on the gigaswitch is providing.  Engineering is working
    on adding some suggested MIB objects.  Please make your requests known
    to them if you have additional requirements from customers.
    
    Here are some examples of MIB variables to watch:
    
    dec ema sysobjid bridges GIGAswitch GIGAversion1 gigaBox psc pscStatus
   
    dec ema sysobjid bridges GIGAswitch GIGAversion1 gigaBox psc
    	pscBackplaneStatus
    
    dec ema sysobjid bridges GIGAswitch GIGAversion1 gigaBox psc
    	cabinetTemperature
     
    dec ema sysobjid bridges GIGAswitch GIGAversion1 gigaBox psc
       	rightPowerStatus
                
    
    
    As far as performance is concerned, there is not much provided by the
    current agent on the Gigaswitch that will give you an idea of what's
    going on.  You get things like total packets received, but there is no
    "rate" info available from the agent and DECmcc does not allow you to
    perform complex alarm expressions, so you're out of luck until the
    agent is modified.
    
    -Dan