NTPD unable to adjust local clock

[Bill Hacker]

Joerg Sonnenberger wrote:

On Thu, Apr 07, 2005 at 11:04:03AM +0100, Miguel Filipe wrote:

Hi there, in the middle of this imense and juicy talk, anyone talked
with the maintainers, so that OpenNTPd could be correctws upstream,
were it should, instead of burdening DragonFly team.
Or at least, all bugs/fixes should be pushed upstream.


Sure, any patch I propose also goes to Henning.


I vote for ntpd because 1, 2 second diferences between my servers
makes no problem.
I think kerberos and IDS's can tolerate that.


I do consider any time difference over +-20 ms a problem and I want
to fix that.
Joerg
+- 20 ms?

Forget the cheap/non-existent MB clock, and the constant syncing.

Under ten bucks American, half that again for a PCB, IC's, and
connector to attach to the often unused FDC connector as drive 'B:',
and we could have a better-than 2.5 ppm source, stable over a
-20C to +80C range or so and with 0C to ambient settle of ~ 30 sec:
http://www.mouser.com/access/?pn=CVT32-20.000&sn=crystekcrystals

http://www.maxim-ic.com/view_press_release.cfm/release_id/1013

At higher prices, there are .1 ppm thru .005 ppm TCXO / OCXO packages:

http://193.113.211.245/tfc/pages/ocxo_oscillators.html

On-board Stratum 3 anybody?

Slap a DragonFlyBSD logo on it and sell it instead of tee-shirts to raise
project funds?
Blurb:

DragonFlyBSD - High Precision
Lightweight  Kernel  Threading
Sync it once per the life of the system - part of the install,
read it directly 'whenever', and move on to something that
can *not* be done better in hardware.
Software, in an interrupt-driven environment using a packet-switched
network, is going to come just how close to matching that?
And do *what* whenever the link is dodgy?
Bill