RE: [chrony-users] Isolated time domains

[Chris Dore <Chris.Dore@xxxxxxxxx>]

On Thu, Dec 5 2013, Bill Unruh wrote:
> 
> On Thu, 5 Dec 2013, Chris Dore wrote:
> 
> > On Thu, Dec 5 2013, Bill Unruh wrote:
> >
> >> Eg, he says that he wants to keep all of the computers to within 1
> >> sec. But what happens if one of the clients suddenlyfinds itself 3
> >> hours out? Are all of the other clients then supposed to go out as
> >> well to keep themselves in sync with that client? How would they do
> >> that? And if not, why is the server special that all should run after its
> crazyness?
> >
> > The clients should, and do already, follow the server no matter how "crazy"
> it may seem to the outside world.  The server in a single site location is the
> source of truth for what UTC is.  All clients on that site must obey or not
> participate in operations.  In fact, these clients will already make whatever
> jumps in time are needed to bring themselves in line with the server (usually
> as part of connection startup).  If one client of the server decided that it
> knew better than the server and adjusted to some other reference of UTC
> than it just functionally won't work.  That's why the server is special.
> 
> "Just functionaly won't work" means what? If |client time-server time| > x
> seconds -> shut down client?

Basically data starts getting thrown away by the server, since it gets considered too old.  On connection bring up, clients currently step time to match that of the server.  From there ntp is used to keep them in sync.  To be clear, in the field the current ntpd instance on the server has no external references, the only source it has is its local clock.

> Since ntpd refuses to move faster than 500PPM, you must use chrony on all
> your clients or there is no way they can keep up. If you use chrony on your
> server, and ntpd on your clients you will have to persuade chrony to keep its
> rate well below 500PPM which will mean it will take about a year to get rid of
> a 3 hr offset in the master.

Yes, and that would be acceptable. Any site that is too far out to be corrected in a reasonable time will need to have some manual intervention to coordinate a jump in time.

> Also if you use ntpd on your clients, it will jump the time if it finds itself
>   sure that it has  an offset of greater than 0.128 sec. Chrony can also be set
> up to jump the time if you want.

When I was initially doing some tests with ntpd, I had to disabled that feature for the ntpd instance on my server, since jumping time (on the server) is unacceptable in my use case (unless human intervention and co-ordinated activities take place).  Clients can step time all they want to match the time of the SERVER, which may or may not be UTC.

> > As an experiment, I've got two instances of chronyd running on a server..
> One instance is sourcing the external ntp servers and taking care of the
> server's local clock.  The second instance, is just serving up the local clock to
> the clients (on a different UDP port).  This is producing what I've been
> describing, although I'm not a big fan of having two instances running since I
> don't understand the chronyd/NTP internals well enough to know of any
> gotchas that may be hiding.  Also, requiring the use of a non-standard port is
> less than ideal, in case an ntp client doesn't support it.
> 
> Both ntpd and chrony support non-standard ports.
> Are you planning on using anything other than ntpd or chrony?

There are devices running implementations of ntp for which I do not know the lineage.  I haven't yet looked into what ports are supported on all devices, but I'm going to look into Miroslav's suggestion and hopefully this isn't an issue.


Chris

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.