Poco test using clock_gettime() and gettimeofday()

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Nov 17 12:41:00 GMT 2014


Hi David,

On Nov 15 16:56, David Stacey wrote:
> I'm trying to get the (rather extensive) testsuite for poco-1.4.7 passing -
> or at least satisfying myself that any failures are not due to a Cygwin
> problem. The last test I have to worry about is 'testDequeue' from the
> Foundation testsuite.
> 
> The Poco code uses two clock classes, one that uses clock_getttime() and the
> other uses gettimeofday(). The test creates two timestamps using the two
> clock classes, both 0.1 seconds in the future. clock_gettime() is polled
> repeatedly until the timestamp is reached. Then the other timestamp is
> checked (using gettimeofday()) to ensure that 0.1 seconds has elapsed on
> this clock also.
> 
> I've managed to condense this down into the sample programme attached. This
> always passes in Fedora 20, but passes or fails randomly in Cygwin.
> 
> I'm not convinced that the test is valid. Poco seems to be making
> assumptions about clock_gettime() and gettimeofday() that simply aren't
> guaranteed to hold - but obviously do in Fedora at least. For instance, the
> test must be assuming that either the accuracy of the two routines is
> identical, or be making assumptions about rounding in the less accurate
> routine.
> 
> I think it would be better to patch the test so that it uses clock_gettime()
> exclusively (and not gettimeofday() at all), and then this problem will
> disappear. But I thought I would submit it here to see what you thought
> before raising a ticket with the Poco developers.
> 
> What do you think?

Same as you.  One problem is that CLOCK_REALTIME (which is the one used
by gettimeofday) is not monotonic by definition, see for instance the
Linux man page:

  This  clock is  affected by discontinuous jumps in the system time
  (e.g., if the system administrator manually changes the clock), and by
  the incremental adjustments performed by adjtime(3) and NTP.

The second problem, and that's the one affecting this testcase mostly,
is the accuracy of the timer (see clock_getres function).

Implemenation details:

For the monotonic clock, Cygwin uses the
Windows performance counters, which have a pretty high accuracy.

Up to Windows 7, Cygwin uses the values returned by
GetSystemTimeAsFileTime as system time.  The accuracy of this clock
is rather on the low side.

Starting with Windows 8, Cygwin's realtime clock uses the new function
GetSystemTimePreciseAsFileTime, which returns the system time with an
accuracy < 1 µs.

I tried your testcase under Windows 8.1, and it never fails.  On
Windows 7 it's as you said, it fails a lot.  Still, I think the
testcase is flawed, because it makes assumtions about the accuracy
of two different clock sources, which is invalid.


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20141117/e0fe6ff7/attachment.sig>


More information about the Cygwin mailing list