Date: Sun, 2 Jan 2000 17:31:55 -0600 From: Karl Denninger <karl@Denninger.Net> To: David Schwartz <davids@webmaster.com>, Warner Losh <imp@village.org> Cc: current@FreeBSD.ORG Subject: Re: xntpd - VERY old folks, how about updating? :-) Message-ID: <20000102173155.G26048@Denninger.Net> In-Reply-To: <000101bf5575$e8b342e0$021d85d1@youwant.to>; from David Schwartz on Sun, Jan 02, 2000 at 03:05:49PM -0800 References: <20000102164519.A25992@Denninger.Net> <000101bf5575$e8b342e0$021d85d1@youwant.to>
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 > > is MATERIALLY different to any process WHICH THAT DEVICE MAY INTERACT WITH > > 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, youknow.youwant.to is synchronized to both tick.gpsclock.com and > tock.gpsclock.com through a full-duplex 100Mbps LAN switch. Watch this: > > > ntpdate -q -p 8 209.133.29.16 209.133.29.20 > server 209.133.29.16, stratum 1, offset -0.000298, delay 0.02579 > server 209.133.29.20, stratum 1, offset -0.000302, delay 0.02579 > 2 Jan 15:01:01 ntpdate[2491]: adjust time server 209.133.29.20 > 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 > http://www.gpsclock.com/ Yep. 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 networks. 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 (karl@denninger.net) Web: http://childrens-justice.org 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000102173155.G26048>