From owner-freebsd-hackers Tue Jun 6 10:45:29 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA28603 for hackers-outgoing; Tue, 6 Jun 1995 10:45:29 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA28589 for ; Tue, 6 Jun 1995 10:45:24 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA18938; Wed, 7 Jun 1995 03:45:07 +1000 Date: Wed, 7 Jun 1995 03:45:07 +1000 From: Bruce Evans Message-Id: <199506061745.DAA18938@godzilla.zeta.org.au> To: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG, james@miller.cs.uwm.edu Subject: Re: Interval timer/System clock Sender: hackers-owner@FreeBSD.ORG Precedence: bulk >I think I now understand the problem, but I beleive the interval timers and >select is still broken in FreeBSD. Having my druthers, I would rather have >the timers return after a 10ms sleep, than have the sleep system call be off >by +-0.5ms. It would be off by up to (-10 + epsilon)ms. >Every other system I tested implemented these timers so a user program could >clock at the same speed as the system clock. In FreeBSD, the select Try Linux. I helped "fix" it too. >and interval timers can't return at the time specified since that would >break sleep. Actaully, in FreeBSD they return 10ms late. No, they return an average of 5ms late for random calls and about 10ms late only for synchronous calls, provided of course the application making them gets scheduled enough - on a heavily loaded system it may only run every few hundred ms. >I am at a loss to provide a fix for this. I beleive the attached select >system call should return after approx 10ms -- not 20ms, don't you? >Is the correct fix for this to subtract 1 from the hzto() call in >sys_generic.c. This is the correct incorrect fix :-). It makes average timeout 5ms too small instead of 5ms too large, and timeouts of 10ms may be reduced to 0. >Also, for the Interval timers, is the correct fix to subtract 1 from the >realitexpire? Since sleep uses the interval timers -- will this fix >the interval timers and break posix sleep? I think it is correct but haven't tested it. POSIX sleep is difficult to implement using interval timers (the current version fails to restore the alarm timeout correctly), but the periodic alarm is not relevant so changing relitexpire() won't affect sleep(). >Is there a clean solution that will fix this 1/2 tick problem and still >allow select and the interval timers to work the way they do on other OSes? >Or will FreeBSD be known as the system that is always 10ms late? :-) >... >#define WAIT_TIME 10000 A wait time of 1 can be made to work right. Bruce