[H-GEN] Should I NTP reference clock driver?

[ben.carlyle at invensys.com]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

G'day,

.. and why the hell not ask humbug? You never know who might have had 
experience with these things.
:)

Unless you've hacked NTP before you're probably not going to be able to 
assist me, but I don't like gathering spam so I'm loathe to post to the 
official newsgroup. Since there's no official ntp mailing list I thought 
I'd post my query here.

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 
conclusion that I could plug the GPS clock into one or more of the 
machines and get ntp to use the clock as a reference driver. The other 
machines could synchronise off the directly connected machines and 
everything would be hunkey dorey.

No. I can't do that.

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 
is the GPS clock several kilometers from the machines I really want to 
synchronise? Politics.

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, 
these "master stations" periodically contact the relevant RTU and ask it 
the time. A custom and very jittery algorithm is the used to adjust the 
local clock of the machine. Only one of the master stations can talk to 
the RTU at one time. A complicated and non-standard ntp arrangment uses 
cron-style scripts to periodically check which master station is in fact 
talking to the RTU and should therefore have the best local clock and 
adjusts all NTP servers around the master stations to ignore their local 
clocks and instead talk to the good master station.

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.

Ok.
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 
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.

The next best thing would probably be to impliment a process that talks 
ntp, but simply passes a poll request all the way down to the RTU then 
passes the response back up. A kind of ntp proxy. An ntp adaption process. 
This of course begs the question "On which host does it run?" and "Which 
port does it listen on?". Since all the hosts I have at my disposal want 
to be synchronised it seems like a bad idea to run my program on the ntp 
port. Ntp would probably not be able to run on that machine. It seems, 
also, that I would not be able to specify a different port for ntp to 
connect to a server on since I can't find that kind of option in the 
configuration.

<shrug>

Unless any of you can give me a clue as to how to overcome the problems 
associated with those options I may have to revert back to the old system 
behaviour, which I suppose was not so bad in it's own way. It just didn't 
keep accurate time, is all :)

Benjamin.


--
* 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/