Date: Fri, 03 Oct 2014 08:50:12 -0400 From: John Baldwin <jhb@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-hackers@freebsd.org, Adrian Chadd <adrian@freebsd.org>, Paul Albrecht <palbrecht@glccom.com> Subject: Re: freebsd 10 kqueue timer regression Message-ID: <2499075.KMdpQjyIZI@ralph.baldwin.cx> In-Reply-To: <1412297389.12052.46.camel@revolution.hippie.lan> References: <8ABC0977-FB8F-45E7-ACCC-BFA92EE22E1C@glccom.com> <1412288106.12052.39.camel@revolution.hippie.lan> <1412297389.12052.46.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, October 02, 2014 06:49:49 PM Ian Lepore wrote: > On Thu, 2014-10-02 at 16:15 -0600, Ian Lepore wrote: > > On Thu, 2014-10-02 at 16:00 -0400, John Baldwin wrote: > > > On Thursday, October 02, 2014 3:53:28 pm Ian Lepore wrote: > > > > On Thu, 2014-10-02 at 12:47 -0700, Adrian Chadd wrote: > > > > > I'm confused; it's doing 50 loops of a 20msec timer, right? So > > > > > that's > > > > > > 1000ms. > > > > > > > Yes, so the entire loop should take 1000ms maybe + 1ms. Instead it > > > > takes 1070. When I run it on an armv6 system running -current it > > > > takes > > > > 1050. When I run it on my 8.4 desktop (pre-eventtimers) it takes > > > > 1013. > > > > > > > > -- Ian > > > > > > What if you set kern.eventtimer.periodic=1? > > > > Some interesting results... > > > > HZ 100 500 1000 > > > > --------------------------------- > > periodic=0 1050 1050 1080 > > periodic=1 1110 1012 1049 > > > > > > The 1080 number was +/- 3ms, all the other numbers were +/- 1ms (except > > for one outlier of 24363 at 100Hz non-periodic which I'm going to > > pretend didn't happen). > > > > The 1050 numbers are probably each 20ms sleep actually taking 21ms, but > > the old tvtohz code with -1 adjustments from the old email thread isn't > > in play anymore. I don't know how to account for the other numbers at > > all. There's all kinds of stuff I don't understand in the new code > > involving tick thresholds and such. > > > > -- Ian > > The attached patch seems to fix the problem in what I think is the most > correct way: scheduling the callout with absolute times based on the > time the current event was scheduled for plus the requested interval. > The net effect should be metronomic events that do not drift (or phase > shift if you prefer) over time, regardless of any latency involved in > processing the events. > > This makes all the numbers in the tests I ran above come out 1000. > > It doesn't make me understand the strange results from the prior tests > any better. > > -- Ian Are you running ntpd or ptpd? If so, perhaps try the original tests without the patch. That said, I think one of the reasons the old code worked was that the previous callout had the equivalent of the C_HARDCLOCK flag set. Thus, when the timer interrupt fires and we rescheuled for N ticks, it was actually N ticks - <time since the timer interrupt that triggered this callout> (if that makes sense?). Now I think what is happening is that that the callout_reset_sbt() is doing 'delta time t + <time since the timer interrupt>' and that that accounts for your numbers. In that case, I wonder if the reason you are seeing such large gaps is that you have Cx states enabled (including C1E) and that those are making that second factor large enough to account for the skew. Try setting machdep.idle=spin as a test (this is a better test than ntpd/ptpd I think). The reason I don't like using C_ABSOLUTE is that in theory that will result in longer or shorter intervals if time is adjusted via ntp/ptp, whereas historically EVFILT_TIMER has been CLOCK_UPTIME based instead of CLOCK_REALTIME. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2499075.KMdpQjyIZI>