Re: [reSIProcate] Timers: why system time?
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>