Julien Claassen wrote: I played around a bit more, and it seems I misjudged "ps aux", since it seems to report correct values. Will takt that route and get back in case of further trouble. Thanks for the input, anyhow! -- Atte http://atte.dk http://modlys.dk

----- "Atte André Jensen" <atte.jensen(a)gmail.com> wrote: Short solution: top -b -n 1 (with procps 3.2.7, just in case it fails for you...) Long explaination (you may skip it): Note that ps results are not accurate. The CPU usage is reported as % of time spent running during the entire lifetime of a process. So if you have a process sleeping for one minute and then running like hell for one second, you might think it won't eat much CPU if you ps it during this second even if in reality it eats up all the CPU. The /proc/[processID]/stat gives you statistics on the process. You are interested in the field utime I guess, which gives you the number of jiffies the process smoked in user mode at the time of reading /proc/[processID]/stat. (The output format of /proc/[processID]/stat is described in Documentation/fs/proc.txt found in the linux sources tarball.) So to know how much CPU the process smokes you first read /proc/.../stat, wait a bit (1s or so), read /proc/.../stat again and do something like (value2 - value1) / nb_jiffies_of_1s (nb_jiffies_of_1s might be defined on your system in /usr/include/asm/param.h, it's the HZ value. It might also exist in your shell's environment (try: echo $HZ). Or you can go read the procps sources (in procps-3.2.7 this stuff is in proc/sysinfo.c, and it is a bit tricky to get this value it seems...) to see how they get it. You can also do: cat /proc/stat; sleep 1; cat /proc/stat and see how bigger the 4th number on the line "cpu: XX" is. (Or /proc/self/stat and the 22nd number.) On my host HZ=100, but on yours it might well be 250, 300 or 1000 (this are the values I see when doing a "make config" of the kernel). I guess 1000 is the most probable. Anyway, there is no way to know how much CPU a given process is eating at a given moment. You have to "wait a bit" and see what changed. But maybe you are more interested in the global times? in which case just do "time command" and you get some stats at the end, when the process exits. For the "accurate" way to measure it's not too hard to code. The program would open /proc/[processID]/stat, get the number, wait, open again, output the result and exit. A few lines of C code. Or you can do "top -b -n 1" with other options if you like. Just read the manpage. (Note that it may not be very accurate either if the process switches before the end of a jiffy for example; I had such a problem in the past with a 2.0 something kernel; the process was reported as eating 0% CPU which was false. But maybe things are different now.) Hope it helps. Cédric.