From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20217 invoked from network); 9 Jan 2022 10:22:37 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 9 Jan 2022 10:22:37 -0000 Received: from h4.fbrelay.privateemail.com ([131.153.2.45]) by 4ess; Sun Jan 9 03:15:01 -0500 2022 Received: from MTA-07-4.privateemail.com (mta-07-1.privateemail.com [198.54.122.57]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by h3.fbrelay.privateemail.com (Postfix) with ESMTPS id 2CCFD1801143 for <9front@9front.org>; Sun, 9 Jan 2022 03:14:58 -0500 (EST) Received: from mta-07.privateemail.com (localhost [127.0.0.1]) by mta-07.privateemail.com (Postfix) with ESMTP id CB0D318000B0 for <9front@9front.org>; Sun, 9 Jan 2022 03:14:41 -0500 (EST) Received: from localhost (unknown [10.20.151.152]) by mta-07.privateemail.com (Postfix) with ESMTPA id CA93818000AD for <9front@9front.org>; Sun, 9 Jan 2022 03:14:40 -0500 (EST) Date: Sun, 9 Jan 2022 00:14:30 -0800 From: Anthony Martin To: 9front@9front.org Message-ID: References: <7e13be65-765d-4f6e-ad2a-e1646f01c53d@sirjofri.de> <87k0fbzimt.fsf@turtle-trading.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k0fbzimt.fsf@turtle-trading.net> X-Virus-Scanned: ClamAV using ClamSMTP List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: element-scale factory markup configuration generator Subject: Re: [9front] Understanding milli-CPUs (/dev/sysstat) Reply-To: 9front@9front.org Precedence: bulk Benjamin Riefenstahl once said: > > I wrote a daily script which sends me an email via a cron job. The > > mail contains this load value from /dev/sysstat. > > I see that this device is described in cons(3). I do not see from that > documentation what time span sysstat uses. It seems that you need to > write to the file to reset it and than read from it after some time. > But it also says that the vale is "decayed over time" which sounds like > some kind of moving average. It does not say (unless I missed it), how > fast this decay is (i.e. again over which time span). /sys/src/9/port/proc.c:/^accounttime /* only one processor gets to compute system load averages */ if(m->machno != 0) return; /* * calculate decaying load average. * if we decay by (n-1)/n then it takes * n clock ticks to go from load L to .36 L once * things quiet down. it takes about 5 n clock * ticks to go to zero. so using HZ means this is * approximately the load over the last second, * with a tail lasting about 5 seconds. */ n = nrun; nrun = 0; n = (nrdy+n)*1000*100; load = ((uvlong)load*(HZ-1)+n)/HZ; m->load = load/100; Nrdy is the total number of procs in the scheduler queues. Nrun is the number of procs running on each mach (cpu). The multiplication and accompanying division by 100 is there to handle precision problems with high values of HZ (the clock tick frequency). Cheers, Anthony