Re: [reSIProcate] Timers: why system time?

["Alexander" <alt@xxxxxxxxx>]

Hi

Yes I also have rejected QPC not only because of problem on some
hardware, but because of very poor performance.
See: http://www.nvidia.com/object/timer_function_performance.html
Tests above are in full conformance with my own tests.

Below is some notes concerning Windows/Posix details: 

Windows
=======

- GetTickCount() - fastest, but with 16 ms inaccuracy
- timeBeginPeriod(1), timeGetTime(), timeEndPeriod(1) - about 1 ms
accuracy
Keep in mind that that WaitForSingleObject() etc uses the same internal
clock as timeGetTime().
Without timeBeginPeriod(1) WaitForXXXX functions will have the same 16
ms timeout inaccuracy.

By my opinion for SIP purpose 16 ms inaccuracy is not a problem.

Another issue is DWORD return value. 
<MSDN>
Therefore, the time will wrap around to zero if the system is run
continuously for 49.7 days.
</MSDN>
If timer is called on reasonable often interval we may wrap it into
class and manage wrap around by our own.
Even thread safe implementation is just 2-3 times slower then current
GetSystemTimeAsFileTime() code.


Posix
=====

It is possible to detect CLOCK_MONOTONIC accessibility on compile time -
_POSIX_MONOTONIC_CLOCK.

We have to check availability of monotonic clock on runtime also:
syscall( __NR_clock_getres, CLOCK_MONOTONIC, &dummy ) == 0

There is another important issue - to be consistent we must use
monotonic timer for pthread timeouts (mutexes & conditions).

If using of monotonic clock is impossible it will fall back to
CLOCK_REALTIME (always exists).

With best regards
Alexander Altshuler
Xeepe Project
http://xeepe.com

-----Original Message-----
From: Justin Matthews [mailto:jmatthewsr@xxxxxxxxx] 
Sent: Thursday, October 23, 2008 10:28 PM
To: 'Alexander'; 'resiprocate-devel'
Subject: RE: [reSIProcate] Timers: why system time?

Hi Alexander,

My only concern is the use of QPC.  It has a few issues
(http://support.microsoft.com/kb/274323
http://msdn.microsoft.com/en-us/library/bb173458(VS.85).aspx) and is one
of
the more CPU intensive timer calls.  It seems that every timer has its
issues, and there is a lot of info on the web about windows timers, but
resip may be able to use GetTickCount.  It's the fastest of the
available
timer calls, but has the worst accuracy (10-55ms on average, depending
on
CPU load and underlying platform). This should be accurate enough for
resip
though. It's also a 32-bit timer, so appropriate measures need to be
taken
when comparing timing values, etc. 

Whatever is chosen, I hope that the functionality can be wrapped in
timer
classes and could be swapped out with different time functions down the
road
if needed.

Thanks,

-justin