From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 21:57:36 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 0E1B98BD; Sun, 23 Nov 2014 21:57:36 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 92F6EC73; Sun, 23 Nov 2014 21:57:35 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id r20so4020355wiv.8 for ; Sun, 23 Nov 2014 13:57:34 -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 :cc:content-type:content-transfer-encoding; bh=mWCZhQnMA3mCVuCtcYYp1W0SnYq0W0afeR+a7E+hI+8=; b=ILv7HEKZI8ywse+KkXQmF8xt2r32xZdr0U6lDaVsfzlaaXlp0L+JCO1Nedt4XPg/zL CaEjLjNlgVW8UrPgUft+n1izKPcOhZswRK5qS8xfMxzZACj3lJlQa2VCoBdioMkFuflJ fF6lYKOmaXVmRYD/TNfQ020mKecZhwsuxv9qfRqx8LTVOzNAhZVr3M3Drd8Sn3smUuaZ 8SIy0nTCML/p8ae7Y5FeT/ATPmIeeZW5S5lWO8jCYQ2YljOFsY1SLeDNtmiKUq1dlDhI kuDrtb6UXxVxtSXfydt5iYQvDXbQ2kJpuGc82+T/blKPqUz4ZforT6dR53+l/9l8YJW4 UJpg== MIME-Version: 1.0 X-Received: by 10.180.186.40 with SMTP id fh8mr15751777wic.40.1416779853965; Sun, 23 Nov 2014 13:57:33 -0800 (PST) Received: by 10.180.8.7 with HTTP; Sun, 23 Nov 2014 13:57:33 -0800 (PST) In-Reply-To: <54723E7E.8080509@freebsd.org> References: <20141123174555.GB1228@albert.catwhisker.org> <54723E7E.8080509@freebsd.org> Date: Sun, 23 Nov 2014 22:57:33 +0100 Message-ID: Subject: Re: top -d1 behavior From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= To: Allan Jude Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers 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 21:57:36 -0000 On Sun, Nov 23, 2014 at 9:07 PM, Allan Jude wrote: > On 2014-11-23 14:34, Fernando Apestegu=C3=ADa wrote: >> On Sun, Nov 23, 2014 at 6:45 PM, David Wolfskill = wrote: >>> On Sun, Nov 23, 2014 at 06:11:02PM +0100, Fernando Apestegu=C3=ADa wrot= e: >>>> Hi hackers, >>>> >>>> While writing a small script for a friend, I run into a peculiar top b= ehavior: >>>> >>>> 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 + i= dle_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. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >> > > You would either need to make top sleep for 1 second and then calculate Not really. The computation is possible. Do you mean we would need two readings of cp_time to be _accurate_? We state in the man page something like this: "As with ps(1), things can change while top is collecting information for an update. The picture it gives is only a close approximation to reality" And in any case, why 1 second? The default interval between updates is 2 seconds. This can be overridden with -s but the flag is ignored if -d1 is present so we don't have a way to let the user decide for how long he/she wants to wait until the result is calculated. > 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. Agreed. But this is mostly unexpected (and can lead scripts to fail): $ top -d1 last pid: 1013; load averages: 0.54, 0.59, 0.43 up 0+00:11:33 22:39:27 37 processes: 2 running, 35 sleeping CPU: % user, % nice, % system, % interrupt, % idle Mem: 327M Active, 169M Inact, 98M Wired, 1984K Cache, 76M Buf, 375M Free Swap: 3615M Total, 3615M Free What I would suggest is this: - Change top so it can show results for cpu states even for -d1 _and_ specifically state in the man page that in this case, the result can be specially inaccurate due to 'cold start' effect. - If the previous thing doesn't seem reasonable, state in the man page that the CPU states line is kind of "broken" when -d1 is specified. Cheers. > > -- > Allan Jude >