[netperf-talk] negative CPU utilization

[Andrew Gallatin]

Rick Jones wrote:
 > I've applied the updated patch (the later one in direct email, but
 > responding to the list so folks can see).  I make a couple gratuitous
 > formatting changes to bring more stuff within 80 columns and I also made
 > a couple routines static - not that we'd be likely to get namespace
 > collisions the way the netcpu_mumble.c file is selected :) but apart
 > from that it should be just as you sent me.  Committed to top-of-trunk.

Sorry about those things, thanks for fixing them!

 > I'm not sure what the calibration routine should return at this point.
 > I guess the question is somewhat moot since lib_local_maxrate is no
 > longer used for anything.

Yes.  I left it, as I was worried it might be used elsewhere, and was
afraid to touch it.  I stopped tinkering when it compiled cleanly and
gave the correct answer. Sort of "tunnel vision" on my part.

 > Since looking over the changes had me looking at the code:
 >
 > In calc_cpu_util_internal:
 >
 >
 >     /* calculate idle time as a percentage of all CPU states */
 >     if (total_ticks == 0) {
 >       fprintf(stderr, "Total ticks 0 on CPU %d, charging nothing!\n", i);
 >       lib_local_per_cpu_util[i] = 100.0;
 >     } else {
 >       lib_local_per_cpu_util[i] = 100.0 *
 >     ((float) diff.idle / (float) total_ticks);
 >
 > since total ticks is uint64_t, should we instead be using a pair of
 > (double) casts there?

I'm not sure.  I've been mainly a kernel/driver guy for the last 15
years, and never deal with anything but integer arithmetic, so I've
forgotten all the integer/floating point conversion rules that I
learned doing scientific programming for a college internship. :) I
just tried to preserve the existing types (which I think were doing
the same uint64t -> float thing).  Also, netlib.h declares
lib_local_per_cpu_util as a float, and its used in all the other
netcpu* modules.

If that doesn't inspire you with overwhelming confidence, then
consider that the total_ticks here is a difference, so its unlikely to
be larger than 32-bits anyway, unless a single netperf test has been
running for weeks or months.

Drew