Date: Fri, 06 Nov 2015 10:23:05 -0700 From: Ian Lepore <ian@freebsd.org> To: Hans Petter Selasky <hps@selasky.org>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: Rasool Al-Saadi <ralsaadi@swin.edu.au>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Alexander Motin <mav@FreeBSD.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Timing issue with Dummynet on high kernel timer interrupt Message-ID: <1446830585.91534.435.camel@freebsd.org> In-Reply-To: <563CDBF9.3090800@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> <CA%2BhQ2%2Bhm2z0MkB-8w5xJM7%2Biz13r_ZjwmpZBnb30_D_48gaf-w@mail.gmail.com> <563C786C.1050305@selasky.org> <CA%2BhQ2%2Bj0WiGgzV119M1ZQiXP5Z7fq7deVxDPkOhvTc7hpTETKw@mail.gmail.com> <563CC186.9000807@selasky.org> <563CD533.2000909@selasky.org> <1446828229.91534.417.camel@freebsd.org> <563CDA8F.5010901@selasky.org> <563CDBF9.3090800@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2015-11-06 at 17:57 +0100, Hans Petter Selasky wrote: > On 11/06/15 17:51, 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 > > > > Thought I still see some unexpected dips, as the test runs for a > longer > amount of time. Not sure what the cause might be. > > > debug.total: 10013 -> 0 > > debug.total: 10013 -> 0 > > debug.total: 10013 -> 0 > > debug.total: 9844 -> 0 > > debug.total: 10013 -> 0 > > debug.total: 10013 -> 0 > > debug.total: 10012 -> 0 > > --HPS Is it possible your machine is occasionally falling into a deeper sleep state (C3 or whatever)? I think it can take hundreds of microseconds to wake up from some of the deeper power-saving modes. If not power-saving, just plain old system-is-busy could lead to the reduced counts occasionally, since each callout is scheduled as a delta from the current actual wakeup time, not a delta from the current scheduled wakeup time (i.e., there is a phase shift in the firing of events over time). Raising the priority of the test thread into the realtime range might help with system-busy variation. It's also a bit iffy that you're using eventtimers to measure the performance of eventtimers (by using sleep 1 in the script). That explains the +12/13 count every second, not the reduced counts unless we speculate that sleep is returning early (which I have NEVER caught it doing). If you have a PPS source available, that can make a good way to sleep based on an off-box timing signal and avoid using a clock to measure itself. But I doubt it would make a big difference in this case. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1446830585.91534.435.camel>