Subject: Re: settimeofday() versus interval tim{ers,ing}
To: None <jonathan@DSG.Stanford.EDU>
From: None <Havard.Eidnes@runit.sintef.no>
List: tech-kern
Date: 09/30/1996 18:00:30
> > The machine in question is a router. It can't set its time
> > until it can reach an NTP server, which it can't in general
> > do until it is running the routing protocols to populate its
> > forwarding table. Once the routing is running it can set the
> > time. Unfortunately, if the time is way off from boot (like
> > the hardware RTC is set to PDT rather than UTC),
>
> There's not much one can do once things have gone that far. As
> someone else is fond of saying, ``don't do that, then''.
I disagree. I do not think there is any tradition for saying "do not
use settimeofday() except right after boot". Certainly the manual
page for settimeofday() does not make any such warning or that setting
the time of day can have such unfortunate side-effects that timers
will "stop firing for an extended period of time".
Rather, I would claim that the application wanting to sleep until a
specific point in (real) time should check the time with
gettimeofday() when it is woken up again. There is no guarantee
that the clock of a given machine will actually be correct at all
times, and an application should be prepared for the possibility
that an error was corrected through settimeofday() while an interval
timer was active.
Furthermore, the way I read the documentation of setitimer() it only
talks about delta values in real time, and without the changes
proposed by Dennis that behaviour is not being preserved in the face
of settimeofday().
Tweaking the boottime variable on settimeofday() actually seems to me
to be the right solution -- if the clock was wrong in the first place
adjusting it on settimeofday() only makes it "right" again (in terms
of "real wall-clock time"). Or am I missing something here?
Apparently there are also in the kernel in several places a need for
"monotonoically increasing fine-resolution time" variable (as
demonstrated by Dennis), and fixing that should be a Good Thing.
All in all I think Dennis' suggestions were all entirely reasonable,
and fail to see why you object so strongly to them.
Regards,
- Havard