[ntp:questions] Implementing NTP in a legacy system

unruh unruh at invalid.ca
Wed Dec 12 19:11:33 UTC 2012

On 2012-12-12, andreas.ames at de.transport.bombardier.com <andreas.ames at de.transport.bombardier.com> wrote:
> Hi unruh,
> unruh <unruh at invalid.ca> schrieb am 12.12.2012 18:37:33:
>> On 2012-12-12, andreas.ames at de.transport.bombardier.com <andreas.
>> ames at de.transport.bombardier.com> wrote:
>> > Dear all,
>> >
>> > I'm rather new to NTP so please forgive me, if my question is trivial.
>> >
>> > I'm maintaining a legacy system with its own proprietary time 
>> Why be coy. Why not tell us what that legacy system is. And why you
>> would want to keep its own proprietary time sync protocol.
> Well I guess I'm shy by nature :-).
> I cannot change the synchronisation protocol in the legacy part
> because that would mean a lot of changed components including
> 3rd-party.  That's simply not practical.
>> > synchronisation protocols.  Now I want to add a new subsystem which 
>> > requires a NTP daemon to be available.  I have added a gateway device 
>> Subsystem as in new hardware or as in a program? If the latter then one
>> thing to remember is that there is (usually) only one system clock on a
>> system, and having two systems try to control that one clock is a
>> recipie for total and complete disaster. If that is what you want to do,
>> you cannot. ntp is not a way for programs to figure out what the time
>> is, it is a way for the system to control the system clock.
> Ok, point taken, thanks.  I'll drop the requirement not to touch the
> system time of the gateway device.
> The new subsystem is a complete Ethernet LAN with numerous devices
> attached which use the NTP daemon on the gateway as their time base.
> The legacy part is a distributed control system with three different
> bus systems (two fieldbusses and one Ethernet LAN) all of which have
> subscribers that want to synchronise their time.
>> If you would be more forthcoming, people could probably give better
>> advice. 
> What I'm looking for is an API/other interface in NTPD to attach to a
> currently non-supported reference clock (most probably by writing the
> needed adapter code).  And this (adapted) NTPD shall run on the
> gateway device to feed the ntp clients in the new subsystem. 

As was suggested, it MIGHT work to run ntpd and have only a localclock
as its only refclock, and no other servers. Then, AFAIK, ntpd would not
run its clock control algorithm, but could serve others.
Of course you would have to be very very careful that noone ever put in
some other server into the ntpd configuration files, because two
programs both trying to discipline your local lock would be a mess, and
could go totally unstable. 
 Otherwise you
could write and  run a driver on your system which accepted ntp packets read your
system clock on the gateway device, and delivered that to the remote
clients by return ntp packet. The packet format is open, so there is no
reason you could not write such a daemon, assuming your operating system
on the gateway allowed you to install daemons (I do not know how closed
it is). Most of the code in ntpd is to discipline the local clock.
Without that requirement, a time server using ntp would be pretty

More information about the questions mailing list