From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 19:34:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F0FEC17 for ; Sun, 23 Nov 2014 19:34:33 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EE4CC3B for ; Sun, 23 Nov 2014 19:34:33 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id b13so10650215wgh.17 for ; Sun, 23 Nov 2014 11:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nEBZx1rMUl64DjyhrkgneVDbsXF3hwp4iNeSdDSv0pk=; b=XZSJYVIpEchd/FIkHfz+ZC6PnAui8gnBxEzgw/QHN3nqp/TRQXTf78uxalKuVRFpZm QAqLOk7x5TDYHtSxRsZu+yyh79joMXdzdRomuXm43fszVGFU1EBFMU5NfGiiwZCkIA9R SRmVkSNg11t26BGSwKMzABEHnOWljSllDDlv9JbyA95fFtJXabRmuw9dilgHgOhNl+C7 HOnT5hzfZEsxDAdO9B4qLxSXob0wcAykppzvIO7LlrBpeBUHCbbFegnkvlbZte9lgdKO 6ykNMmVKz9q/AO4yQf0cRhyV63CW79tsdj5ThP4ZYEovhibXwNMAhYM+8uBNjpm+KdxZ Tn7A== MIME-Version: 1.0 X-Received: by 10.180.211.79 with SMTP id na15mr9324410wic.36.1416771271069; Sun, 23 Nov 2014 11:34:31 -0800 (PST) Received: by 10.180.8.7 with HTTP; Sun, 23 Nov 2014 11:34:31 -0800 (PST) In-Reply-To: <20141123174555.GB1228@albert.catwhisker.org> References: <20141123174555.GB1228@albert.catwhisker.org> Date: Sun, 23 Nov 2014 20:34:31 +0100 Message-ID: Subject: Re: top -d1 behavior From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= To: David Wolfskill , =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 19:34:33 -0000 On Sun, Nov 23, 2014 at 6:45 PM, David Wolfskill wro= te: > On Sun, Nov 23, 2014 at 06:11:02PM +0100, Fernando Apestegu=C3=ADa wrote: >> Hi hackers, >> >> While writing a small script for a friend, I run into a peculiar top beh= avior: >> >> 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 <=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 + idl= e_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 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 =3D=3D 1 but we are not. Cheers. > > Peace, > david > -- > David H. Wolfskill david@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.