[H-GEN] Should I NTP reference clock driver?
Bruce Campbell
bc at humbug.org.au
Mon Aug 19 08:32:34 EDT 2002
[ Humbug *General* list - semi-serious discussions about Humbug and ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]
On Mon, 19 Aug 2002 ben.carlyle at invensys.com wrote:
> I have a situation where I want to synchronise clocks. I have a number of
> sun machines that really want to know the time in something approaching
> millisecond accuracy. I have a GPS clock. Normally I'd jump to the
right.
> The GPS clock is several kilometers from the machine. It is connected
> instead to one of my company's remote telemetery units (RTU) which is
> capable of synchronising it's local clock with that of the GPS clock. Why
right.
> Some of the machines I want to synchronise can contact the RTU via TCP/IP
> over the customer's corporate WAN. These machines could talk ntp to the
> RTUs but ntp is not implimented in the RTUs. Why? Politics. So instead,
right.
The reasonably accurate wheel (ntp) exists. Politics or not, you'd be
much better off using it, and clearly stating so to the relevant powers
that be, rather than (re-)inventing something which approximates a wheel.
Failing that, my first suggestion would be to go out and purchase another
GPS unit to connect to a box where you can run ntp.
> This is an arrangement that actually works. Worked.
> My project team just spent the last two years rewriting the master station
> code, and we haven't yet implimented the setting of the local clock using
> a custom and jittery algorithm. We'd really prefer to have ntp set the
> local clock based on it's poll mechanisms.
Various programs exist for copying a serial port (the GPS) to a TCP/IP
stream, for one (r/w) or many (r/o) remote machines. These are generally
_not_ useful for keeping accurate time, but are useful for position
tracking.
> Now I've come up with a few options, the most obvious being "Write some
> kind of reference clock driver". This is well-supported by ntp and after
> browsing the code it looks like it's completely useless to me. The
> reference clock drivers of ntp want to talk to serial ports. They want to
> gather multiple samples during the poll period and process those samples
> whenever the regular ntp poll arrives. They don't appear use the
> round-trip delay to estimate jitter so with a real network between me and
> the clock it seems to me that they won't do. I could be wrong, and that's
So, don't use round-trip. Have something on the RTU reading the serial
port of the GPS, getting the current time and sending it in an ICMP or UDP
packet (ie, one way) to the measuring box. Calculate one-way network
jitter based on the variable intervals of the data arriving.
Gory details of something which uses this to solely measure network jitter
and other oddities at:
http://www.ripe.net/test-traffic/Documents/RIPE/RIPE158/node2.html
( As an aside, the project recently successfully detected a periodic crc
error in the gigE line to the office. Its a pity that the telco are so
annoyingly clueless in getting it fixed )
> what I really want someone to tell me. I want someone to tell me that I
> can just fill in some code for the poll function, then when I get the data
> back tell ntp what the time I got was using my own custom protocol.
You 'can' do this, but if the local clock on your machine is subject to
wild variations, the data cannot be trusted.
--==--
Bruce.
--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'. See http://www.humbug.org.au/
More information about the General
mailing list