X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=O1bISU64EvzNAyC80XmXcxSdP0Q04+jOEGXcTLbmkluRGG4PIuYt9
	ByOpAeL5xOQ8D8zpM/36Rch4iWuTjEAFLWs3LVjJ3ctcKYP1e79uKr7OOtsvJCEM
	5maMQvzFf7RqqNv2NGG6+KH+5gqlGQe6maQXV1K+LrhdAydw1XOJWI=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=4YQsXXcu3G6WYoXfslm7cr1+0bg=; b=glm/1J2Ej7VksZX+ZnHB5Z3EXc/j
	+sySfozO7gN1Od3fXziO8LQU7eShAtuC50BYEU+LmgI2KpGXlszKZfMO/KiWAGK7
	Yp0YEgoiHxZfZd1WF/XJwTZ+TQLHs6FAFiOHYDSij3583aWzqUFzjsSXYw6eacTa
	DTjdAZ9Idf6vcxM=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Mon, 17 Nov 2014 13:41:42 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Poco test using clock_gettime() and gettimeofday()
Message-ID:	<20141117124142.GF3151@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<546785C6 DOT 4030303 AT tiscali DOT co DOT uk>
MIME-Version:	1.0
In-Reply-To:	<546785C6.4030303@tiscali.co.uk>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--+ts6NCQ4mrNQIV8p
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.
>=20
> I've managed to condense this down into the sample programme attached. Th=
is
> always passes in Fedora 20, but passes or fails randomly in Cygwin.
>=20
> 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, t=
he
> 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.
>=20
> I think it would be better to patch the test so that it uses clock_gettim=
e()
> 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.
>=20
> 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 =C2=B5s.

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

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--+ts6NCQ4mrNQIV8p
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUae0FAAoJEPU2Bp2uRE+g284P/0X1fQ0tpAd/8wnvfWH7OkVo
2yEwsLFO20Aerun9X017rSFCx+Qg9tF1jL4Yy+yUZgHROZfHMry8GPoTfE/2FFxt
GxhsZQ0lgFFxDzVwUno15s5BTgVhX2kkB8yM2kCdpN0kUgMmtf3siDO5pRF+pGod
ukUqM21nOaWNryXIjUoO9YbO9Az0O+Nr/UMrXUFyAC/lox07bxUcELD77x2tUggc
Yeo+K3lqZ2uSzm10aP+A6Of4USp2oZ4g4K8J1vyxTluAahKr72CmXQn0nxs48F5G
suMpLueOjIjBHnM7M873R6ieobpf8RCONbbu6yRfaMHQ1PREtLUv+DOIopGK4dQD
2acFlxut4oexMZ19eSYq5I+PAEMMp9CUSugdCoAkzXc4hf5qP6bOW0JFWSpy/Or7
vHzFXuq42d9EiXH/flFLxkCqnJZY8C/u5fwiG4kjhwoXuYOFZchTqbzow6WicQD3
LrAlYEWo2H724vLpms57gzLZwITb1A7nGt+Ogd/V1t6V6l062mYzKUkAcoaHdxY0
MvAGyaaEfAsJv8YhQlWwMZo8IxXefweY4B+RM0+Xr2d3U6AXGs5+zHMa5w/OyTGj
e14Werp0oXq0UCUaRwW+hL4akW18iacccf6E7qJjQ4S62bBUMJ5BrV9BZoL4wI0k
iuKegiAKgQbhcWLbimZE
=/5WR
-----END PGP SIGNATURE-----

--+ts6NCQ4mrNQIV8p--

- Raw text -