>> I know _I_'d certainly be annoyed if I requested a timer tick once a
>> second and then, according to gettimeofday(), actually got it every
>> 1.001 second, thereby slowly drifting with respect to second
>> boundaries.

> But who was calling adjtime() to adjust your clock in this example,
> and why were they doing this?  If it was xntpd (or even timed) the
> only reason they would have been calling adjtime() in this way is
> because your system clock frequency is 0.1% too slow, and they're
> correcting it.

Yeah...but when I call setitimer with it_interval=<1,0>, I expect
tv_usec to be the same every wakeup (modulo jitter on the order of the
clock tick size, if ticks per second is not an integer).

But if the implementation just decides to sleep for 100 clock ticks
(assuming a 100Hz clock), without compensating for adjtime's
adjustment, then I will end up sleeping for not 1.000000 second, but
rather .999000 or 1.001000 second - and gettimeofday() return values
will reflect this.

What it has to do is to sleep for 99, or 101, ticks every once in a
while.  And getting _that_ right is...well, perhaps not really _hard_,
but not entirely trivial.

> That is, without adjtime() you would be getting interrupts every
> 0.999 seconds and slowly drifting with respect to second boundaries,
> with adjtime() adjusted time you're more likely to get interrupts
> every 1.000 seconds, and far more likely to get really excellent long
> term stability [...].

Yes - _if_ my one-second interval is one adjtime-adjusted second, as
returned by gettimeofday().  The danger I fear is that it won't be,
that it will simply be HZ clock ticks each time.

> I can't think of a real situation where adjtime()-adjusted time would
> be inferior over the long term to what your system clock provides.

Neither can I.  And provided adjtime-adjusted time is the time my
interval timers run in, I'm happy.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D