[reSIProcate] Timers: why system time?

Tue Jun 9 10:35:03 CDT 2009

	So, in your opinion, is this stuff ready for prime time? Should I  
merge into the 1.5 release branch, or hold off for now?

Best regards,
Byron Campen

> Changed the time source from GetTickCount to timeGetTime.  Resip now  
> requires winmm.lib on windows.  This timer has the added feature of  
> increasing the resolution/accuracy of resip timers to 1ms on windows  
> (using timeBeginPeriod(1)), in addition to being monotonic. This is  
> an improvement over GetSystemTime on all Windows OS’s less than  
> Vista where this clock resolution is normally around 15ms.
>
> -justin
>
>
> From: Justin Matthews [mailto:jmatthewsr at gmail.com]
> Sent: Tuesday, May 26, 2009 4:25 PM
> To: 'Scott Godin'
> Cc: 'Cullen Jennings'; 'Alexander Altshuler'; 'resiprocate-devel'
> Subject: RE: [reSIProcate] Timers: why system time?
>
> Good point. 1 second is a little conservative.  The note on accuracy  
> comes from windows ::GetTickCount that is known to be only accurate  
> to the “resolution of the system timer”.  On my system it’s about  
> 15ms, but I have in my notes that the resolution could be around  
> 50ms and that it could be worse under high cpu load (100ms?).  Maybe  
> it’s reasonable to assume that on modern hardware this timer won’t  
> exceed 50ms in accuracy.  If we want a more accurate time  
> measurement then ::timeGetTime() along with timeBeginPeriod(x) could  
> be used to get ~xms accuracy.
>
> Anyway, if T100 is the only timer near 100ms, then I would say that  
> GetTickCount should be fine for the majority of users.   I could add  
> an option for high-performance users that want a more accurate clock.
>
> -justin
>
> From: slgodin at gmail.com [mailto:slgodin at gmail.com] On Behalf Of  
> Scott Godin
> Sent: Tuesday, May 26, 2009 3:21 PM
> To: Justin Matthews
> Cc: Cullen Jennings; Alexander Altshuler; resiprocate-devel
> Subject: Re: [reSIProcate] Timers: why system time?
>
> Hi Justin,
>
> I just noticed a comment you placed in the code:
> "The precision of this clock is available in microseconds, but the  
> accuracy is intended to be no worse than 1 second."
>
> I would think that we require accuracy of at least 50ms.  Many of  
> the SIP based timers are less than 1 seconds - ie. T1 - 500ms, T100  
> - 80ms - what are the implications for these timers?
>
> Thanks,
> Scott
> On Tue, May 26, 2009 at 11:20 AM, Justin Matthews <jmatthewsr at gmail.com 
> > wrote:
> Checked in the monotonic timer code.  It's disabled by default,  
> turned on by
> defining _RESIP_POSIX_MONOTONIC_CLOCK for non-windows and
> _RESIP_WINDOWS_MONOTONIC_CLOCK for windows.
>
> The time functions were moved to a separate file time.hxx and now  
> referenced
> by Timer as the reference clock to use for timing.
>
> NOTE: When using the new monotonic timer if you have assumed that  
> any of the
> timeXXX functions returned system clock time, that code will most  
> likely
> break.
>
> Changed the non-windows function back to clock_gettime.  This  
> function is
> not available on mac osx, so another function will have to be used.   
> There
> are a couple of choices and it's not clear at first glance what the  
> best
> solution would be.  Since I am not running on mac, I will leave the
> implementation up to someone who runs on osx.  Here are some  
> references to
> timing on mac:
>
> http://www.wand.net.nz/~smr26/wordpress/2009/01/19/monotonic-time-in-mac-os-
> x/
> http://www.meandmark.com/timing.pdf
> http://developer.apple.com/qa/qa2004/qa1398.html
>
> Thanks,
>
> -justin
>
> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy at cisco.com]
> Sent: Tuesday, May 19, 2009 12:27 PM
> To: Justin Matthews
> Cc: 'Scott Godin'; 'Alexander Altshuler'; 'resiprocate-devel'
> Subject: Re: [reSIProcate] Timers: why system time?
>
>
> I think I was to blame for the buggy code and it just had some inline
> assembly to use RDTSC instruction.
>
> On May 19, 2009, at 9:00 AM, Justin Matthews wrote:
>
> > Do you remember if the buggy code was using RDTSC or
> > ::QueryPerformanceCounter?  I believe those have potential issues,
> > including
> > changes in CPU frequency.  From what I've read I haven't found any
> > docs
> > stating that GetTickCount has any of these issues and have not found
> > any
> > discussion of related issues.   From my own experience
> > GetTickCount() is not
> > affected by CPU frequency changes and is always increasing (it's
> > actually
> > referenced by Microsoft as a way to keep QPC in-check
> > (http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323).
> > GetTickCount also works on multiple threads and processors/cores.
> >
> > Thanks for bringing attention to this.  If users are still weary of
> > it, then
> > they can continue using the system clock.  Another build option  
> may be
> > useful.
> >
> > -justin
> >
> > -----Original Message-----
> > From: Cullen Jennings [mailto:fluffy at cisco.com]
> > Sent: Tuesday, May 19, 2009 10:07 AM
> > To: Justin Matthews
> > Cc: 'Scott Godin'; 'Alexander Altshuler'; 'resiprocate-devel'
> > Subject: Re: [reSIProcate] Timers: why system time?
> >
> >
> > At one point in time, we had a bug where on machines such a notebook
> > where the system might step the CPU frequency up or down for power /
> > performance reasons, we had  an issue where the timers got messed up
> > because they were using clock counts but the the assumption about  
> CPU
> > frequency was wrong to the time of the timers in seconds was getting
> > messed up. Whatever you do, make sure you don't reintroduce that  
> bug.
> >
> > Cullen
> >
> >
> > On May 19, 2009, at 6:46 AM, Justin Matthews wrote:
> >
> >> Hi,
> >>
> >> Attached is a proposed mod to enable monotonic Timer's on Windows
> >> and *unix.
> >>
> >>
> >> Windows
> >> =========
> >>
> >> * _RESIP_WINDOWS_MONOTONIC_CLOCK  enables/disables the monotonic
> >> timer.  If
> >> disabled, the current ::GetSystemTime is used.
> >>
> >> * The default on Windows Vista and beyond is to
> >> use ::GetTickCount64().  No
> >> special handling is required when using this function.
> >>
> >> * The default on Windows versions < Vista is
> >> GTCLockDuringRange::GTC64().
> >> This implementation is the one given by Alexander, based on his  
> final
> >> comments below.
> >>
> >> * An alternate implementation GTCInterlocked is given and is
> >> intended to
> >> decrease the frequency that the timer must be called and avoid
> >> locking on a
> >> mutex.
> >>
> >> * A third alternative is to simply lock each time the timer is  
> called
> >> (GTCLock)
> >>
> >> * When not running on Vista or higher, GTCLockDuringRange is the
> >> default
> >> because the GTCInterlocked requires the CMPXCHG8B instruction,  
> which
> >> was
> >> introduced in the intel pentium and AMD K5 and is only supported,
> >> without
> >> assembly, using an intrinsic visual c++ function that is only
> >> available in
> >> visual studio 2005 or higher.
> >>
> >> Non-Windows
> >> =========
> >>
> >> * _RESIP_POSIX_MONOTONIC_CLOCK enables the __NR_clock_gettime call.
> >> Note
> >> that on some systems even if _POSIX_MONOTONIC_CLOCK is defined
> >> __NR_clock_gettime may not be, or may require another library
> >> (librt?).
> >> Some improvement in enabling this could probably be done in the  
> build
> >> scripts.
> >>
> >> =========
> >>
> >> Comments?
> >>
> >> Thanks,
> >>
> >> -justin
> >>
> >> -----Original Message-----
> >> From: slgodin at gmail.com [mailto:slgodin at gmail.com] On Behalf Of
> >> Scott Godin
> >> Sent: Wednesday, November 05, 2008 2:40 PM
> >> To: Alexander Altshuler
> >> Cc: Justin Matthews; Byron Campen; Adam Roach; resiprocate-devel
> >> Subject: Re: [reSIProcate] Timers: why system time?
> >>
> >> I think a solution that does not depend on how often getTimeMs is
> >> called is preferred, given that it doesn't have a huge hit on
> >> performance.  This makes the Timer class more usable as a general
> >> utiltiy fn, if used outside of the stack.
> >>
> >> Scott
> >>
> >> On Wed, Nov 5, 2008 at 2:26 PM, Alexander Altshuler <alt at kaluga.ru>
> >> wrote:
> >>> Hi All
> >>>
> >>> The requirements for offered Win32 timer wrap around problem:
> >>> Timer::getTimeMs() must be reasonable often called.
> >>>
> >>> The solution:
> >>> - redefine SipStack::getTimeTillNextProcessMS() that it will  
> return
> >>> 0xfff maximum for example.
> >>>
> >>> PS: Timer::msTillNextWrapAroundTimer() stuff I posted today will  
> be
> >>> unnecessary.
> >>>
> >>> Regards
> >>> Alexander Altshuler
> >>> http://xeepe.com
> >>>
> >>> _______________________________________________
> >>> resiprocate-devel mailing list
> >>> resiprocate-devel at resiprocate.org
> >>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >>>
> >> <Timer.cxx><Timer.hxx><SipStack.cxx><mime-attachment.txt>
> >
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20090609/76296e28/attachment.htm>
-------------- 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/20090609/76296e28/attachment.bin>