Experimental Physics and
Industrial Control System

"Kalantari Babak" <[email protected]> · Thu, 10 Dec 2009 09:20:06 +0100

Thanks for your comprehensive reply.

I will be taking look at ntpclient code for sometime and come back to
you later.

Babak   

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Mittwoch, 9. Dezember 2009 17:17
> To: Kalantari Babak
> Cc: [email protected]; Korhonen Timo; Eric Norum
> Subject: Re: multiple NTP servers and NTPTime
> 
> 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