top -d1 behavior

Fernando Apesteguía fernando.apesteguia at gmail.com
Sun Nov 23 19:34:33 UTC 2014


On Sun, Nov 23, 2014 at 6:45 PM, David Wolfskill <david at catwhisker.org> wrote:
> On Sun, Nov 23, 2014 at 06:11:02PM +0100, Fernando Apesteguía wrote:
>> Hi hackers,
>>
>> While writing a small script for a friend, I run into a peculiar top behavior:
>>
>> top -d1 shows only one 'iteration' of the information screen, but in
>> it, the CPU percentages line is not well formed: there are 5 columns
>> with the '%' symbol, but no values are shown. This only happens for
>> -d1 and this behavior is deliberately done in the sources (see
>> 'dostates' variable).
>> ...
>> My point is: why are we doing this? If we remove that constraint, top
>> would show the values for -d1. I don't know if they would be really
>> accurate, but not printing anything doesn't seem a nice behavior
>> either (especially when this is not documented in the man page)
>> ....
>
> At the time of the inital display, the program only has access to the
> counters (from kern.cp_time) from one instant.
>
> In order to calculate the relative proportion of CPU time spent in each
> of the 5 states, it is necessary to determine the extent to which those
> counters changed over an interval.
>
> If we call the time when the first sample is taken "T0" and the time
> when the second sample is takne "T1", we get something like:
>
> Time          user    nice      sys    intr    idle
>   T0        user_0  nice_0    sys_0  intr_0  idle_0
>   T1        user_1  nice_1    sys_1  intr_1  idle_1
>
> To determine the relative proportions for the interval from T0:T1, we
> first determnine the differences (or deltas):
>
> user_delta <== user_1 - user_0
> nice_delta <== nice_1 - nice_0
> sys_delta  <== sys_1 - sys_0
> intr_delta <== intr_1 - intr_0
> idle_delta <== idle_1 - idle_0
>
> Then sum the deltas:
>
> Interval_total = user_delta + nice_delta + sys_delta + intr_delta + idle_delta
>
> Then, for each of user, nice, sys, intr, and idle, the percentage for
> the interval is
>
> 100 * _delta / Interval_total.
>
> Here's a sample (produced by a little shell script):
>
> albert(10.1-S)[6] get_sys_info -N 0 -c 2 -w 10 kern.cp_time
> time:1416763949 kern.cp_time:20934 0 28872 5664 1027225
> time:1416763959 kern.cp_time:20980 0 28933 5674 1029686
>
> Given those numbers, we have:
>
> Time          user    nice      sys    intr    idle
> 1416763949   20934       0    28872    5664 1027225
> 1416763959   20980       0    28933    5674 1029686
>
> The differences:
>               user    nice      sys    intr    idle
>                 46       0       61      10    2461
>
> The total of the deltas is 46+0+61+10+2461 ==> 2578.
>
> The percentages:
>               user    nice      sys    intr    idle
>               1.78    0.00     2.37    0.39   95.46
>
>
> (System's uptime, in this case, was a little over an hour -- I had just
> updated in to stable/10 @r274909.)

OK, but if we use -d1, T0 is 0 since cp_time, cp_old and cp_diff are
all declared as static, so we should not have any problems with just
having one lecture of the kern.cp_time sysctl and doing all the
calculation above. Am I right?

That's in fact what top in linux (from the procps package) does. They
have the CPU_t struct declared as static. top in Linux is able to show
CPU statistics for number of iterations == 1 but we are not.

Cheers.

>
> Peace,
> david
> --
> David H. Wolfskill                              david at catwhisker.org
> Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.


More information about the freebsd-hackers mailing list