Re: interpreting hrSystemUptime - SNMP

This is a discussion on Re: interpreting hrSystemUptime - SNMP ; Thomas Scholz wrote: > Hi, > > does anybody know how to interprete the value > .iso.org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime > (.1.3.6.1.2.1.25.1.1.0) returned by Microsofts hostmib.mib? > Well having to interpret it any other way than it is defined in the MIB makes ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: interpreting hrSystemUptime

  1. Re: interpreting hrSystemUptime

    Thomas Scholz wrote:
    > Hi,
    >
    > does anybody know how to interprete the value
    > .iso.org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime
    > (.1.3.6.1.2.1.25.1.1.0) returned by Microsofts hostmib.mib?
    >

    Well having to interpret it any other way than it is defined in the MIB
    makes it a bug. :-,) And I agree that there is a bug in this case. I think
    the mistake is that it is in units of milliseconds rather in TimeTicks (tens
    of milliseconds).

    I've included some examples below that I've collected over the past while.
    The hrSystemUptime value always appears ten times too large. (Of course it
    is not exactly ten times as the sysUpTime value is only measured from the
    SNMP service starting rather than system boot as hrSystemUptime does).
    ____
    Variable = system.sysUpTime.0
    Value = TimeTicks 51,802,412

    Variable = host.hrSystem.hrSystemUptime.0
    Value = TimeTicks 518,090,484
    ____
    Variable = system.sysUpTime.0
    Value = TimeTicks 51,804,937

    Variable = host.hrSystem.hrSystemUptime.0
    Value = TimeTicks 518,115,731
    ____
    Variable = system.sysUpTime.0
    Value = TimeTicks 66,381,544

    Variable = host.hrSystem.hrSystemUptime.0
    Value = TimeTicks 663,885,897
    ____
    Someone should report this to Microsoft...they might even fix it... An
    ex-colleague reported a fault in the same MIB which has resulted in KB323668
    http://support.microsoft.com/default.aspx?kbid=323668, which is included in
    Windows 2000 SP4, http://support.microsoft.com/?kbid=327194. Just a shame
    the guy didn't report this at the same time. :-(
    --
    Alan J. McFarlane
    http://homepage.ntlworld.com/alanjmcf/
    Please follow-up in the newsgroup for the benefit of all.



  2. Re: interpreting hrSystemUptime

    Thanks for you answer Alan,

    if the values would stay like the ones you've collected it would be
    allright. As I said, my experience was that on some servers the value is
    smaller although the "real uptime" is higher (compared to other servers). On
    some servers I don't have a clue what it represents.

    Anyway, ResKit tools like "uptime" report the uptime correct. There's also a
    performance counter for systenm uptime. I suspect this is the first source
    and the SNMP values fed by the SNMP extensions (I think some .dll) might be
    buggy.

    For me the hr...xyz stuff is more or less unusuable. For example, I've tried
    to get the disk usage via SNMP from "hrStorageUsed" etc. Works fine for a
    while ... but then it may happen that snmp.exe pops up an application error
    telling "no disk in drive A:". While this dialog is up SNMP is halted. I've
    noticed that it is enough to request any value under hrStorage and snmp.exe
    will check the floppy drive maybe every 5-10 minutes. Lucky if one can
    access the servers console via VNC etc. ...

    Maybe SP4 will fix some of this ... at least Windows 2003 has fixed some of
    them (for example hrSWRun contains correct information now).

    Thomas


    "Alan J. McFarlane" schrieb im Newsbeitrag
    news:9fcVa.2571$2o3.31232@newsfep4-glfd.server.ntli.net...
    > Thomas Scholz wrote:
    > > Hi,
    > >
    > > does anybody know how to interprete the value
    > > .iso.org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime
    > > (.1.3.6.1.2.1.25.1.1.0) returned by Microsofts hostmib.mib?
    > >

    > Well having to interpret it any other way than it is defined in the MIB
    > makes it a bug. :-,) And I agree that there is a bug in this case. I

    think
    > the mistake is that it is in units of milliseconds rather in TimeTicks

    (tens
    > of milliseconds).
    >
    > I've included some examples below that I've collected over the past while.
    > The hrSystemUptime value always appears ten times too large. (Of course

    it
    > is not exactly ten times as the sysUpTime value is only measured from the
    > SNMP service starting rather than system boot as hrSystemUptime does).
    > ____
    > Variable = system.sysUpTime.0
    > Value = TimeTicks 51,802,412
    >
    > Variable = host.hrSystem.hrSystemUptime.0
    > Value = TimeTicks 518,090,484
    > ____
    > Variable = system.sysUpTime.0
    > Value = TimeTicks 51,804,937
    >
    > Variable = host.hrSystem.hrSystemUptime.0
    > Value = TimeTicks 518,115,731
    > ____
    > Variable = system.sysUpTime.0
    > Value = TimeTicks 66,381,544
    >
    > Variable = host.hrSystem.hrSystemUptime.0
    > Value = TimeTicks 663,885,897
    > ____
    > Someone should report this to Microsoft...they might even fix it... An
    > ex-colleague reported a fault in the same MIB which has resulted in

    KB323668
    > http://support.microsoft.com/default.aspx?kbid=323668, which is included

    in
    > Windows 2000 SP4, http://support.microsoft.com/?kbid=327194. Just a shame
    > the guy didn't report this at the same time. :-(
    > --
    > Alan J. McFarlane
    > http://homepage.ntlworld.com/alanjmcf/
    > Please follow-up in the newsgroup for the benefit of all.
    >
    >




  3. Re: interpreting hrSystemUptime

    I'll try to collect some samples ... but I'm on holidays right now :-)
    so check back in 1-2 weeks ....

    "Alan J. McFarlane" schrieb im Newsbeitrag
    news:c5VVa.1272$Kx1.14055@newsfep4-glfd.server.ntli.net...
    > Thomas Scholz wrote:
    > > "Alan J. McFarlane" schrieb im Newsbeitrag
    > > news:9fcVa.2571$2o3.31232@newsfep4-glfd.server.ntli.net...
    > >> Thomas Scholz wrote:

    >
    > > if the values would stay like the ones you've collected it would be
    > > allright. As I said, my experience was that on some servers the value
    > > is smaller although the "real uptime" is higher (compared to other
    > > servers). On some servers I don't have a clue what it represents.
    > >

    > Hmm. Could you show us some examples? Do both objects appear wrong at
    > times or just one of them? Is the SNMP Service possibly being restarted

    and
    > thus correctly the sysUpTime value will be correspondingly short?
    >
    >
    > > Anyway, ResKit tools like "uptime" report the uptime correct. There's
    > > also a performance counter for systenm uptime. I suspect this is the
    > > first source and the SNMP values fed by the SNMP extensions (I think
    > > some .dll) might be buggy.
    > >

    > I've just played with uptime.exe here, it sure gets confused (by my
    > configuration?). I can see that some of its confusion here may be caused

    by
    > hibernation (as I use on my laptop). With non-admin priv's it says 195
    > days--no idea where that comes from , with admin it says 5 hours--when it
    > last resumed from hibernation, with non-admin priv's but limiting it to
    > looking 3 days in the past, it report the actual time since the last

    reboot.
    > Hmm. The help etc says it uses the Event log, and registry Heartbeat if
    > enabled.
    >
    > A day or so later now. Uptime now reports 22 hours plus, a value I don't
    > recognise...
    >
    > Hmm, sysUpTime, hrSystemUptime and the PerfMon values are respectively
    > 10,981,424 (SNMP Service restarted since boot), 181,345,370 and

    81,187.500.
    > That 81187 corresponds to the uptime.exe value.
    >
    > I'm not sure I'm helping you now! :-) Perhaps the hibernation really does
    > confuse things, as a system-hardware-clock-running value is used...
    >
    >
    > > For me the hr...xyz stuff is more or less unusuable. For example,
    > > I've tried to get the disk usage via SNMP from "hrStorageUsed" etc.
    > > Works fine for a while ... but then it may happen that snmp.exe pops
    > > up an application error telling "no disk in drive A:". While this
    > > dialog is up SNMP is halted. I've noticed that it is enough to
    > > request any value under hrStorage and snmp.exe will check the floppy
    > > drive maybe every 5-10 minutes. Lucky if one can access the servers
    > > console via VNC etc. ...
    > >

    > Yikes that's no good! I've never seen that. I think my ex-colleague
    > collects such stats, I'll try and ask him if he sees such problems. Do

    you
    > have (other) removable disks that might confuse the indexing or do you

    boot
    > from floppy or something similar.
    >
    > I wonder if whether the SNMP Service getting thusly stuck causes it to

    stop
    > updating the uptime values, or one of the two anyway?
    >
    >
    > > Maybe SP4 will fix some of this ... at least Windows 2003 has fixed
    > > some of them (for example hrSWRun contains correct information now).
    > >

    > Well I've got SP4 installed here...
    >
    > In my looking at the hwSWRun table in the past, pre SP4, it has always
    > appeared to correctly represent what TaskManager shows though I've not
    > checked the Perf values in detail, if that's where your problem lies.
    > Though I've just checked the CPU and Mem entries of the first two

    processes
    > and they seem fine--again in my SP4 system. Seems you've got all the bad
    > luck. :-( Perhaps the German build (assuming that's what you have
    > installed...) of hostmib.dll is broken...
    >
    > BTW the hostmb.mib /is/ new (due to KB323668, as noted previously) with
    > version 5.00.2195.6627 and dated in June.
    >
    >
    > >>> does anybody know how to interprete the value
    > >>> .iso.org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime
    > >>> (.1.3.6.1.2.1.25.1.1.0) returned by Microsofts hostmib.mib?

    > [cut]
    > >> I've included some examples below that I've collected over the past
    > >> while. The hrSystemUptime value always appears ten times too large.
    > >> (Of course it is not exactly ten times as the sysUpTime value is
    > >> only measured from the SNMP service starting rather than system boot
    > >> as hrSystemUptime does).

    > [cut]
    > --
    > Alan J. McFarlane
    > http://homepage.ntlworld.com/alanjmcf/
    > Please follow-up in the newsgroup for the benefit of all.
    >
    >
    >




  4. Re: interpreting hrSystemUptime

    I have just reported this bug to Microsoft -- see also https://connect.microsoft.com/onecar...dbackID=504908.

+ Reply to Thread