Date: Wed, 7 Jun 1995 10:30:45 -0500 From: Jim Lowe <james@miller.cs.uwm.edu> To: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Interval timer/System clock Message-ID: <199506071530.KAA13630@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> FreeBSD isn't a real time system, so consistent timing is impossible to
> guarantee, and you shouldn't be surprised to have to do more work to
> get close to it.
I realize that FreeBSD isn't a real time system. The Internet isn't
a real time network either; nevertheless, packet video and audio seem
to work.
I agree that consistent timing is difficult to do, but I think the
behavior of FreeBSD should be documented as a feature since most other
system work differently.
The select man page says:
If timeout is a non-nil pointer, it specifies a maximum interval to wait
for the selection to complete. If timeout is a nil pointer, the select
blocks indefinitely. To affect a poll, the timeout argument should be
non-nil, pointing to a zero-valued timeval structure.
I would add a comment here about the wait interval to select. Something like:
The wait interval is determined by the system clock. Timeout values
are rouned up to the resolution of this clock (typically 10
milliseconds). A wait interval of 10ms will usually wait
between 10 and 20ms on a FreeBSD system, a wait interval of 20ms
will wait between 20 and 30ms. This behavior is currently inconsistant
with other Unix systems where the wait interval may fall between
0 and 10ms and 10 and 20ms respectively.
>
> Have you looked at the rtprio command and syscalls? At rtprio 0, a
> process is guaranteed priority over all user processes except of course
> the others at rtprio 0. I think the priority doesn't affect swapping,
> so for consistent timing a real time process might want extra wakeups to
> keep itself in core and early wakeups to allow time for swapping it in;
> after an early wakeup it should check call gettimeofday() to check
> exactly when it got woken up. These methods may help even if rtprio is
> not available. However, they are no help for processes that always run
> every clock tick.
Yes, I don't think it will help in my case. I need to be able to receive
packets from the network (out of order), reorder them and place them on
the crt or play them via a sound card with eye and ear coordination. From
studies that have been going on for years, this usually requires a 10-20ms
interval timer. Many other workstation vendors have increased their
system clock to 200hz for this reason and many others.
>
> >While it is possible to make the interval timers work by subtracting one
> >from the reloaded value I don't think it is possible to make the select
> >system call return on time with the current implementation. This will
> >make it very difficult to write portable programs that rely on timings
> >of accuracies of 10ms.
>
> Settle for 20ms under FreeBSD-current.
I would apply the following patch to kern_time.c:
*** kern_time.orig.c Mon Jun 5 11:36:02 1995
--- kern_time.c Wed Jun 7 09:29:47 1995
***************
*** 315,321 ****
&p->p_realtimer.it_interval);
if (timercmp(&p->p_realtimer.it_value, &time, >)) {
timeout(realitexpire, (caddr_t)p,
! hzto(&p->p_realtimer.it_value));
splx(s);
return;
}
--- 315,321 ----
&p->p_realtimer.it_interval);
if (timercmp(&p->p_realtimer.it_value, &time, >)) {
timeout(realitexpire, (caddr_t)p,
! hzto(&p->p_realtimer.it_value) - 1);
splx(s);
return;
}
At least this makes the Interval timers work the way one would expect.
If you don't think the above patch is correct, then I would add another
comment to the setitimer man page similar to the select comment, since
the behavior of FreeBSD is inconsistant with previous versions of FreeBSD
and most other systems out there.
-Jim
FreeBSD 2.0.5 -- it is guaranteed never to be early, but it is usually only
10ms late :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506071530.KAA13630>