top -d1 behavior

[Allan Jude]

On 2014-11-23 14:34, Fernando Apesteguía wrote:
> 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.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 

You would either need to make top sleep for 1 second and then calculate
the delta, or make it calculate the average of each time by taking the
counter and dividing it by the uptime.

Neither seem like what the user would expect.

-- 
Allan Jude

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20141123/96dfc216/attachment.sig>