I'm somewhat new to this, but my guess would be that the reason this occurs is because we are sampling user system and nice percentages asynchronously. Thus we get, from the kernel (via /proc/stat) something like user and system for time0, but nice from time1, because this file is dynamically being modified in the time between some of the values are read.
However, in practice, I've never seen a value greater than 102, which could just be because the user/system/nice values do not change drastically between two very close samples. I'd suggest reading the whole line that contains these values at once, then tokenizing it afterwards. I'll try that later today when I get access to my main machine.
I don't have the code infront of me now, but I believe that we just read these values from the kernel interface, so any rounding error would have to be on the kernel's side, and I'm sure the kernel knows better than to report >100% combined cpu usage.
On 10/18/05, Martin Geisler <[EMAIL PROTECTED]> wrote:
Randy Robertson <[EMAIL PROTECTED]> writes:
> I've been using the monitor module, and annoyingly it reports >100% cpu
> usage. Here's a simple patch to hide this.
I have just looked at the patch, and as you say it hides the >100%
load, but itsn't this an indication of a more fundamental problem?
So instead of hiding it I think it should be fixed --- unless we're
talking about rounding errors (so it would display 101% once in a
while which is silly).
--
Martin Geisler GnuPG Key: 0x7E45DD38
PHP Exif Library | PHP Weather | PHP Shell
http://pel.sf.net/ | http://phpweather.net/ | http://mgeisler.net/
Read/write Exif data | Show current weather | A shell in a browser
