From owner-freebsd-current@FreeBSD.ORG  Sat Nov 29 15:57:32 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4B9E616A4CE; Sat, 29 Nov 2003 15:57:32 -0800 (PST)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 80B9343FDD; Sat, 29 Nov 2003 15:57:30 -0800 (PST)
	(envelope-from phk@phk.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hATNvRgS021078;
	Sun, 30 Nov 2003 00:57:27 +0100 (CET)
	(envelope-from phk@phk.freebsd.dk)
To: "Marc G. Fournier" <scrappy@hub.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Sat, 29 Nov 2003 19:23:12 -0400."
             <20031129191941.X99096@ganymede.hub.org> 
Date: Sun, 30 Nov 2003 00:57:27 +0100
Message-ID: <21077.1070150247@critter.freebsd.dk>
cc: stable@FreeBSD.org
cc: current@FreeBSD.org
cc: Kris Kennaway <kris@obsecurity.org>
Subject: Re: Corrected gettimeofday() test code 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Nov 2003 23:57:32 -0000

In message <20031129191941.X99096@ganymede.hub.org>, "Marc G. Fournier" writes:

Hmm, I'm not saying this makes sense, but at least there is
an emergent pattern...

Col#1 is duration of the shift, sorted in increasing order.
Col#2 is the delta to the line above.
Notice stratification on 50msec boundaries:

	695.426189 -
	695.426190 0.000001
	695.426191 0.000001
	695.426191 0.000000
	695.426192 0.000001

	695.476192 0.050000
	695.476193 0.000001
	695.476194 0.000001

	695.526193 0.049999
	695.526194 0.000001
	695.526196 0.000002
	695.526196 0.000000
	695.526198 0.000002
	695.526201 0.000003

	695.576193 0.049992
	695.576195 0.000002

	695.626195 0.050000

	695.676192 0.049997
	695.676195 0.000003

The only place I can think of 50msec in relation to the timecounter
is NTIMECOUNTER * 1/HZ.

Try to modify some of that, and see if you can affect the results.

In particular, try to yank NTIMECOUNTER _way_ up, like a thousand
and see if the problem goes away.

Another (uglier) option is that ACPI/SMI/APM or similar BIOS magic
screws up the i8254 on a regular basis, or even that the latch
functionality of the i8254 doesn't work properly.  This is not
unheard off.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.