[Click] When Timers fall behind

[Eddie Kohler]

On thinking about this some more, I decided that the previous 
reschedule_after() semantics could be improved.  You guys should know the 
latest semantics:

* 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.

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

I think these semantics are better than the previous semantics, but they are 
different.  All, let me know what you think.

Eddie


Eddie Kohler wrote:
> Roberto,
> 
> Remember that initialize() is called exactly once.  If initialize() is called 
> before the system time adjustment then it will take a long time for _next to 
> catch up!
> 
> I don't see what's so hard to understand about this.  If you just want to run 
> the timer every 10000ms use _timer.schedule_after_msec(10000).
> 
> Eddie
> 
> 
> Roberto Riggio wrote:
>> Eddie,
>>
>> ok in order to simply the problem I've increased the confusion. This is the
>> run_timer method:
>>
>> void
>> Blank::run_timer(Timer *)
>> {
>>   click_chatter("Pruning...")
>>   _next += Timestamp::make_msec(10000);
>>   _timer.schedule_at(_next);
>> }
>>
>> _next is set to Timestap::now() in the element's initialize method.
>>
>> R.
>>
>> ----- "Eddie Kohler" <kohler at cs.ucla.edu> wrote:
>>> Roberto,
>>>
>>> What is "now"?  Not Timestamp::now().  It must be some variable that
>>> you are 
>>> maintaining.
>>>
>>> If you want the timer to run once, use
>>>
>>> schedule_at(Timestamp::now() + delay)
>>>
>>> or equivalently
>>>
>>> schedule_after(delay)
>>>
>>> If you want the timer to run 60 times, use
>>>
>>> now = _timer.expiry();
>>> ...
>>> schedule_at(now + delay)
>>>
>>> or
>>>
>>> reschedule_after(delay)
>>>
>>> Eddie
>>>
>>>
>>> Roberto Riggio wrote:
>>>> Eddie,
>>>>
>>>> I don't know if it is really a problem. I use schedule_at
>>>> in order to schedule the timer at X. Then, in run_timer I do 
>>>> something like this:
>>>>
>>>> schedule_at(now + delay)
>>>>
>>>> now let's assume that I change the system clock while click is
>>>> running moving it forward one hour.
>>>>
>>>> Then if delay is 1 min run_timer is executed 
>>>> 60 times right after the clock change is committed.
>>>>
>>>> Is this the expected behavior?
>>>>
>>>>
>>>> ----- "Eddie Kohler" <kohler at cs.ucla.edu> wrote:
>>>>> Roberto,
>>>>>
>>>>> I don't know exactly what the "problem" is here, which behavior do
>>> you
>>>>> not like?
>>>>>
>>>>> The meaning of "schedule_after" is "schedule at X past the current
>>>>> time."  The 
>>>>> meaning of "scheudle_at" is "schedule at the moment the system
>>> clock
>>>>> says X." 
>>>>>   These methods are behaving correctly.
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>> Roberto Riggio wrote:
>>>>>> Hi,
>>>>>>
>>>>>> the problem is the following: if I use the schedule_at function
>>>>>> in order to reschedule a timer I get the timer scheduled several
>>>>>> times if i move the system clock forward.
>>>>>>
>>>>>> On the other hand if I use the schedule_after function this
>>>>>> does not occur and the timer is scheduled only one even if I move
>>>>>> the clock several years in the future.
>>>>>>
>>>>>> The problem is annoying because I'm using click over an embedded 
>>>>>> platform that forget the system date at each reboot (the default
>>>>> date
>>>>>> is Jan 2000).
>>>>>>
>>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click