Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Jan 2000 17:31:55 -0600
From:      Karl Denninger <karl@Denninger.Net>
To:        David Schwartz <>, Warner Losh <>
Cc:        current@FreeBSD.ORG
Subject:   Re: xntpd - VERY old folks, how about updating? :-)
Message-ID:  <20000102173155.G26048@Denninger.Net>
In-Reply-To: <000101bf5575$e8b342e0$>; from David Schwartz on Sun, Jan 02, 2000 at 03:05:49PM -0800
References:  <20000102164519.A25992@Denninger.Net> <000101bf5575$e8b342e0$>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, Jan 02, 2000 at 03:05:49PM -0800, David Schwartz wrote:
> > Now explain to me how stability of your timing source ON THOSE MACHINES
> > between 10ns and 1us, AS SEEN FROM THE UNIX MACHINE.
> 	A battle you would win is if you said, "synchronizing the time of other
> UNIX machines without specialized hardware over a LAN or WAN". :)

Of course, which is my point.

> 	You can see 2 microsecond differences inside a single machine with no
> specialized hardware. 

MICROseconds.  *NOT* NANOseconds, which is what Paol was claiming!

> You can see 5 microseconds over a good LAN. For
> example, is synchronized to both and
> through a full-duplex 100Mbps LAN switch. Watch this:
> > ntpdate -q -p 8
> server, stratum 1, offset -0.000298, delay 0.02579
> server, stratum 1, offset -0.000302, delay 0.02579
>  2 Jan 15:01:01 ntpdate[2491]: adjust time server
> offset -0.000302 sec
> 	Note that it claims that Tick and Tock agree with each other to 5
> microseconds. But it has been unable to keep its own time to any better than
> 300 microseconds (it's been under heavy load, swapping in fact).

Correct.  And the issue there is that its the COMPLETE timekeeping
environment, not some bullshit-manufacturered claim of 10ns time stability
that is CLEARLY bogus.

As soon as you put a REAL workload on the machine(s) involved interrupt
latency starts to cause trouble.  Hell, just READING THE FRIGGING PORT
to SEE the PPS output involves interrupt latency which is INDETERMINATE
beyond a LOT more elapsed time than 10ns!

> 	In actual reality, the GPSClock 200 is better than the specifications
> indicate. If it really did alternate between 1us early pulses and 1us late
> pulses, stability would be measurably impacted. NTP is very good at
> smoothing things out anyway, especially since it only probes the clock every
> 64 seconds or so.
> 	David Schwartz


My entire point, David, is that there is ZERO actual, real-world difference
between your reasonably-priced receiver and the shilled-for Motorola
receiver that Poul and others like to promote at twice the price.

Now if you're willing to stuff a custom PCI board (that in and of itself
probably violates all manner of FCC regulations in terms of emissions)
to keep nanosecond-level track of the number of "ticks" between seeing
a PPS signal and the processor getting around to reading the latch, then
Poul and the shills might be right on a TECHNICAL level - as long as they
never actually USE that computer for anything, never access a disk, and
never hit any other I/O port.

But that's not the real world, its not a real application, and geeking-up
something just to prove you can (while probably breaking the law in terms 
of emissions - the clock rates to get nanosecond timing accuracy are
non-trivial, and that board would need FCC appoval here in the states)
doesn't count.

It also has ZERO relavence to those of us who want to keep time on our

It is precisely this kind of elitism and bullshit that I continually
run into when trying to deal with the "treehouse" FreeBSD kids, and in 
this particular instance its so blatent that I simply refuse to shut 
up about it.

Karl Denninger (  Web:
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!

To Unsubscribe: send mail to
with "unsubscribe freebsd-current" in the body of the message

Want to link to this message? Use this URL: <>