Conference azur::mcc

As you've correctly observed, Counter Creation Time (CCT) is being calculated
from Seconds Since Last Zeroed (SSLZ).

Note that the Ethernet STATION calculates CCT in the same way for DEC_ENETV2
(MOP V3) stations. So does Terminal Server AM.

It's just one of those things...

						Chris

P.S. What are your thoughts on this?

    Hi, Chris..
    
    Thanks for the reply.
    
    Its good to get my ideas confirmed!!!
    
    As to what I think of it, I don't like it.
    Before I realised what was happening yesterday, I spent a lot of time
    trying to understand why there had been three circuit down events on
    one end of a synchronous circuit since 19:00 the previous evening and
    28 circuit down events at the other end since the same time!!
    particularly as OPCOM has not reported any.
    
    In my opinion, AFTER the number of seconds since zeroed has latched the
    Counter Creation Time should be displayed as NOT RETURNED or some such
    thing.
    
    I agree that zeroing counters on a timed basis would stop this being a
    problem but even so...
    
    Rgds,
    Graham
    

    I agree with Graham - if you can't calculate an ACCURATE value for CCT
    then you should either not return it, or return an indication that the
    value is not known.
    This was discussed with Jim Carey a long time ago.
    
    A client of any AM should be able to make the following assertions
    about counters:
    	- if you have two observations with the same CCT, then you may
    	  'relate' the associated counters (for example, you can subtract
    	  one from the other (modulus, if wrapping counters) and divide
    	  be the time difference, to yield a rate)
    	- you may divide any counters by the difference between the time
    	  stamp and the CCT to get a rate since the counters were
    	  initialised.
    
    Obviously, an erroneous value for CCT won't mess up case 1 above, but
    will mess up case 2, as mentioned in previous replies.
    

    The facts of life in the world of phase iv decnet include the counter
    feature - it's something like 18.2 hours where it latches - so your
    stats are bogus - with home grown tools I've seen - the stats were
    done with the 18.2 hours and marked with a * to signify that a latch
    had occured - if the counters were latched - the 'seconds since zeroed'
    counter showed a *.  Don't think about not returning the values... just
    mark them with a taint - 
    
    bill
    
    

From the DEC_ENETV2 Station perspective:

 SSLZ latches at 65535. 
 We will return SSLZ, even if it's latched (hoping that the user is savvy
 enough to recognize the magic number).

 CCT is calculated from SSLZ.
 It is not obvious (given current behavior) to someone looking just at CCT
 that it is correct/incorrect.  

 The fix (DEC_ENETV2):
 If SSLZ is less than 65535, CCT will be calculated and returned.
 If SSLZ is 65535, CCT will NOT be calculated:
    either 1) CCT will NOT be returned (predictable=false)
        or 2) CCT will return with ReasonCode = Attribute Not Available.

 Anyone have strong feelings about the above (other than "fix it")?

					Chris

 
 

This problem, for STATION, has been QAR'd against Ethernet AM.

Fix will be to NOT RETURN CCT when SSLZ latches.

Fix should appear in the X1.2.4 kit.

						Chris

    
    
    Hi, just woke up and noticed you were talking about me.  DECnet Phase
    4.
    
    I have discussed this with Colin and Chris recently.  I buy Colin's
    second argument above -- that essentially the CCT should have some
    validity when it appears and and if we can't be pretty sure that it
    makes sense, we should just leave it out.
    
    My mind is halfway through a timewarp -- at one time we discussed this
    in a slightly different way -- and expected FMs to recognize over a
    sample interval that the CCT has changed, and thus the counters are
    suspect.  The second reason quite reasonably makes that thinking
    obsolete.
    
    For some reason, it was requested that I make the DNA4 CCT Predictable.
    Is it predictable enough to return it with "Attribute Not Sensible" or
    whatever it was that Chris is doing with the Bridge?
    
    I will QAR this against DNA4, and we'll get it fixed as soon as
    possible.
    
    -Jim Carey.
    

    
    
    Oops.  Just reviewed this.
    
    What does make sense?
    
    Chris is planning to not return CCT?  Will this break anybody?
    PA is a popular consumer.
    
    We do want to be as consistent as we can.
    
    -Jim Carey

If you have historical data available to you, you can compute an accurate
CCT value, just read back in time until you find a case where the SSLZ<65535,
and use that to decide when the counters were *really* last zeroed.
Watch out for the case where two "reads" of the counter were more than
65534 seconds apart, it is *possible* the counters were zeroed at the start
of that period, and you missed it.

PA's normalize code *ought* to have lots of algorithms for deciding when
counters might have been zeroed.

Mark