[Click] When Timers fall behind

Bart Braem bart.braem at ua.ac.be
Wed Mar 5 03:04:31 EST 2008


On Wednesday 05 March 2008 02:44:37 Eddie Kohler wrote:
> * Timers cannot be scheduled too far in the past.  If a timer is
>    scheduled more than 1 second in the past, it may be silently updated to
>    the current system time.  If it's scheduled more than 2 seconds in the
>    past, it will definitely be silently updated to the current system time.
>    Thus, repeated application of reschedule_after() will never get more
> than 2 seconds behind; after that the timer will jump ahead to the current
> system time.  This will make timers more robust to system time changes and
> such.
>
This seems like interesting behaviour but I find it dangerous. 
You might want to know that timers have been scheduled in the past and are 
corrected, certainly if you need higher precision. It might be a good idea to 
give a notification, similar to what happens with packets with too few 
headroom.

> * Timer fairness: no single rescheduled timer can starve other expired
>    timers.
>

Of course this is a good idea!

Regards,
Bart
-- 
Bart Braem
PATS research group - IBBT
Dept. of Mathematics and Computer Sciences
University of Antwerp
Campus Middelheim, G3.30
Middelheimlaan 1
B-2020 Antwerpen, Belgium
Phone: +32 (0)3 265.32.91
Fax: +32 (0)3 265.37.77
Web: www.pats.ua.ac.be/bart.braem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part.
Url : https://pdos.csail.mit.edu/pipermail/click/attachments/20080305/004d0110/attachment.pgp 


More information about the click mailing list