Frequency Reference for NTP Use?

[Alex Satrapa]

On Sunday, July 14, 2002, at 06:07 , Tomasz Ciolek 
<tmc at dreamcraft.com.au> wrote:

> Alex, so what you are atelling me is that you want a solution, that we 
> would nornmally package into an oven sized device. and be bale to 
> compress it into a PCMCIA card so that you can correct the drift in the 
> clock crystal in your laptop?

Don't confuse "ovenised" with "ovensized" :)

The best non-GPS frequency reference I've found so far is an ovenised 
Quartz system.  This is a rack-mount system (1 RU) that costs around 
$AU4,500.  It has a stability approaching 1 second per year. Combine 
that with a small rack-mount PC (1 RU), and you have something not quite 
portable, but not too bulky either.  Suitable for a remote datalogging 
station.  I would never use a laptop as a datalogging station - it's not 
environmentally sealed.

If I'm willing to trust the GPS network, then I can bring the cost down 
to the region of $600 for the Kallisto GPS ISA card ($300 for external 
GPS with PPS, but you have to use serial comms for the time signal).  
But you have to trust the GPS network and you have to have good GPS sky.

If I have a reliably low-latency connection to the Internet, I can use 
publicly available Stratum 2 servers, for the cost of the Internet 
feed.  But for that to be useful when using an on-demand Internet 
connection, I need about 1 month of permanent connection for the NTP 
server to calculate the drift of the local clock.  Then if I move the 
machine to a different environment (temperature, humidity, ambient 
electrical fields), I have to recalibrate all over again.

On Sunday, July 14, 2002, at 09:15 , Wally <wally at wic.net.au> wrote:

> I guess the question to ask is how accurate do you need it?
>
> If you sync the PC's clock at the start ... How much drift is acceptable
> after week? or after 1 month?

A PC clock will drift by as much as a minute a day or as little as a 
second a week - and that's just clocks I've personally had experience 
with.

However, the drift is apparently consistent after a warmup period.  The 
xntpd software knows about this, and is able to store the drift value 
for the local clock.  So if my network has a month or so of 
uninterrupted access to the upstream NTP server, the internal NTP 
servers will be able to calculate the drift of their local clock 
accurately.
Then I can expect that at the end of the month of separation from the 
Internet, my clocks might only be out by a couple of seconds. However, 
the xntpd software has a hard limit of 1 day without polling external 
servers before it reports to its clients that it is unsynchronised - I 
don't know whether the undisciplined local clock counts as an "external 
server".  There's an easy way to find out, I guess - just apply a couple 
of new rules to my IPTABLES setup to block NTP packets inbound or 
outbound from my firewall.  Time to set up a few new machines, since I 
don't particularly want to mess up my existing network for the sake of 
this experiement.

For the purposes of putting a "sent date" on email, I don't care if my 
clock is out by an hour.  For the purposes of digitally signing an email 
(or timestamping firewall logs for forensics and legal purposes), I want 
my clock to be accurate to the second.  One day my life, my fortune or 
my job might depend on it, so I want to get it right.

In the immediate future, I'm content with my local clock.  When I start 
to get serious about keeping time, I'll invest in an ovenised quartz 
Reference Frequency.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 225 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20020715/fc9131e4/attachment.bin