Re: [Lcd4linux-devel] Two new FIXMEs in timer code :)

[Martin Z. <co...@mz...>]

Hi Michael,

I'm quite busy as well, so never mind the delay... ;)

 > A clean solution cold be to check if timestamp of next timer is later
 > than "now + timer.delay"? (or probably "now + 2*timer.delay") ?

That sounds clever.  Though I think that checking for

   now + timer.delay + CLOCK_SKEW_DETECT_TIME_IN_S

would be best.  This way, time skew detection wouldn't depend on the 
actual timer intervals and users might still easily adapt the detection 
limit to their needs.

 > I also think that the correction "set it to current" is wrong: It should
 > be set to "now + timer+delay" or something similar.

You're right.  I think that adding the detected time skew to the timer 
triggers would be best.

 >> The other "thing" seems like a real bug to me (and is of course related
 >> to clock skew). In case a clock skew has been detected, the next
 >> upcoming timer (and *only* that) is updated to the new time.
 >>
 >> Now imagine two timers of different intervals and a clock skew of one
 >> hour (think of the transitions between summer and winter time). The
 >> next upcoming timer (let's say number 1) is updated and triggers on.
 >> But what about the second? If I get that right, it will not trigger for
 >> at least a whole hour while the user awes in wonder!
 >>
 >> So I think we should update *all* timers:
 >>
 >> for (timer = 0; timer< nTimers; timer++)
 >> Timers[timer].when = now;
 >>
 >> instead of only the next upcoming one:
 >>
 >> Timers[next_timer].when = now;
 >
 > I'm not sure about this: probably all the other timers would be
 > corrected one by one as soon as they are processed (every timer should
 > be the "next occuring timer" somethime, and then would be corrected)

Think of these (bogus) trigger time stamps (in seconds):

   current time:  3615
   timer #0:      3616
   timer #1:      3618

Now imagine that the system time is set backward by one hour (think of 
winter time):

   current time:    15
   timer #0:      3616
   timer #1:      3618

By the current code, timer #0 (the next upcoming one) would be corrected:

   current time:    15
   timer #0:        15
   timer #1:      3618

But timer #0 will *still* the next upcoming timer, so timer #1 will 
*not* be corrected (and thus not trigger) for an hour:

   current time:    16    17    18  ...  3618  3619
   timer #0:        16    17    18  ...  3618  3619
   timer #1:      3618  3618  3618  ...  3618  3621

Feel free to correct me, but I think that I'm correct. :)

Finally, I have updated the function "timer_inc()" (rev 1141).  The 
function now checks how many trigger intervals have passed since a given 
timer has been updated.  This might be due to "negative clock skew" 
(think of summer time) or the fact that some processing took too long 
(i.e. fetching of a web site).  These missed trigger intervals are then 
skipped and the user is notified so that he may adapt his timer settings.

This handling is essential, otherwise unprocessed timers might stack up 
and would trigger continuously while at the same time becoming 
notoriously late and unreliable.  As the "timer_inc()" is called right 
after calling a timer's callback, the code change also shouldn't do any bad.

Happy new year (somewhat late) from Germany,

Martin
-- 
www.mzuther.de
www.radix-musik.de