Re: nanosleep returning early

From: Bruce Evans (bde_at_zeta.org.au)
Date: 07/22/04

  • Next message: George D. Gal: "radeon drm code in -current" 
    Date: Fri, 23 Jul 2004 02:25:16 +1000 (EST)
To: John Birrell <jb@cimlogic.com.au>

    On Fri, 23 Jul 2004, Bruce Evans wrote:

    > On Thu, 22 Jul 2004, John Birrell wrote:
    >
    > > On Wed, Jul 21, 2004 at 11:01:20PM +1000, Bruce Evans wrote:
    > > > ...
    > > > The most obvious bug is that nanosleep() uses the low-accuracy interface
    > > > getnanouptime(). I can't see why the the problem is more obvious with
    > > > large HZ or why it affects short sleeps. From kern_time.c 1.170:
    > > > ...
    > > > % getnanouptime(&ts);
    > > >
    > > > This may lag the actual (up)time by 1/HZ seconds.
    >
    > [ (actually tc_tick/HZ seconds)

    > > So, does increasing HZ expose the lower accuracy of getnanouptime() and is
    > > that what I'm seeing?
    >
    > I still don't know the reason. Unfortunately, I deleted your original
    > mail so I can't run the test program in it easily.

    Now I think I know the reason. The interval between clock interrupts
    is supposed to be 1/HZ seconds = `tick' microseconds, but it cannot
    be set nearly that precisely, and the imprecision of inversely
    proportional to HZ. The i8254 counter has a default nominal frequency
    of 1193182 Hz. Suppose that this is perfectly accurate. Then to
    implement clock interrupts at HZ hz, we want to program the i8254's
    maximum count to 1193182/HZ in infinite precision, but counts must be
    integers so we must round. The loss of precision is quite large for
    HZ = 1000: 1193182 / 1000.0 = 1193.182; rounding this (to nearest)
    gives 1193 and an error of 182 in 1193182 = 152 ppm. Also, the extra
    tick added by tvtohz() is only 1000 uS long, so it only has a chance
    of about 152/1000 to compensate for the rounding error. Finally, the
    explicit check that the interval has elapsed cannot compensate for
    errors larger than tc_tick/HZ because getnanouptime() is fuzzy.

    Rounding 1193.182 to nearest happens to round down; thus clock ticks
    are shorter than `tick' microseconds, tvtohz()'s value is too small,
    and nanosleep() may return too early. The loop limits the error to
    about 1 tick in this case. The i8254 frequency may be calibrated or
    set using sysctl to a more (or less) accurate value. Then the rounding
    may go the other way so that tvtohz()'s value is too large and nanoleep()
    may return too late. The loop cannot limit the error in this case.
    The absolute error may be large for long sleeps. E.g., 152 ppm over
    1 day is 13 seconds.

    tvtohz()'s value may also be too large because the i8254 frequency
    is not known accurately. It's nominal value is wrong by 10-100 Hz
    on my systems. I minimize errors from this by calibrating all
    timecounters using a common clock.

    Bruce
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: George D. Gal: "radeon drm code in -current"

    Relevant Pages

    • Re: activating new office 2003
      ... Well,Miss Tick the reason I tried here is because I was redirected ... back to Microsoft when I tried to get answers from Compaq. ... I will redirect my energy ...
      (microsoft.public.office.setup)
    • Re: PHOTOS FROM INSIDE IRAN
      ... of economics, which is why I voted for him in the first place. ... and that is the reason why I intend to vote ... tick, tick, tick ... ... (never mind the ailing stock market ... ...
      (rec.photo.equipment.35mm)
    • Re: [PATCH 1/5] generic clocksource updates
      ... Is there a reason, why requirements which are known from existing ... confuse John when I talked about handling of continuous vs. tick based ... tick patches, as they both reprograms the tick frequency, and need to ...
      (Linux-Kernel)
    • Re: Recovery by Relocation.
      ... but for some reason I do have a love of ... things that go 'tick' and 'tock'. ... My wristpet most days is an old-ish(?) Atlantic automatic. ...
      (alt.sysadmin.recovery)
    • Re: nanosleep returning early
      ... > implement clock interrupts at HZ hz, we want to program the i8254's ... > maximum count to 1193182/HZ in infinite precision, ... > tick added by tvtohzis only 1000 uS long, so it only has a chance ... > of about 152/1000 to compensate for the rounding error. ...
      (freebsd-current)