[reSIProcate] Timers: why system time?

[Adam Roach]

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
>