Date: Thu, 02 Oct 2014 16:15:06 -0600 From: Ian Lepore <ian@FreeBSD.org> To: John Baldwin <jhb@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: <1412288106.12052.39.camel@revolution.hippie.lan> In-Reply-To: <201410021600.17740.jhb@freebsd.org> References: <8ABC0977-FB8F-45E7-ACCC-BFA92EE22E1C@glccom.com> <CAJ-VmokPNgckHiR0znp6p4u2NRO0aOR_eaOVaBWe7cWDp2_o5g@mail.gmail.com> <1412279608.12052.24.camel@revolution.hippie.lan> <201410021600.17740.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1412288106.12052.39.camel>