Re: NTPD unable to adjust local clock

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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