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

+ Reply to Thread
Results 1 to 8 of 8

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,

    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

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

    Thank you for your help
    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



+ Reply to Thread