Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 9 Dec 2009 10:17:20 -0600

Hi Babak,

On Wednesday 09 December 2009 02:54:56 Kalantari Babak wrote:
>
> As you know, the current NTPTime provider of generalTime in EPICS polls
> only to one NTP server which is specified by "EPICS_TS_NTP_INET". For us
> (and probably others) it would be desired to enable the NTPtime provider
> to be aware of multiple NTP servers such that if one fails to respond at
> any point it could sync with a second (or third ...) NTP server.

It is also desirable to have a better NTP client that uses a phase-locked-loop 
to track multiple NTP servers and adjusts the local time-keeping clock slowly.  
Jeff Hill already uses a PLL-approach in the Win32 clock interface, but I'm 
not sure how easy it would be to extract that part and re-use it.

If we're going to spend some effort producing a better client, it might be 
worth seeing whether the ntpclient http://doolittle.icarus.com/ntpclient/ 
software from Larry Doolittle could be easily modified to run on vxWorks.  
Larry is on the edge of the EPICS community and has at a previous ICALEPCS 
mentioned that he might be willing to re-license his code for use in EPICS (it 
currently uses GPLv2 and thus cannot be incorporated into the official Base 
distribution).  It just so happens that Eric Norum has recently started 
working at LBL with Larry and I know he was interested in this subject, so he 
might be useful as a go-between.  Even if Larry doesn't agree to a license 
change we could still use his code as long as we keep the client code separate 
from Base itself.

> 1. Having one generalTime-registered NTPTime provider (like now) but
> making it to accept a list of NTP servers and it syncs to the first
> available one. This can be done by making "EPICS_TS_NTP_INET" a list of
> IP addresses and consequent modifications.

I agree that this would be fairly simple to implement on vxWorks, but the OSI-
OSD API was designed to work with RTEMS as well, and that OS has a rather 
different interface to the OS-provided routine that executes an NTP request.  
The rtems_bsdnet_get_ntp() call that we use there doesn't take the IP address 
of the time server, which I believe gets configured somewhere inside the OS 
network start-up code.  I'm not saying this couldn't be changed (and Eric is 
the right person to discuss that with), but unfortunately it's not quite as 
easy as you think.

Note that the ntpclient code has its own NTP client network interface, so it 
is not subject to the same OS-dependent issue.

> 2. Having multiple generalTime-registered NTPTime providers where each
> of those can be configured with a simple (driver) configuration command
> to set NTP server IP and one or two more parameters to distinguish
> between NTPTime providers. In this case the NTPTime configurations have
> to be called in a common startup.cmd at init time with one of them
> having its NTP server as "EPICS_TS_NTP_INET".

This could be done with no changes to Base.  The current code will handle the 
EPICS_TS_NTP_INET server, and you would create and load new client code which 
provides a command to register a particular NTP server IP at a specific 
General Time priority.  The priority controls the order in which servers fail-
over, and the IP address (or host name) is how you distinguish between 
providers.

One disadvantage of our existing approach is that we create a background 
thread for each registered time provider which is used to synchronize with the 
server.  If you do write the code for #2, it would be nice to try and combine 
the synchronization activities for all NTP servers (other than the default one 
from Base) into a single thread.

One of the advantages of using code like Larry's ntpclient is that it may be 
making much better use of the different servers, comparing their performance 
and/or combining their responses, as well as measuring and correcting the 
tick-rate of the local clock, and it will probably perform much better at 
times when no NTP server is available.

I do really think that the most sensible next step would be to look at 
ntpclient, and I hope we can do that rather than reinventing yet another 
wheel.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System