[reSIProcate] Timers: why system time?

Tue May 26 14:21:02 CDT 2009

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>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20090526/96efc713/attachment.htm>