Re: PSA: Clock drift and pkgin

> The attached (untested) patch reverts to the old algorithm
> specifically for the case of rearming a periodic timer, leaving the
> new algorithm with +1 in place for all other uses.

> Now, it's unclear to me whether this is correct, because it can have
> the following effect.  Suppose ticks happen on intervals of time T.
> Then, owing to unpredictable and uncontrollable scheduling delays,
> the following sequence of events may happen:

> Time 0*T: timer_settime(.it_value =3D T, .it_interval =3D T), arms timer at 1*T
> Time 1*T + 0.9*T: timer expires, rearms timer at 2*T
> Time 2*T + 0.1*T: timer expires, rearms timer at 3*T

> The duration between these consecutive expirations of the timer is
> 0.2*T, even though we asked for an interval of T.

True.

In my opinion that is the correct behaviour; userland requested timer
ticks at multiples of T, so there is a conceptually infinite stream of
(conceptual) ticks generated at those times.  Those then get turned
into real events when the kernel can manage it.  But a delay for one of
them should not affect any other, except for the case where one is
delayed long enough to occur after another's ideal time, in which case
I would consider it acceptable (though not required) to drop one of the
two.

> [...POSIX...]

IMO if POSIX forbids the above, POSIX is broken and should, in this
respect, be ignored.  One reason for using facilities taking structs
itimerval is for ticks to _not_ be delayed by delay of previous ticks.
If POSIX cannot be ignored for whatever reason, I would argue that a
new facility that _does_ provide undelayed ticks should be provided.
(I'm partial to timer sockets, but I am hardly unbiased. :-)

> On the other hand, if it's not correct to do that, I'm not sure
> correct POSIX periodic timers can attain a target _average_ interval
> between expirations [...]

I would argue that it's misleading, to the point I would call it
incorrect, to call such a thing "periodic".

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B