sysUpTime in 32 bits

[mat54]

Hello,
I've got a problem with the sysUpTime's OID from the mib2
beacause it's a 32 bits (timeticks). The maximum numer it could have is
2^32 - 1 = 4294967295,
it makes 497 days.
I've a lot of server which overflow this numer of days.
The sysUptime gives me 126 days, but in fact it's in real
497+126=623days.

He's there a way to have the sysUptime in 64 bits, or is there a way to

know how many time the limit overflow, so that I could make a calcul.

[Juergen Schoenwaelder]

Post by mat54
Hello,
I've got a problem with the sysUpTime's OID from the mib2
beacause it's a 32 bits (timeticks). The maximum numer it could have is
2^32 - 1 = 4294967295,
it makes 497 days.
I've a lot of server which overflow this numer of days.
The sysUptime gives me 126 days, but in fact it's in real
497+126=623days.
He's there a way to have the sysUptime in 64 bits, or is there a way to
know how many time the limit overflow, so that I could make a calcul.

You can define new objects but they won't be widely implemented anytime
soon. Some MIB modules have DateAndTime objects which allows to read
the system start time. This can help out in some cases (but not in all
of them).

The simplest solution is perhaps to reboot every 400+ days. ;-)

/js

[mat54]

Hello,

thank you for your help.
It's too bad that's the sysuptime is not a dateandtime type.
I think I will reboot my 500 server...

Bruno Matringhen

Post by Juergen Schoenwaelder

Post by mat54
Hello,
I've got a problem with the sysUpTime's OID from the mib2
beacause it's a 32 bits (timeticks). The maximum numer it could have is
2^32 - 1 = 4294967295,
it makes 497 days.
I've a lot of server which overflow this numer of days.
The sysUptime gives me 126 days, but in fact it's in real
497+126=623days.
He's there a way to have the sysUptime in 64 bits, or is there a way to
know how many time the limit overflow, so that I could make a calcul.

You can define new objects but they won't be widely implemented anytime
soon. Some MIB modules have DateAndTime objects which allows to read
the system start time. This can help out in some cases (but not in all
of them).
The simplest solution is perhaps to reboot every 400+ days. ;-)
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany

[Wes Hardaker]

mat> thank you for your help.
mat> It's too bad that's the sysuptime is not a dateandtime type.
mat> I think I will reboot my 500 server...

There is no reason to reboot. sysuptime is expected to wrap by decent
managers. It's also not the uptime of the box, it's the uptime of the
agent. Big difference.

If you want the system clock, by the way, use hrSystemDate from the host
resources mib. Or for the box uptime, use hrSystemUptime.

[mat54]

I know that it is the uptime of the snmp agent, the pb is when the
uptime is more than 497 days, because when the snmp agent is started
from 500 days, the sysUptime gives me 3 days and that's a big mistake
!!!
So, i must restart all the server with an uptime > 497 days to have a
correct uptime. I'm system administrator, and it could help to plan
reboot of server.

Bruno

Post by Wes Hardaker
mat> thank you for your help.
mat> It's too bad that's the sysuptime is not a dateandtime type.
mat> I think I will reboot my 500 server...
There is no reason to reboot. sysuptime is expected to wrap by decent
managers. It's also not the uptime of the box, it's the uptime of the
agent. Big difference.
If you want the system clock, by the way, use hrSystemDate from the host
resources mib. Or for the box uptime, use hrSystemUptime.
--
Wes Hardaker
Sparta, Inc.

[Dave Shield]

Post by mat54
I know that it is the uptime of the snmp agent, the pb is when the
uptime is more than 497 days, because when the snmp agent is started
from 500 days, the sysUptime gives me 3 days and that's a big mistake

Let's take a step back.
What exactly is the sysUpTime being used for?
Why does it matter if the value is "wrong" - what will actually break?

The main use of sysUpTime seems to be as a base time for assorted
internal timestamps, to indicate whether various MIB values might
have changed. If the base time changes, then this effectively
invalidates all such time-based caches.

So any external management tools might need to reload all their
current local representation of the state of that particular agent
(and the agent itself might need to reset all the relevant timestamps).

That's certainly less than ideal, but this sort of "blip" once every
16 months is hardly a disaster.

Post by mat54
So, i must restart all the server with an uptime > 497 days to have a
correct uptime.

Uptime of the server, or uptime of the SNMP agent?

Post by mat54
I'm system administrator, and it could help to plan reboot of server.

That sort of planning feels more related to the uptime of the server,
rather than the agent. If I have a policy of rebooting a given
server every two years (due to a very slow memory leak in the kernel),
it doesn't matter how often the agent is stopped and restarted - I
still need to know how long the server as a whole has been up.
So it would probably be more appropriate to look at hrSystemUptime.

Now in fact, that simply moves the problem since this object is also
defined using the same syntax as sysUpTime, so will be limited to the
same range. (And hrSystemDate doesn't help here either - that's the
time *now*, not the time the system booted). So there is indeed a
problem - but with the hrSystem group, not sysUpTime.

What's probably necessary is a "HC-Counter" style object, monitoring
how often the hrSystemUptime value wraps. Taking these two objects
together should address the problem you mention.
Or else a 'hrBootDate' object, with syntax DateAndTime.

Dave

[mat54]

Yes that's right, I need a 'hrBootDate' object, with syntax DateAndTime
or Counter64. I now that there is a HC counter type (high Capacity)
with SNMPV2c wich use 64 bits...

Thank you for your help
Bruno

Post by Dave Shield

Post by mat54
I know that it is the uptime of the snmp agent, the pb is when the
uptime is more than 497 days, because when the snmp agent is started
from 500 days, the sysUptime gives me 3 days and that's a big mistake

Let's take a step back.
What exactly is the sysUpTime being used for?
Why does it matter if the value is "wrong" - what will actually break?
The main use of sysUpTime seems to be as a base time for assorted
internal timestamps, to indicate whether various MIB values might
have changed. If the base time changes, then this effectively
invalidates all such time-based caches.
So any external management tools might need to reload all their
current local representation of the state of that particular agent
(and the agent itself might need to reset all the relevant timestamps).
That's certainly less than ideal, but this sort of "blip" once every
16 months is hardly a disaster.

Post by mat54
So, i must restart all the server with an uptime > 497 days to have a
correct uptime.

Uptime of the server, or uptime of the SNMP agent?

Post by mat54
I'm system administrator, and it could help to plan reboot of server.

That sort of planning feels more related to the uptime of the server,
rather than the agent. If I have a policy of rebooting a given
server every two years (due to a very slow memory leak in the kernel),
it doesn't matter how often the agent is stopped and restarted - I
still need to know how long the server as a whole has been up.
So it would probably be more appropriate to look at hrSystemUptime.
Now in fact, that simply moves the problem since this object is also
defined using the same syntax as sysUpTime, so will be limited to the
same range. (And hrSystemDate doesn't help here either - that's the
time *now*, not the time the system booted). So there is indeed a
problem - but with the hrSystem group, not sysUpTime.
What's probably necessary is a "HC-Counter" style object, monitoring
how often the hrSystemUptime value wraps. Taking these two objects
together should address the problem you mention.
Or else a 'hrBootDate' object, with syntax DateAndTime.
Dave

[Juergen Schoenwaelder]

Post by mat54
It's too bad that's the sysuptime is not a dateandtime type.
I think I will reboot my 500 server...

There are many devices that do not know the data and time and this is
why sysUpTime is in terms of 10th of a second since a box was last
reinitialized (well actually the management portion of the box if you
read the details of the description clause).

/js