I
would prefer to wait until 1.6. I would like to hear some feedback from
linux/posix users and it would be nice to get an implementation for OS/X. In my
opinion, the windows version is ready for prime time; I will be using it in our
upcoming product releases.
Thanks,
-justin
From: Byron Campen
[mailto:bcampen@xxxxxxxxxxxx]
Sent: Tuesday, June 09, 2009 11:35 AM
To: Justin Matthews
Cc: 'Scott Godin'; 'resiprocate-devel'
Subject: Re: [reSIProcate] Timers: why system time?
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?
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.
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.
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?
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?
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>
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
|