On 10 November 2010 17:53, Eckert, Doug <doug.eck...@dowjones.com> wrote:
>>Two possibilities spring to mind:
>> a) the second system is much faster than the first,
>> and is populating the sysORTable within the first second of operation
>
> Very possible as the 'offending' system is a 10-core Power770 LPAR
> and the 'reference' system is a 2-core Power6 LPAR.
>
> But, how would the speed of populating sysORTable affect the value of
> sysUpTime?
It's not the value of sysUpTime now.
It's the value of sysUpTime ==>at the point when this entry is added
to the table <===
So on a slow system you might have:
system starts (sysUpTime=0)
<tick> (sysUpTime=1)
<tick> (sysUpTime=2)
<tick> (sysUpTime=3)
add entry 1 to sysORTable (sysUpTime=3, hence sysORUpTime.1 = 3)
<tick> (sysUpTime=4)
add entry 2 to sysORTable (sysUpTime=4, hence sysORUpTime.2 = 4)
etc, etc
Whereas on the faster system, the initialisation would be much quicker,
so it might go:
system starts (sysUpTime=0)
add entry 1 to sysORTable (sysUpTime=0, hence sysORUpTime.1 = 0)
add entry 2 to sysORTable (sysUpTime=0, hence sysORUpTime.2 = 0)
<tick> (sysUpTime=1)
Remember that sysORUpTime doesn't change - it's fixed to whatever
the value of sysUpTime (which *does* change) when the row was created.
Dave
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
