Subject: [OPS-AREA] A better version of TimeTicks?

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Dec 2007 14:30:55 +0200 (EET)

Hi,

SNMPv2 SMI (RFC2578, STD 58) defines, among other things, TimeTicks.

TimeTicks is limited to 497 days before it wraps over 
(2^32/3600/24/100).

TimeTicks is used in various things, among others, reporting uptimes.

Has there been work to consider redefining or extending TimeTicks-like 
objects which would not wrap after 497 days?

We have gear whose internal uptime representation allows the uptimes 
in the order of decades but unfortunately such uptimes cannot be 
managed within the current SNMP framework as far as I can see.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: Jon Saperia <[email-masked]>
Date: Mon, 17 Dec 2007 08:29:55 -0500

Peter,

The drill usually is that the management application polls for  
information on some periodic basis, for interface and other  
information. It is as this point that a wrap in uptime would be  
detected.  Also depending on the deployment model of your customers,  
some may choose to have a cold-start or other notification message  
sent when the management system is reinitialized (which will be the  
case on a reboot).  Between these two, you should be OK

Note is you are really keeping track of uptime of the system, you  
should distinguish it from management system up time.  In some  
systems I have worked on, the distinction is important and we  
implemented a different object than sysUptime.
Thanks
/jon

------------
Jon Saperia
(mobil) 617-201-2655
(office) 978-461-0249
[email-masked]

On Dec 17, 2007, at 7:30 AM, Pekka Savola wrote:

> Has there been work to consider redefining or extending TimeTicks- 
> like objects which would not wrap after 497 days?
>
> We have gear whose internal uptime representation allows the  
> uptimes in the order of decades but unfortunately such uptimes  
> cannot be managed within the current SNMP framework as far as I can  
> see.
>
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Dec 2007 14:26:27 +0100

On Mon, Dec 17, 2007 at 02:30:55PM +0200, Pekka Savola wrote:

> TimeTicks is limited to 497 days before it wraps over (2^32/3600/24/100).
>
> We have gear whose internal uptime representation allows the uptimes in the 
> order of decades but unfortunately such uptimes cannot be managed within 
> the current SNMP framework as far as I can see.

When we did the SMIng experiment, we defined a TimeTicks64 type, a
64-bit version of TimeTicks (which is 32-bit). Once you move to 64-bit
numbers (which I think is pretty much reasonable these days), it is
possible to also change the time base form hundredths of a second to
something more granular (e.g. microseconds) while still allowing long
time intervals to be expressed without wrap arounds.

That said, I am not aware of any standards-track action in this space.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 17 Dec 2007 14:03:52 -0500

Pekka,

I have also seen devices stay up for two years.

So, how would you handle this? One possibility is to create a new type
with range 0-2^32 and a granularity of seconds. Another is to create a
new type with range 0-2^64 and granularity of centiseconds?

                                     Ron

Pekka Savola wrote:
> We have gear whose internal uptime representation allows the uptimes in
> the order of decades but unfortunately such uptimes cannot be managed
> within the current SNMP framework as far as I can see.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Dec 2007 20:20:04 +0100

> new type with range 0-2^64 and granularity of centiseconds?

If you go to 64-bit, you can safely go down to microseconds and
achieve a rather long lifetime without a rollover. Lets do the
calculation with microseconds = 10^6 ticks per second: This means
approximately 18446744073709 seconds which is in the order of 584942
years until rollover. Of course, the lower 32 bits would rollover
almost every hour.

NTP timestamps are 64 bits where 32 bits are in the resolution of
seconds (rollover in ~136 years) and the other 32 bits give you a
resolution in pico-seconds.

/js

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Dec 2007 21:21:11 +0200 (EET)

On Mon, 17 Dec 2007, Joel Jaeggli wrote:
> Ron Bonica wrote:
> low-enough sample interval should given you high confidence that you've
> detected a counter rollover rather than a reboot.

This presumes a system where this information is polled regularly (and 
then synthethized and presented, in some postprocessed form, e.g. 
adjusting for overflows, to the user).

In our case, when the user goes to a web page, CGI scripts fire up a 
couple of SNMP queries -- there no stored state about the results of 
previous runs. We could easily add such stored data for each of our 
(self-developed) systems that do similar on-demand tasks, but I'm not 
sure how feasible approach that is in the general case or how that 
would work with closed-source products.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Dec 2007 15:13:04 -0500

Hi,

Wouldn't an alternative be to define a sysUptimeRollovers to count the
number of times the maximum value was reached? Except that you would
need to poll two objects, this is the same as defining a new sysUpTime
object to be 64 bits, where the upper bits would count the rollovers.
sysUptimeRollovers would need to be cleared on reboot, just as
sysUptime is cleared. All existing applications would continue to work
just fine with the existing lower-32-bit counter. 

If you define a new TimeTicks64 and wanted to apply it to existing
counters, such as sysUptime, you would need to define a new managed
object of the 64bit type, and agents and managers would probably need
to support both the timeticks32 and the timeticks64 objects. 

Using a rollover counter does not require any changes to existing
sysUptime support, just an additional object where rollovers might
matter. If a system does not support the rollover counter then you are
no worse off than you are today. If it does, it provides additonal
information to better interpret sysUptime.

This could be done as a textual convention, so timeticks objects other
than sysuptime could be extended to count their rollovers.
Descriptions would need to be clear about when the rollover count was
cleared.

Combining the normal 32-bit counter with a rollover counter is
equivalent to using a 64-bit counter, assuming access to both the
lower-32-bits and the upper-32-bits are handled simultaneously, and
SNMP GETs are supposed to be as0if-simultaneous, so if both are
requested in the same PDU, they chould be consistent. (And
implementations of course could actually use a 64-bit counter so they
could access instrumentation once, and then report it as two 32-bit
objects.)

Of course for new objects where there is no 32-bit counter already,
simply using a 64-bit counter might be preferable.

Before you invent a new object to track, say, seconds since reboot,
you might take a look at the SNMP-FRAMEWORK-MIB which contains a Boots
counter and a seconds-since-last-boot counter. This is not tied to
sysUptime explicitly, and may or may not be appropriate to your
desired usage. While designed for SNMPv3 support, SNMP-FRAMEWORK-MIB
can be implemented in any SNMP engine, regardless of which versions of
SNMP are supported.

Note that with all of these objects, you need to be careful about a
re-initialization of the SNMP agent independent of re-initialization
of the hardware or software that is being managed.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Monday, December 17, 2007 2:20 PM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: [OPS-AREA] A better version of TimeTicks?
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Dec 2007 21:20:59 +0100

> information to better interpret sysUptime.

Both solutions require a new object and so I do not understand what
the difference there is implementation wise.
 
> can be implemented in any SNMP engine, regardless of which versions of

I believe most people want HOST-RESOURCES-MIB::hrSystemUptime or
something with equivalent semantics and with less rollovers.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 18 Dec 2007 14:37:07 +0100

> Sent: Monday, December 17, 2007 10:21 PM
> To: David Harrington
> Cc: [email-masked]
> Both solutions require a new object and so I do not 
> understand what the difference there is implementation wise.
>  

Would not the introduction of a newTimeTicks64 be a new basic type, so a
modification to SMIv2, something that we did not do since RFC 2578? 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Dec 2007 15:03:12 +0100

> modification to SMIv2, something that we did not do since RFC 2578? 

Oh, TimeTicks64 is just a Counter64 counting ticks. ;-) And we like
with ZeroBasedCounter64 or Unsigned64TC, we can just "overwrite" the
rule that you can't derive a TC from a Counter64...

/js

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 17 Dec 2007 11:23:44 -0800

> adjusting for overflows, to the user).

It does, yeah.  larger counter is I agree the general purpose solution...

joelja

> sure how feasible approach that is in the general case or how that would
> work with closed-source products.
>

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 17 Dec 2007 11:23:44 -0800

joelja

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 17 Dec 2007 11:13:21 -0800

g;
	Mon, 17 Dec 2007 14:13:39 -0500
Date: Mon, 17 Dec 2007 11:13:21 -0800
From: Joel Jaeggli <[email-masked]>
To: Ron Bonica <[email-masked]>
Subject: Re: [OPS-AREA] A better version of TimeTicks?
Cc: [email-masked]