From owner-freebsd-current@freebsd.org Fri Nov 6 18:47:04 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 603EEA282ED; Fri, 6 Nov 2015 18:47:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1B11C2B; Fri, 6 Nov 2015 18:47:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 0DC5E1A482D; Sat, 7 Nov 2015 05:46:53 +1100 (AEDT) Date: Sat, 7 Nov 2015 05:46:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore cc: Hans Petter Selasky , Luigi Rizzo , Rasool Al-Saadi , "freebsd-net@freebsd.org" , Alexander Motin , FreeBSD Current Subject: Re: Timing issue with Dummynet on high kernel timer interrupt In-Reply-To: <1446829230.91534.425.camel@freebsd.org> Message-ID: <20151107050810.M3139@besplex.bde.org> References: <6545444AE21C2749939E637E56594CEA3C0DCCC4@gsp-ex02.ds.swin.edu.au> <5638B7B5.3030802@selasky.org> <6545444AE21C2749939E637E56594CEA3C0DE7FF@gsp-ex02.ds.swin.edu.au> <563B2703.5080402@selasky.org> <6545444AE21C2749939E637E56594CEA3C0E0BD9@gsp-ex02.ds.swin.edu.au> <563C6864.2090907@selasky.org> <563C786C.1050305@selasky.org> <563CC186.9000807@selasky.org> <563CD533.2000909@selasky.org> <1446828229.91534.417.camel@freebsd.org> <563CDA8F.5010901@selasky.org> <1446829230.91534.425.camel@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=cK4dyQqN c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=nlnVIGYx78Tj1a5HvFcA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Fri, 06 Nov 2015 19:19:07 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 18:47:04 -0000 On Fri, 6 Nov 2015, Ian Lepore wrote: > On Fri, 2015-11-06 at 17:51 +0100, Hans Petter Selasky wrote: >> On 11/06/15 17:43, Ian Lepore wrote: >>> On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote: >>>> Hi, >> >>> >>> Do the test II results change with this setting? >>> >>> sysctl kern.timecounter.alloweddeviation=0 >> >> Yes, it looks much better: >> >> debug.total: 10013 -> 0 >> debug.total: 10013 -> 0 >> ... > This isn't the first time that the alloweddeviation feature has led > people (including me in the past) to think there is a timing bug. I > think the main purpose of the feature is to help save battery power on > laptops by clustering nearby scheduled wakeups to all happen at the > same time and then allow for longer sleeps between each wakeup. I was trying to remember the flag for turning off that "feature". It gives the bizarre behaviour that on an old system with a timer resolution of 10 msec, "time sleep 1" sleeps for 1 second with an average error of < 10 msec, but with a timer resolution of 1 msec for hardclock and finer for short timeouts, "time sleep 1" sleeps for an average of an extra 30 msec (worst case 1.069 seconds IIRC). Thus high resolution timers give much lower resolution for medium-sized timeouts. (For "sleep 10", the average error is again 30 msec but this is relatively smaller, and for "sleep .001" the average error must be less than 1 msec to work at all, though it is likely to be relatively large.) > I've been wondering lately whether this might also be behind the > unexplained "load average is always 0.60" problem people have noticed > on some systems. If load average is calculated by sampling what work > is happening when a timer interrupt fires, and the system is working > hard to ensure that a timer interrupt only happens when there is actual > work to do, you'd end up with statistics reporting that there is work > being done most of the time when it took a sample. I use HZ = 100 and haven't seen this. Strangely, HZ = 100 gives the same 69 msec max error for "sleep 1" as HZ = 1000. Schedulers should mostly use the actual thread runtimes to avoid sampling biases. That might even be faster. But it doesn't work so well for the load average, or at all for resource usages that are averages, or for the usr/sys/intr splitting of the runtime. It is good enough for scheduling since the splitting is not need for scheduling. Bruce