RE: hrProcessorLoad returns incorrect values for processor #'s > 100

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Dave Shield
Sent: Wednesday, July 18, 2012 4:33 AM
To: Joe Guderjohn
Cc: [email protected]
Subject: Re: hrProcessorLoad returns incorrect values for processor #'s
> 100

On 17 July 2012 19:34, Joe Guderjohn <[email protected]> wrote:
> Platform: IBM 3850 (10.1.20.10) w/ 16 CPUs, each with 8 cores = 128 
> CPUs for monitoring Net-snmp version: 5.3.2.2 (RHEL 5.6). Also built 
> net-snmp-5.4.4 with same results.
>
> Values returned for hrProcessorLoad for CPU #'s greater than 100 
> appear to be incorrect. They're always in the range of 90 > 100.

> I'd be happy to try and solve this, if someone would suggest a few 
> source files that might have some bearing on this.


Hmmm...   that sounds an interesting one.

The souce code that implements the hrProcessorTable is in
   agent/mibgroup/host/hr_proc.c
but that relies on data from the "hardware independence layer"
which is implemented at
   agent/mibgroup/hardware/cpu/*

I suspect the file that is probably most relevant here will be
   agent/mibgroup/hardware/cpu/cpu_linux.c
(though you can check by seeing which files in the directory actually
get compiled!).

I've had a quick look, and can't immediately spot an limitations of <100

The data is being read from
    /proc/cpuinfo   &    /proc/stat
(plus /proc/vmstat, but that's probably not relevant here)

It might be worth checking those two files, to see if you can spot
anything odd about the higher entries.

<ping>
I think this may be related to line 156 of cpu_linux.c

           b1 = b2+5; /* Skip "cpuN " */

This works fine with single-digit CPU numbers, and happens to work with
double-digit CPU numbers (but leaves the trailing space for the next
sscanf to ignore) But with three CPU numbers, the third digit will be
left in the buffer, and picked up by the next sscanf statement (line
160)

Try tweaking this b1 line to skip the next token, rather than moving on
a fixed amount.
   I strongly suspect that should do the trick

Dave

Thanks. It would have taken me a very long time to find that source
file.

I modified the file 'agent/mibgroup/hardware/cpu/cpu_linux.c' as shown
below, and it appears to solve the problem, as the snmpwalk snippet
indicates. I'm sure there's a more elegant solution to this problem, but
at least the source has been identified.

136     while ((b2 = strstr( b1, "cpu" ))) {
137         if (b2[3] == ' ') {
138             cpu = netsnmp_cpu_get_byIdx( -1, 0 );
139             if (!cpu) {
140                 snmp_log_perror("No (overall) CPU info entry");
141                 return -1;
142             }
143             /* b1 = b2+4;  Skip "cpu " */
144             b1 = strstr(b2, " ") + 1; /* Skip past "cpu", and
whitespace */
145         } else {
146             sscanf( b2, "cpu%d", &i );
147                        /* Create on the fly to support non-x86
systems - see init */
148             cpu = netsnmp_cpu_get_byIdx( i, 1 );
149             if (!cpu) {
150                 snmp_log_perror("Missing CPU info entry");
151                 break;
152             }
153             /* b1 = b2+5; Skip "cpuN " */
154             b1 = strstr(b2, " ") + 1; /* Skip past "cpu","digits",
and whitespace */
155         }

HOST-RESOURCES-MIB::hrProcessorLoad.768 = INTEGER: 6
HOST-RESOURCES-MIB::hrProcessorLoad.769 = INTEGER: 1
HOST-RESOURCES-MIB::hrProcessorLoad.770 = INTEGER: 1
HOST-RESOURCES-MIB::hrProcessorLoad.771 = INTEGER: 1
...

HOST-RESOURCES-MIB::hrProcessorLoad.892 = INTEGER: 1
HOST-RESOURCES-MIB::hrProcessorLoad.893 = INTEGER: 1
HOST-RESOURCES-MIB::hrProcessorLoad.894 = INTEGER: 1
HOST-RESOURCES-MIB::hrProcessorLoad.895 = INTEGER: 3

Please let me know if submitting a patch file would be appropriate, and
if so, a pointer to the process for doing so.

Thanks again, Dave.

Regards,

Joe


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users