Conference netcad::hub_mgnt

> If I want to see traffic utilization of FDDI then what version of HUBwatch
> we can expect??

In HUBwatch version V3.0.  Coming soon.

Tom H
HUBwatch

    HUBwatch V3 will support FDDI utilization. The hardware modules will
    require a MAC-3 chip to get the raw data, the first rev's of the FDDI
    concentrator will have MAC-2 chips in them and then be phased over to
    MAC-3. This is due to chip availability from the vendor. The hardware
    will be self describing and the software support is latent so when
    the right chips show up FDDI utilization should just happen. We
    will try to get the word out when the new chips roll out of
    manufacturing, the field should not there is not a plan to upgrade
    boards with MAC-2 to MAC-3.
    
    Bruce

    The DECbridge 900MX (WGE200) uses the MELMAC chip which has MAC-3
    inside, so the bridge can already be used to obtain FDDI Utilization.
    
    The DECconcentrator 900MX initially used the MAC-2 chip but will be 
    shipping with the MAC-3 chip shortly.  If you try to measure FDDI
    utilization and the feature is not available, HUBwatch will grey out
    the information.
    
    Dave.

How is FDDI utilization calculated anyway?  (Previous versions kept
an FDDI MIB object, "blahFrameCount" which was useless because it counted
void frames.  I'm wondered if the additional instrumentation suffers from
the same problem.)
						-Shawn

	You need to know the ring latency (D) and the token count.
	Both are kept by MAC3.  The equation is

	utilization = 1 - mD/T

	m is the token count (how many tokens seen in T time units)
	D is ring latency in time units

	So for example, m = 50000 tokens in 1 second and ring latency
	of 10 usec means you have 50% utilization.

	But void frames still are involved here.  On a big ring with
	lots of traffic they become insignificant.  But on a small ring,
	with Ring Purger on and little "real" traffic, the utilization
	number is MEANINGLESS.

	So if you need to look at utilization I would turn the Ring Purger
	OFF (at least while you do the calculation.)  But Ring Purger has
	to be turned off on ALL DEC equipment on the ring.

	Luc

>               <<< Note 638.4 by LEVERS::BENSON "DTN 227-3555" >>>
>                         -< Bridge now, Conc soon... >-
>
>    The DECbridge 900MX (WGE200) uses the MELMAC chip which has MAC-3
>    inside, so the bridge can already be used to obtain FDDI Utilization.

I was told that "attribute not gettable" or some such messages returned
when accessing the token counter.   What firmware version be required?
Anyone has tried this before? 

Thanks,
_Tak

    FDDI utilization is supported since 1st ship of DB900MX - both
    the token ct and ring latency objects.  HUBwatch uses these
    in showing the utilization "meter" on the FDDI screen.
    (Note that this utilization includes the bandwidth taken up by
    void frames - thus it is advisable to disable ring purger on all DEC
    stations on the FDDI.)
    
    Anil

Re: .-1

ELAN MIB 2.9 has it..  We are now sampling traffic data from Bridge900 as
a trial.

One question.  The RingLatency uses a void frame according to the MIB below.  
What void frames do you use to measure the latency while having Ring Purger 
off?

_Tak
 
    eMACRingLatency OBJECT-TYPE
        SYNTAX  INTEGER
        ACCESS  read-only
        STATUS  mandatory
        DESCRIPTION
               "The total ring latency in 1 nanosecond units, as measured
               by the amount of time that it takes to receive back a void
               frame transmitted by the MAC chip.  Note that implementations
               that do not have the capability to measure the ring latency
               will not return this object."
        ::= { efddiMACEntry 22 }

Follow-up questions -

1.  RingLatency data measured by MCC shows some drift.  When graphed, it 
    looks as if there are three horizontal bars: centered at ~17.050us, 
    drifted +/- ~.100us from the center.   
    Data is taken every 10minutes that makes 10minutes average.  The ring 
    in question has two DECnis and two DEChub900s.  

    Can this drift happen on rings?  Or something wrong with the
    measurement?  -- The ring purger is being disabled (so have been told).

2.  There is a topic in the FDDI notes (UPSAR::FDDI, 1186.*).
    My interpretation of the topic is that SNMP counters of the concentrator 
    only reflect the traffic to that concentrator (addressed to it:
    ie, SNMP packets, ping traffic to it). Other traffic that's just
    passing thorough is not counted. 

    Has Concentrator900 the same behaviour? -- when graphed interface 
    counter (in/out), it shows ~5% at some peaks and close up to ~2% on 
    average.  I wonder if SNMP or ping communication can make the traffic 
    that high.

It is our first experience to approach FDDI utilization and throughput
measurments.  We want to know if our observation is what we should see.
Any advice or hints would be very much appreciated.
  
Thanks,
_Tak 

As a foot note, .9 and .10 are also posted to the FDDI notes file, #1405
that points back to this topic for continuation.

_Tak

>1.  RingLatency data measured by MCC shows some drift.  When graphed, it 
>    looks as if there are three horizontal bars: centered at ~17.050us, 
>    drifted +/- ~.100us from the center.   
>    Data is taken every 10minutes that makes 10minutes average.  The ring 
>    in question has two DECnis and two DEChub900s.  
>
>    Can this drift happen on rings?  Or something wrong with the
>    measurement?  -- The ring purger is being disabled (so have been told).
    
    Firstly, it appears that you are looking only at ring latency for
    utilization.  You need two variables and crunch them with the formula
    described in the earlier response .6.  The other variable is token
    count, fddimibMACTokenCt I believe, in RFC-1512.  The drift you
    are seeing is less that 0.5% which isn't all that much.
    
>    Has Concentrator900 the same behaviour? -- when graphed interface 
>    counter (in/out), it shows ~5% at some peaks and close up to ~2% on 
>    average.  I wonder if SNMP or ping communication can make the traffic 
>    that high.
    
    Yes, DC900MX has the same behaviour.  If you graphed the sum of
    ifInOctets and ifOutOctets against 100 Mbps, then that means
    2 to 5 Mbps of management traffic which looks a little high.
    If you graphed the 4 packet counters, then your throughout should
    be measured in pps (ie, % doesn't mean much in the case of
    throughput, typically only utilization is measured as % bandwidth).
    In any case, you can't get the FDDI throughput from a DECconcentrator
    since it counts only management traffic destined to it.
    
    Anil

>                       <<< Note 638.12 by NACAD::ANIL >>>
    
>    Firstly, it appears that you are looking only at ring latency for
>    utilization.  You need two variables and crunch them with the formula
>    described in the earlier response .6.  The other variable is token
>    count, fddimibMACTokenCt I believe, in RFC-1512.  The drift you
>    are seeing is less that 0.5% which isn't all that much.

The related variables were also taken.  I refered to the performance 
chapters of Raji Jain's book.  Utilization graphs (after crunching them) 
looked very different from what I expected. Therfore I first asked about 
the latency drift.

    
>>    Has Concentrator900 the same behaviour? -- when graphed interface 
>>    counter (in/out), it shows ~5% at some peaks and close up to ~2% on 
>>    average.  I wonder if SNMP or ping communication can make the traffic 
>>    that high.
>    
>    Yes, DC900MX has the same behaviour.  If you graphed the sum of
>    ifInOctets and ifOutOctets against 100 Mbps, then that means
>    2 to 5 Mbps of management traffic which looks a little high.

Not the sum.  Both.  The sum shows 7% of peaks. 

>    In any case, you can't get the FDDI throughput from a DECconcentrator
>    since it counts only management traffic destined to it.
    
I see.  Seems we need to review the way of sampling and/or crunching.

_Tak

PS. The FDDI Notes file mentioned earlier has two replies to my questions, 
one from Paul Koning and the other from Luc Pariseau, which are basically the 
same as Anil's.  Regarding void frames, the latency is measured with either
void frames of Bridge Strip Mode or of Ring Purger.

>>    Yes, DC900MX has the same behaviour.  If you graphed the sum of
>>    ifInOctets and ifOutOctets against 100 Mbps, then that means
>>    2 to 5 Mbps of management traffic which looks a little high.
>
>Not the sum.  Both.  The sum shows 7% of peaks.
    
    There are two things that people are usually interested in --
    utilization and throughput.  Utilization is a % of bandwidth,
    expressed either as a percentage or Mbps.  In the case of FDDI
    this can be computed from the two variables we've talked about.
    In the case of Ethernet, you can use the total byte count (rcv+xmit)
    and compute it as a percentage of 10 Mbps - however this is useful only
    on a promiscuous device such as a bridge which receives ALL traffic
    on the LAN.  What I'm getting at is that since you already
    have the utilization on the FDDI, there isn't much point in looking
    at octet count (even on a bridge, for example).
    
    Throughput usually refers to packets per second.  Clearly, for
    a given throughput measured in pps, a large average packet size would
    result in a larger utilization than a smaller packet size.  This is
    a useful statistic since network interconnect devices are typically
    limited by pps rather than Mbps.  From a LAN monitoring point of view,
    util. is useful to see how much bandwidth is available.
    
    Using your concentrator, if you want to see throughput then you
    couldn't use the interface packet counters since as explained they count
    only mgmt traffic.  However if the ring purger is turned off on all
    DEC devices on the ring then you can use RFC1512's fddimibMACFrameCts
    to compute the throughput for useful (that is, non-void) traffic.
    By the way, you don't need to do this manually if you have HUBwatch -
    it computes both the FDDI utilization and throughput using these
    guidelines.
    
    Anil

I(we) am in a network management services unit and have fairly alot of
experience on Ethernet (segments) utilization analysis. 

FDDI utilization analysis is new to us, since it is a token ring:
how utilization graph should look like in comparising with (ring)
network load, and what we should read from it.
  
>    By the way, you don't need to do this manually if you have HUBwatch -
>    it computes both the FDDI utilization and throughput using these
>    guidelines.
    
Do you mean the speedmeters?  _That_ small ones?  ;-)
If I'm not mistaken HUBwatch still lacks of historical recording features 
for a short term (eg, a week) and a long term analysis, which is what we
are trying to reach with NMS.

_Tak