Date: Thu, 12 Jul 2012 08:34:40 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Ian Lepore <freebsd@damnhippie.dyndns.org>, Paul Albrecht <albrecht@glccom.com> Subject: Re: kqueue periodic timer confusion Message-ID: <201207120834.40745.jhb@freebsd.org> In-Reply-To: <1342040447.1123.31.camel@revolution.hippie.lan> References: <1342036332.8313.8.camel@albrecht-desktop> <1342040447.1123.31.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> > Hi,
> >
> > Sorry about this repost but I'm confused about the responses I received
> > in my last post so I'm looking for some clarification.
> >
> > Specifically, I though I could use the kqueue timer as essentially a
> > "drop in" replacement for linuxfd_create/read, but was surprised that
> > the accuracy of the kqueue timer is much less than what I need for my
> > application.
> >
> > So my confusion at this point is whether this is consider to be a bug or
> > "feature"?
> >
> > Here's some test code if you want to verify the problem:
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <unistd.h>
> > #include <errno.h>
> > #include <sys/types.h>
> > #include <sys/event.h>
> > #include <sys/time.h>
> >
> > int
> > main(void)
> > {
> > int i,msec;
> > int kq,nev;
> > struct kevent inqueue;
> > struct kevent outqueue;
> > struct timeval start,end;
> >
> > if ((kq = kqueue()) == -1) {
> > fprintf(stderr, "kqueue error!? errno = %s",
strerror(errno));
> > exit(EXIT_FAILURE);
> > }
> > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0);
> >
> > gettimeofday(&start, 0);
> > for (i = 0; i < 50; i++) {
> > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) ==
-1) {
> > fprintf(stderr, "kevent error!? errno = %s",
strerror(errno));
> > exit(EXIT_FAILURE);
> > } else if (outqueue.flags & EV_ERROR) {
> > fprintf(stderr, "EV_ERROR: %s\n",
strerror(outqueue.data));
> > exit(EXIT_FAILURE);
> > }
> > }
> > gettimeofday(&end, 0);
> >
> > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 +
end.tv_usec - start.tv_usec) / 1000) - 1000);
> >
> > printf("msec = %d\n", msec);
> >
> > close(kq);
> > return EXIT_SUCCESS;
> > }
> >
> >
>
> What you are seeing is "just the way FreeBSD currently works."
>
> Sleeping (in most all of its various forms, and I've just looked at the
> kevent code to verify this is true there) is handled by converting the
> amount of time to sleep (usually specified in a timeval or timespec
> struct) to a count of timer ticks, using an internal routine called
> tvtohz() in kern/kern_time.c. That routine rounds up by one tick to
> account for the current tick. Whether that's a good idea or not (it
> probably was once, and probably not anymore) it's how things currently
> work, and could explain the fairly consistant +1ms you're seeing.
This is all true, but mostly irrelevant for his case. EVFILT_TIMER
installs a periodic callout that executes KNOTE() and then resets itself (via
callout_reset()) each time it runs. This should generally be closer to
regulary spaced intervals than something that does:
for (;;) {
usleep(20 * 1000);
}
Which should be subject to the problem you are describing. It would be
interesting to see if the callout routine itself is running at the right
interval or if it is being delayed. If the latter, then that should be fixed
if at all possible. You could investigate that by adding KTR traces to the
relevant callout routine (so recording the TSC timestamp each time the callout
runs), and then parsing the ktrdump output to compute TSC deltas and examining
that distribution to see if it is noisy or incorrect, etc.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207120834.40745.jhb>