[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