# sysUpTime in 32 bits - SNMP

This is a discussion on sysUpTime in 32 bits - SNMP ; 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 ...

# Thread: sysUpTime in 32 bits

1. ## sysUpTime in 32 bits

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.

2. ## Re: sysUpTime in 32 bits

mat54 wrote:
> 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
P.O. Box 750 561, 28725 Bremen, Germany

3. ## Re: sysUpTime in 32 bits

Hello,

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

Bruno Matringhen

Juergen Schoenwaelder a écrit :
> mat54 wrote:
> > 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
> P.O. Box 750 561, 28725 Bremen, Germany

4. ## Re: sysUpTime in 32 bits

>>>>> On 26 May 2005 02:27:00 -0700, "mat54" said:

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.

5. ## Re: sysUpTime in 32 bits

mat54 wrote:

> 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

--
Juergen Schoenwaelder International University Bremen
P.O. Box 750 561, 28725 Bremen, Germany

6. ## Re: sysUpTime in 32 bits

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

Wes Hardaker a écrit :
> >>>>> On 26 May 2005 02:27:00 -0700, "mat54" said:

>
> 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.

7. ## Re: sysUpTime in 32 bits

mat54 wrote:

> 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.

> 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?

> 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

8. ## Re: sysUpTime in 32 bits

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...

Bruno

Dave Shield a écrit :
> mat54 wrote:
>
> > 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.
>
>
>
> > 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?
>
> > 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