| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 654.1 | Past Time Show | TOOK::SHMUYLOVICH | | Thu Jan 24 1991 10:35 | 57 |
|
> I am recording counters of a particular entity every 5 minutes from
> the beginning of the day.
>
> I then try at noon to SHOW these counters specifying
> SHOW <entity> ALL COUNTERS, FOR EVERY 0:5:0 UNTIL <date>:12:00
> START=<date>:10:00, IN DOMAIN <mydomain>
>
> To my surprise I got the counters which I recorded yesterday afternoon.
>
> Is this a bug ?
How Information Manager process Past Time scope of interest?
In SRM section 6.3.2 Information Manager we can find:
"If the scope of interest is totally in the past ... directives ... are
converted into mcc_mir requests for historical entity information....
The time value is copied into the mcc_mir lookup_time parameter and an
mcc_mir call is made."
From the description of the lookup_time_start argument of mcc_mir_read_attr_data
(chapter 11 page 719):
"... if both lookup_time_start and lookup_time_end are specified, then all
records within these time instants will be returned, as well as the record just
before and the record just after the time range...If only lookup_time_start is
specified <<this is your case because you did not specify duration>>... then
only the attribute records which are closest to this time instant are returned
(just before and just after, or exactly matching)."
Let's assume that:
H1-H5 - time when historical data have been recorded;
R1-R4 - request time for historical data.
R1 R2 R3 R4
------H1---------v--H2--v--H3--v--H4---v--H5-------KS---->time
NOW
For R1 you will have data H1 and H2, for R2 - data H2 and H3 and so on.
In your case, I think, "the beginning of the day" was slightly after <date>:10:00
and you got the latest data from the previous day as well as the earliest data
from today.
> Second question.
> Is there a possibility to analyze a posteriori which points were
> recorded in the MIR, for which entities, and for which partitions.
These functions are on our list, unfortunately, I don't think that they will be
available in the V1.2. Of course, if feedback from users shows that these functions
are very important (I think they are) we'll try to implement them earlier.
Sam
|
| 654.2 | Log of the TIME problems. | KETJE::PACCO | | Fri Jan 25 1991 07:10 | 78 |
| I agree with the MCC logic, but I expressed myself not enough clearly
in note 654.1. The following LOG will clarify this.
Note that the counter data was removed from the log, in order to
concentrate on all TIME specifications:
--> recorded time : every 5 minutes
--> time limits of the MCC request
--> interval of the MCC request ( 20 minutes)
--> resulting times.
I request something for the 24th January, I get it from the 23th
This does not seem right !!!!!!!!
The system time during the tests was about 25-JAN-1991:12:00
do [mcc.mcc]x.x
!%MCC-S-VERIFYENTER, entering command procedure DISK$SYSTEM_2:[MCC.MCC]X.X;30
!show node4 brsr4 circ syn-1 all counters, for every 0:20:0
until 24-jan-1991:15:00 start = 24-jan-1991:14:00, in domain routers
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 13:55:12 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 19:42:57.68
! Seconds Since Last Zeroed = >65535 Seconds
! Terminating Packets Received = 299 Packets
! ... data removed
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 14:00:12 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 19:47:57.67
! ... counter data also removed in all next displays
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 14:15:12 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 20:02:57.73
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 14:20:12 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 20:07:57.78
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 14:35:14 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 20:22:59.57
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 14:40:13 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 20:27:58.15
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 14:55:13 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 20:42:58.69
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 15:00:12 Counters
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 20:47:57.77
!%MCC-S-VERIFYEXIT, exiting command procedure DISK$SYSTEM_2:[MCC.MCC]X.X;30
!
use logging off
!
|
| 654.3 | Log helped a lot | TOOK::SHMUYLOVICH | | Wed Jan 30 1991 09:38 | 34 |
|
RE:.2
> I request something for the 24th January, I get it from the 23th
> This does not seem right !!!!!!!!
You get data not from 23th but from 24th.
Let's look at your log:
!show node4 brsr4 circ syn-1 all counters, for every 0:20:0
until 24-jan-1991:15:00 start = 24-jan-1991:14:00, in domain routers
!
!Node4 brsr4 Circuit syn-1
!AT 24-JAN-1991 13:55:12 Counters <-- THIS IS A TIME STAMP !!!
!
!Examination of Attributes shows:
! Counter Creation Time = 23-JAN-1991 19:42:57.68
! Seconds Since Last Zeroed = >65535 Seconds
! Terminating Packets Received = 299 Packets
! ... data removed
!
This data were recorded at 24-JAN-1991 13:55:12.
According to the algorithm described in .1 all returned data have right
Time Stamps.
I believe that you question is why there is a difference between
Time Stamp and Counter Creation Time attribute?
I sent this question to the PhaseIV team.
Sam
|
| 654.4 | Counter Creation Time is when counting STARTED... | TOOK::CAREY | | Wed Jan 30 1991 11:32 | 45 |
|
In DECmcc, Counter Creation Time refers to the moment when the counters
first started incrementing from zero. That is, the moment that the
counters were created and started keeping track of whatever they're
counting. In the Entity Model (and DECnet/OSI), we find that counters
are never reset, and never cleared, they just keep on clicking away and
wrap around when reaching their maximum value. DECnet/OSI has a
"Creation Time" which reflects when the node was started, and it never
changes. DECnet Phase IV has a Counter Creation Time that reflects
when the counters were last zeroed.
So, the TIMESTAMP underneath the output entity specifier
"AT 24-Jan-..." reflects the time at which the counters were collected.
The Counter Creation Time reflects (as nearly as possible) the time at
which the counters were last cleared.
DECnet keeps track of the number of Seconds Since Last Zeroed. In an
attempt to allow consistent management of DECnet Phase IV, we calculate
the Counter Creation Time from this Seconds Since Last Zeroed (SSLZ),
and return it for user's and Functional Modules to work with.
In DECnet Phase IV, counters latch (that is, cease to increment) once
they have reached their maximum values. You will see them displayed
with a "greater than" symbol (>) in front of them once they have
latched. This happens at 65535 seconds for Seconds Since Last Zeroed,
or something just over 18 hours of operation.
We calculate the Counter Creation Time from this, and consistently
display a time 18 hours in the past. If you zero the counters and
continue to keep track of them, you will note that the Counter Creation
Time stays constant until the SSLZ reaches its maximum value, then it
starts to creep along as you have seen.
We expected that this would not be too confusing to DECnet users, but
apparently it is at least disconcerting. Any ideas for making this
behavior easier to interpret?
-Jim Carey
|
| 654.5 | I used my lower soapbox... | ULTMAT::BELANGER | A ROSE by anyother name, would not be manageable | Fri Feb 01 1991 10:21 | 14 |
|
IMHO, the Counter Creation Time (CCT) and the Seconds Since Last
Zeroed (SSLZ) are represeting the same information. The problem is
that the CCT is invalid after the SSLZ is >65535. This definitely
makes for confusion, especially if the user does not know that the
CCT is calculated from the current time and SSLZ. The only truely
accurate information is the SSLZ. Therefore, I'd suggest either
dropping the CCT or find an alternative which is always accurate. I
realize that the information is not guarranteed to always be accurate,
but knowingly generating inaccurate information, even if it is accurate
at certain times, is not very useful and can be used to falsely
identify a problem.
~Jon.
|
| 654.6 | Creeping Counter Creation Time.... | TOOK::CAREY | | Fri Feb 01 1991 12:44 | 25 |
|
We have discussed the following alternative. There has been no
resolution, and I expect that the current situation is going to ship
with V1.1.
Return CCT only if SSLZ is less than 65535. That is, only return CCT
if we believe it is likely to be valid. Not returning CCT would then
mean that we "don't know" when the counters were created.
We currently have FMs that sample counters, and expect CCT to come
back. They validate the counters collected by making sure that the
CCTs returned in the two samples match, meaning that the entity didn't
restart, or reset the counters. Thus, the CCT creep that occurs at
max SSLZ would be recognized (by software at least) as indicating that
the counters were suspect. Not returning CCT would trip these FMs.
Anyway, we've been discussing the pros and cons of managing CCT, and
the user confusion described here is possibly the best reason to
revisit the DECmcc philosophy with respect to that.
Thanks for your inputs.
-Jim Carey
|
| 654.7 | CCT Calculation in other AMs too | CHRISB::BRIENEN | DECmcc Bridge|Station Management. | Fri Feb 01 1991 14:18 | 6 |
| For what it's worth...
The algorithm mentioned by Jim Carey in an earlier note (with the problem of
latching at 65535) is also implemented by the Ethernet AM, for Stations that
are of the type DEC_ENETV2 (i.e. MOPV3).
|
| 654.8 | Infinite inaccuracy | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Mon Feb 11 1991 05:38 | 4 |
| Assuming that the CCT is a BATime, you should at least set the inaccuracy to
infinite when the SSLZ hits 65535.
Graham
|
| 654.9 | Oh No, not SSLZ logic again! | CAPN::SYLOR | Architect = Buzzword Generator | Mon Feb 18 1991 21:25 | 12 |
| Simply subtracting th SSLZ from the current time isn't "quite" good
enough when the SSLZ latches. If your AM has state - meaning it
remembers what it got the last time you showed the counters, an
algorithm like the one in NMCC works. It essentially looks to see if
the last reading was less than 65534 seconds ago, if it was, and the
SSLZ counters is still latched, and *no counter has decreased*, then
you can guess that you are still on the same "epoch" of teh counters.
If the AM doesn't have state, then you probably need to report a
true description of what you discovered (SSLZ was latched, etc) to
the FM so it can decipher what's going on.
Mark
|