runq-sz not reporting in whole numbers with one cpu

[Kirk Reindl]

10.20
E-Box
1 CPU

I have question regarding the output in the runq-sz column of the sar -q command.

In my mind I believe a system with only one CPU should only report whole numbers in the runq-sz column. Why? Because any whole number devided by one should be that number. The only thing that may change this is if there is a one and half process. Aren't you either a process or not a process?

Please look at this output:

@ccchpcis::root_ /> sar -qM 5 10

HP-UX ccchpcis B.10.20 E 9000/806 09/06/02

11:19:02 runq-sz %runocc swpq-sz %swpocc
11:19:07 1.0 20 0.0 0
11:19:12 2.0 20 0.0 0
11:19:17 0.0 0 0.0 0
11:19:22 1.7 60 0.0 0
11:19:27 0.0 0 0.0 0
11:19:32 1.0 60 0.0 0
11:19:37 1.7 60 0.0 0
11:19:42 0.0 0 0.0 0
11:19:47 1.5 40 0.0 0
11:19:52 1.0 20 0.0 0

Average 1.4 28 0.0 0
@ccchpcis::root_ />

If you read the man page on sar -q runq-sz it states, "Average length of the run queue(s) of processes in memory and runable.

Because it states average, I could understand non-whole numbers on a multiple CPU system (IE--3CPUs--1st with 2proc in queue 2nd with 5 proc in queue and 3rd with 3proc in queue-----10 divided by 3= 3.3), but not on a single CPU system.

Am I on to anything here?? Any insight would be appreciate.

Thanks
Kirk Reindl

[Tom Danzig · Accepted solution]

You're collecting runq data in 5 second intervals. The reported runq-sz id the average of all the samples (i.e. ticks) in the 5 second interval.

[keith persons]

Kirk,

It's the result of statistical averaging. The only way you would always get a whole number every time, even on a single processor machine, is if the sum of all the datapoints is always evenly divisible by the number of those datapoints. The probability of this occurring (those damned sadistics again...^o^) is so small as to be statistically insignificant. Hope this helps.

Keith