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@xxxxxxxxx]
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@xxxxxxxxx
[mailto:slgodin@xxxxxxxxx] 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?
Scott
On Tue, May 26, 2009 at 11:20 AM, Justin Matthews <jmatthewsr@xxxxxxxxx> 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
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>
>
|