From owner-freebsd-net@freebsd.org Fri Nov 6 17:00:34 2015 Return-Path: Delivered-To: freebsd-net@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 457C1A262F4 for ; Fri, 6 Nov 2015 17:00:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16ECF1574 for ; Fri, 6 Nov 2015 17:00:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 6 Nov 2015 17:01:05 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tA6H0UPJ051152; Fri, 6 Nov 2015 10:00:30 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1446829230.91534.425.camel@freebsd.org> Subject: Re: Timing issue with Dummynet on high kernel timer interrupt From: Ian Lepore To: Hans Petter Selasky , Luigi Rizzo Cc: Rasool Al-Saadi , "freebsd-net@freebsd.org" , FreeBSD Current , Alexander Motin Date: Fri, 06 Nov 2015 10:00:30 -0700 In-Reply-To: <563CDA8F.5010901@selasky.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> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 17:00:34 -0000 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 > debug.total: 10012 -> 0 > debug.total: 10012 -> 0 > debug.total: 10012 -> 0 > debug.total: 10013 -> 0 > debug.total: 10012 -> 1 > debug.total: 10013 -> 0 > debug.total: 10013 -> 0 > debug.total: 10013 -> 0 > debug.total: 10012 -> 0 > debug.total: 10013 -> 0 > debug.total: 10013 -> 0 > > --HPS 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'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. Maybe it would make sense to only enable the feature by default on battery-powered systems? -- Ian