Re: [reSIProcate] Timers: why system time?
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@xxxxxxxxx]
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@xxxxxxxxx]
> 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@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] 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@xxxxxxxxx>
>> 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@xxxxxxxxxxxxxxx
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>> <Timer.cxx><Timer.hxx><SipStack.cxx><mime-attachment.txt>
>