Unix/Linux 'top' command output

[Superwormy]

Aight, so looking at the output of the 'top' command at a terminal, I see something like what follows.

Now, I'd assume that the CPU percentage idle ( 98.3% ) would be equal to 100% - the sum of the CPU usage of all of the running processes... However, this is obviously not the case. Can someone explain to me:

a) why not?
b) how can I really tell the CPU usage of the machine? 100 - the sum or what it says for idle?



last pid: 59111; load averages: 0.26, 0.32, 0.44 up 120+07:56:30 15:38:32
82 processes: 82 sleeping
CPU states: 1.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.3% idle
Mem: 309M Active, 392M Inact, 180M Wired, 37M Cache, 112M Buf, 84M Free
Swap: 2032M Total, 72K Used, 2032M Free

PID UID PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
50520 88 2 0 359M 106M poll 1 436:44 12.50% 12.50% mysqld
59095 1001 18 0 16752K 15672K lockf 0 0:03 7.43% 6.79% perl
6980 80 10 0 22748K 11076K nanslp 1 106:19 1.71% 1.71% httpd
6971 80 2 0 22524K 10872K sbwait 0 79:31 0.54% 0.54% httpd
59036 125 18 0 1932K 1304K lockf 1 0:01 0.49% 0.49% cleanup
59039 125 2 0 1932K 1304K select 1 0:01 0.49% 0.49% cleanup
6982 80 2 0 22500K 10828K sbwait 0 104:27 0.10% 0.10% httpd

 

[Superwormy]

To expand further, what I really want to do is get the total memory usage and CPU usage of the machine so I can parse this out and display it with PHP.

If theres an easier way to go about that, by all means, let me know. This is FreeBSD 4.10.

 

[drag]

Depends on what exactly is going on, and exactly which OS your using. I am not that familar with FreeBSD, but cpu time can be used up by a lot of things. Remember that the cpu 'percentages' is realy a the percentage of the time in a certain time period on what the cpu is being used for what purpose.

CPU is only single tasking thing, it can only pay attention to one proccess at a time.. the amount of time that is spent on a paticular proccess is what that proccesses's 'cpu usage' is. Now you probably already know that, but I wanted to be sure.

For instance you have a scedualer that determines what proccessors get worked on when. A scedualer could cause the CPU to get tied up in I/O wait. That is that the cpu is busy waiting for more information so that it can finish proccessing something. Needless to say you want to reduce that to a minimal time possible. Fast harddrives, fast ram, fast network help out.

Another portion of the CPU's time is going to be used in maintianing the system. The RAM needs to be refreshed since it's volitile. IDE disk controllers use a lot of cpu time because they offload proccessing time onto the CPU... which is why you want DMA turned off if possible. Hardware interrupts take up a large amount of the CPU's attention...

For instance if you have a gigabit ethernet network it has small traditional ethernet type frames, or mtu's or whatever. Each one can generate a interrupt to get your cpu's attention. That's why using 'jumbo packets' or MTU metrics up to 9000 can help out with network performance quite a bit. In fact for dedicated high-speed internet links MTU sizes can be critical to proper system performance. And that's just one peice of hardware. You have sound, video, and USB and other things that generate interrupts.

Then you have the overhead caused by proccessing the TCP/IP stack, and dealing with the file system and things like that.

So you have I/O wait that takes up cpu time. You have system stuff that takes up cpu time, and a few other ones that I can't remember.

Also 'top' isn't the end-all of telling you what is going on. It misses a lot of things going on, but it's good for identifying big cpu and memory using proccesses easily.

 

[dawks]

Originally posted by: drag
For instance if you have a gigabit ethernet network it has small traditional ethernet type frames, or mtu's or whatever. Each one can generate a interrupt to get your cpu's attention. That's why using 'jumbo packets' or MTU metrics up to 9000 can help out with network performance quite a bit. In fact for dedicated high-speed internet links MTU sizes can be critical to proper system performance. And that's just one peice of hardware. You have sound, video, and USB and other things that generate interrupts.

Then you have the overhead caused by proccessing the TCP/IP stack, and dealing with the file system and things like that.

Warning - Stepping off topic!
I was sort of curious about that.. I run Folding@Home and am always looking to get the most out of my system for it. Previously, I had a hub splitting my cable modem connection between two systems. being that its a cable internet connection, there is constantly packets comming it, and I was wondering how much time the CPU was spending looking at those packets and saying 'wtf, these arent for me' and tossing them. Something like that isnt noticeable really, and is probably pretty small, but for something like F@H or SETI it COULD maybe have an effect.. especially added up over 2,3,4,5 years..

 

[kamper]

Originally posted by: dawks

Originally posted by: drag
For instance if you have a gigabit ethernet network it has small traditional ethernet type frames, or mtu's or whatever. Each one can generate a interrupt to get your cpu's attention. That's why using 'jumbo packets' or MTU metrics up to 9000 can help out with network performance quite a bit. In fact for dedicated high-speed internet links MTU sizes can be critical to proper system performance. And that's just one peice of hardware. You have sound, video, and USB and other things that generate interrupts.

Then you have the overhead caused by proccessing the TCP/IP stack, and dealing with the file system and things like that.

Warning - Stepping off topic!
I was sort of curious about that.. I run Folding@Home and am always looking to get the most out of my system for it. Previously, I had a hub splitting my cable modem connection between two systems. being that its a cable internet connection, there is constantly packets comming it, and I was wondering how much time the CPU was spending looking at those packets and saying 'wtf, these arent for me' and tossing them. Something like that isnt noticeable really, and is probably pretty small, but for something like F@H or SETI it COULD maybe have an effect.. especially added up over 2,3,4,5 years..

That shouldn't have much of an impact, as your ethernet card can tell that the packet is going to the wrong MAC address without the processor's help. That doesn't make complete sense to me though, cause I'm not sure how something like libpcap could grab that kind of packet (and I believe it does) if there was never an interrupt.

 

[Mark R]

I had a hub splitting my cable modem connection between two systems. being that its a cable internet connection, there is constantly packets comming it, and I was wondering how much time the CPU was spending looking at those packets and saying 'wtf, these arent for me' and tossing them. Something like that isnt noticeable really, and is probably pretty small, but for something like F@H or SETI it COULD maybe have an effect.. especially added up over 2,3,4,5 years..

The card hardware can recognise which MAC address packets are sent to - if the destination MAC address on the packet matches the card's MAC (or the broadcast MAC) then the card generates an interrupt. If the MAC doesn't match the packet is discarded by the card and the host PC never even knows about them.

Most NICs also support what's called 'promiscuous' mode - in this mode, the MAC check is disabled and all packets trigger an interrupt and are passed to the OS. (This is how traffic analysers work).

 

[Nothinman]

Measuring CPU will never be 100% accurate becaue the CPU is always either at 0% or 100%, it's either executing code or it's not. The number you see in top is an average usage from over a predetermined snapshot, like say 1000 ticks.