[reSIProcate] Timers: why system time?

[Adam Roach]

Byron Campen wrote:
>     So, maybe on win32 we need to have something call getTimeMs() 
> every minute? A heartbeat timer of some sort?

You could be even more clever about it than that. Inserting a timer 
immediately before and after the rollover should get you there. That 
way, you have two timers every 49 days, instead of one timer every 
minute. :)

UInt64 timer1Time = 0x00000000FFFFFFF0ui64 | (Timer::getTimeMs() & 
0xFFFFFFFF00000000ui64);
UInt64 timer2Time = timer1 + 33;

Then, all you need is a new Timer constructor that takes an absolute 
time instead of a relative one.

/a

>
> Best regards,
> Byron Campen
>
>> To qualify things further, though: in order for this bug to be 
>> triggered, you would need to have no calls to "Timer::getTimeMs()" 
>> for over two minutes (131.07 seconds, to be more precise) as the 
>> 49.7-day boundary rolls around. In a normally operating SIP stack, 
>> the chances of this happening seem vanishingly small.
>>
>> So, it's a corner case on top of a corner case. And it only happens 
>> on WIN32 systems.
>>
>> /a
>>
>> Byron Campen wrote:
>>>    Ok, so this is in the "much more serious" category. I would not 
>>> be comfortable leaving this be.
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>> Byron Campen wrote:
>>>>>   Let's say one of these timers is at the top of the heap, and 
>>>>> whatever error you're thinking about happens. Are you saying that 
>>>>> not only will that timer be 49 days late, but everything else in 
>>>>> the heap will be too?
>>>>
>>>> Not new timers. But, if we miss the rollover, then everything in 
>>>> the heap at that time will instantaneously appear to be 49.7 days 
>>>> later than their original expiration time. New timers will be 
>>>> inserted in the heap just fine (ahead of the "lost" timers), and 
>>>> expire correctly.
>>>>
>>>> The behavior would be similar to using our current stack and 
>>>> setting the system time to be 49 days in the past while timers are 
>>>> pending.
>>>>
>>>> /a
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Byron Campen
>>>>>
>>>>>> Technically, they won't be "lost" as much as "over 49 days late." 
>>>>>> From a SIP protocol perspective, 49 days is long enough to 
>>>>>> consider the timer lost for all practical purposes.
>>>>>>
>>>>>> /a
>>>>>>
>>>>>> Byron Campen wrote:
>>>>>>>  I can see how we would miss a roll-over with low timer 
>>>>>>> activity, but I am not sure what you mean by "lose timers". If 
>>>>>>> we have lost a timer from a timer heap, that implies the heap is 
>>>>>>> now broken, because that is the only way to "lose" anything. So 
>>>>>>> this is either much more serious, or much less serious than you 
>>>>>>> have stated.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Byron Campen
>>>>>>>
>>>>>>>> Scott (and any other Windows developers on the list):
>>>>>>>>
>>>>>>>> The Windows 49.7-day rollover fix in this patch uses heuristics 
>>>>>>>> to handle the rollover in an efficient manner -- you can 
>>>>>>>> actually lose timers if you have relatively low timer activity 
>>>>>>>> and a multi-minute timer running when the tick count rolls 
>>>>>>>> over.  The chances of this happening are, admittedly, 
>>>>>>>> vanishingly small (especially in normal SIP usage). In any 
>>>>>>>> case, you might want to give that code a quick review to ensure 
>>>>>>>> that you're comfortable with it.
>>>>>>>>
>>>>>>>> Also, I think it's safe to say that it's difficult to test the 
>>>>>>>> correctness of the code, as step one of any such test plan 
>>>>>>>> necessarily involves something like: "boot a Windows machine 
>>>>>>>> and wait 49.6 days." Make sure you're comfortable with that 
>>>>>>>> fact as well.
>>>>>>>>
>>>>>>>> /a
>>>>>>>>
>>>>>>>> Alexander wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Here is a patch to use monotonic clock.
>>>>>>>>> It is 3 modified files from reSIProcate 1.4.
>>>>>>>>> Attached files have Windows (CLRF) eof-style.
>>>>>>>>>
>>>>>>>>> Windows
>>>>>>>>> =======
>>>>>>>>>
>>>>>>>>> GetTickCount() with 16 ms inaccuracy used.
>>>>>>>>> It is very simple to change it to timeGetTime() etc with 1 ms 
>>>>>>>>> accuracy,
>>>>>>>>> but it will require init/fini calls on application level and 
>>>>>>>>> linking
>>>>>>>>> with Winmm.lib
>>>>>>>>> Tested on Windows XP SP2, compiled with VS7.1
>>>>>>>>>
>>>>>>>>> Not tested on Windows CE
>>>>>>>>>
>>>>>>>>> Linux
>>>>>>>>> =====
>>>>>>>>>
>>>>>>>>> If monotonic clock is not available (compile time and runtime) 
>>>>>>>>> it will
>>>>>>>>> fall back to gettimeofday()
>>>>>>>>> I am not familiar with reSIProcate build system so I use 
>>>>>>>>> workaround to
>>>>>>>>> avoid linking with librt:
>>>>>>>>> syscall( __NR_clock_gettime, ... )
>>>>>>>>> instead of clock_gettime(...)
>>>>>>>>>
>>>>>>>>> IMHO it may not work on other POSIX compliant platforms.
>>>>>>>>>
>>>>>>>>> Pass only some basic tests on my Linux PC (2.6.18 kernel)
>>>>>>>>>
>>>>>>>>> Any feedbacks appreciated.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Alexander Altshuler
>>>>>>>>> Xeepe team
>>>>>>>>> http://xeepe.com
>>>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> resiprocate-devel mailing list
>>>>>>>>> resiprocate-devel at resiprocate.org
>>>>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> resiprocate-devel mailing list
>>>>>>>> resiprocate-devel at resiprocate.org
>>>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>