> It probably should take a command-line argument for the delay, but I was
> too lazy!
		[ ... SIGTERM after 10 second sleep ... ]

Quick tests on my own provided negatives.  Only I could see was normal.

On the other hands, "out-of-sync xntpd" has been observed across
several ports; NetBSD/pmax (Personal DECstation) and NetBSD/alpha
(DEC3000/300).  Masanari Tsubai, a NetBSD/newsmips guy, told me that
he is observing clock slip with his news3400.  He suspects hardclock()
is lost in some degree depending system load.  He has not provided me
any info about "weird-time-statistic", yet. 

Tohru Nishimura

> I've noticed this for a while now (since not longer after 1.4 came out
> at a guess), but only today have I got an up-to-date matching kernel
> and userland on my -current pmax.  The CPU time used is very wrong -
> here's an example of a small program that sits in a "while(1);" loop
> for 10 seconds, with reports from tcsh's built-in time command and
> /usr/bin/time:
>
>        mona:/var/tmp 32> time /usr/bin/time ./x
>               10.25176 real       261.90 user         0.20 sys
>        262.567u 0.425s 4:22.53 100.1%  0+0k 2+1io 0pf+0w

--