[reSIProcate] Timers: why system time?

[Byron Campen]

	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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2482 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20081031/aa8c7303/attachment.bin>