[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

1940.0. "Counter creation time." by COMICS::MISTRY () Fri Dec 13 1991 12:49

I have a simple question regarding BMS V1.1 and counter creation time. If you 
issue the following command from FCL:

MCC> zero node4 xxxx line bna-0 <cr>

This will zero the bna-0 line counters and create a counter creation time 
indicating when the counters were zeroed. If you then monitor the line counters
every minute

MCC> show node4 xxxx line bna-0 all counters, at every 0:01 <cr>

The counter creation time should remain the same for each sample period. This 
however is not true, it seconds and hundreths seem to vary ie 1 sample it will
show : xx:xx:04.70 and then next sample it shows xx:xx:03.98 etc. This isn't so 
bad but i believe it is considerably worse for the DECELMS access module.

I don't think this is a major problem, just a rounding up or down problem, 
however i am wondering whether the problem exists in BMS V1.2 as well.

Bipin.

T.R Title User Personal
Name Date Lines

1940.1 DECmcc ELM CCT CHRISB::BRIENEN DECmcc Bridge|Station|SNMP Management. Fri Dec 13 1991 15:54 31

T.R	Title	User	Personal Name	Date	Lines
1940.1	DECmcc ELM CCT	CHRISB::BRIENEN	DECmcc Bridge\|Station\|SNMP Management.	`Fri Dec 13 1991 15:54`	31
	>The counter creation time should remain the same for each sample period. This >however is not true, it seconds and hundreths seem to vary ie 1 sample it will >show : xx:xx:04.70 and then next sample it shows xx:xx:03.98 etc. This isn't so >bad but i believe it is considerably worse for the DECELMS access module. > >I don't think this is a major problem, just a rounding up or down problem, >however i am wondering whether the problem exists in BMS V1.2 as well. Counter Creation Time for Bridge AM and Concentrator AM (and Node4, too) is calculated from the Second Operating (or SSLZ) attribute. Several problems exist around getting a consistent CCT value: 1. [Current Time - Seconds Operating = Counter Creation Time]. Current timestamp is, for V1.1, taken at the AM. In V1.2, we're going to use the one generated by the MCC_EA Routine (obviously closer to time packet received). This reduces the problem somewhat (it certainly did for Ethernet Station). 2. Units for Seconds Operating is seconds (surprize!). Current time is good to hundreths. CCT carries the hundreths as well. 3. The Seconds Operating for DEC's Bridges is known to drift over time (I seem to recall something on the order of a few seconds/week). Conclusion: the "problem" exists in V1.2 as well (though CCT will be more accurate for Bridge, Concentrator, and Ethernet Station). Chris

>The counter creation time should remain the same for each sample period. This 
>however is not true, it seconds and hundreths seem to vary ie 1 sample it will
>show : xx:xx:04.70 and then next sample it shows xx:xx:03.98 etc. This isn't so 
>bad but i believe it is considerably worse for the DECELMS access module.
>
>I don't think this is a major problem, just a rounding up or down problem, 
>however i am wondering whether the problem exists in BMS V1.2 as well.

 Counter Creation Time for Bridge AM and Concentrator AM (and Node4, too)
is calculated from the Second Operating (or SSLZ) attribute.

 Several problems exist around getting a consistent CCT value:

	1. [Current Time - Seconds Operating = Counter Creation Time].
	   Current timestamp is, for V1.1, taken at the AM. In V1.2,
	   we're going to use the one generated by the MCC_EA Routine
	   (obviously closer to time packet received). This reduces
	   the problem somewhat (it certainly did for Ethernet Station).

	2. Units for Seconds Operating is seconds (surprize!).
	   Current time is good to hundreths. CCT carries the
	   hundreths as well.
            
	3. The Seconds Operating for DEC's Bridges is known to
	   drift over time (I seem to recall something on the order
	   of a few seconds/week).

 Conclusion: the "problem" exists in V1.2 as well (though CCT will be
more accurate for Bridge, Concentrator, and Ethernet Station).

						Chris