Date: Sun, 23 Nov 2014 15:07:26 -0500 From: Allan Jude <allanjude@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: top -d1 behavior Message-ID: <54723E7E.8080509@freebsd.org> In-Reply-To: <CAGwOe2aSYuW=T3-%2Brq2eBS=4PruVARAXXZismyjDEkOOEKofHA@mail.gmail.com> References: <CAGwOe2Zp2cHhCb%2Br_m5HZYJFyc=3DDsPEi7v_7ZVxJ0fkO1jEA@mail.gmail.com> <20141123174555.GB1228@albert.catwhisker.org> <CAGwOe2aSYuW=T3-%2Brq2eBS=4PruVARAXXZismyjDEkOOEKofHA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --84eH9cpPAC0AlhsLFSx4XV5lirn4Cc6mq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2014-11-23 14:34, Fernando Apestegu=C3=ADa wrote: > On Sun, Nov 23, 2014 at 6:45 PM, David Wolfskill <david@catwhisker.org>= wrote: >> On Sun, Nov 23, 2014 at 06:11:02PM +0100, Fernando Apestegu=C3=ADa wro= te: >>> 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 eac= h >> of the 5 states, it is necessary to determine the extent to which thos= e >> 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 <=3D=3D user_1 - user_0 >> nice_delta <=3D=3D nice_1 - nice_0 >> sys_delta <=3D=3D sys_1 - sys_0 >> intr_delta <=3D=3D intr_1 - intr_0 >> idle_delta <=3D=3D idle_1 - idle_0 >> >> Then sum the deltas: >> >> Interval_total =3D 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 =3D=3D> 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 jus= t >> updated in to stable/10 @r274909.) >=20 > 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? >=20 > 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 =3D=3D 1 but we are not. >=20 > Cheers. >=20 >> >> Peace, >> david >> -- >> David H. Wolfskill david@catwhisker.org >> Taliban: Evil cowards with guns afraid of truth from a 14-year old gir= l. >> >> See http://www.catwhisker.org/~david/publickey.gpg for my public key. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 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. --=20 Allan Jude --84eH9cpPAC0AlhsLFSx4XV5lirn4Cc6mq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUcj6CAAoJEJrBFpNRJZKfGX4P/j9VBa3IfmuUyiv74vqFAyJr 3IYR7ZmNmGMWvBPGYdhABejrKu3zasc+YsLrFnRZ9K4Qp1c8XBAO+l4uEc9lwX2b 0qZE2ZnBjDhpdQGkq8K73Kz18piOExcPcDY9MAG+WmdyIvB+VH0LU1ILFddqMyg0 Maq2AQJprQ6omXPjJElZygkWi+57xmiE/X0+QJn2R5gsJbAV+UASZLVJ2mE2RGiI oOJOahqsysT7XeKk6tII51NsOVVixjNMoMrFPtFBiP8uxwiqlhzhhJldKE/G6IkQ E26PztFhDcdpc2gYJoITFVs2Ry4h6wMhtshbTocKtbBd2kt+lDKv15nfkaQnppjC 986iGxmEnjo6hBn/wQ9L8hBAze+wwL+gS9UobgOP9CSUiowSUeM7Qb6czTnfNq10 Sp06mxNHmp0LJY5+2OUIAbGhjeU015L5dzCskpUFOcw2pNrhEorVyC1GYHDgkEKa +OBx+Mc/tRDOh+Qv//QS69QOcXXhRUTRmSfr33DzrJtCluTt68YVDjgTkOhZwGF3 0zYLdJF4tJiOWyqGP8RBJBuCzoJ/ed1qfK8V7FTsIdSoqsZNFZjhEEtibMF0qunm 5PHqXwOW6zOAobtKy4wTKxGwCHZfHmoLndI4o5OTVB7aRefcFP8qLwuP6LADoTw4 q1rfvDcB9zAAll6tllr/ =n4Rv -----END PGP SIGNATURE----- --84eH9cpPAC0AlhsLFSx4XV5lirn4Cc6mq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54723E7E.8080509>