Re: [chrony-dev] Running chronyd without syncing system clock

[Leo Baltus <Leo.Baltus@xxxxxxxxx>]

Op 23/02/2012 om 12:34:50 +0000, schreef Ed W:
> On 23/02/2012 08:24, Leo Baltus wrote:
> >Op 22/02/2012 om 23:07:51 +0000, schreef Ed W:
> >>>In our setup we do not like to pin a service to a specific piece of
> >>>hardware. If, for some reason, a service should run elsewhere we just
> >>>stop it en start it elsewhere. bind() make is invisible for the outside
> >>>to see and firewalls do not need to know about it either. This is what
> >>>we do for all our services, except ... ntp
> >>I do something similar, but it later occurred to me that it serves
> >>no useful purpose to put two ntp servers on a single clocked
> >>machine?
> >This is exactly why I want to separate the systemclock sync from the
> >networkservice so that each instance serves a specific purpose.
> 
> Hmm, one of us has got the wrong idea I think?  Miroslav - is it me?
> 
> My thought process (please knock it down) is:
> 
> - We can't know what the "correct" time is, all we have is a bunch
> of measurements from a variety of sources that are assumed to have
> various random errors associated
> - Based on some heuristics we pick one of these inaccurate sources
> to sync against, being fully aware that we can't correctly measure
> the source, only measure it give or take some error term (which we
> hope will average through time)
> - Because the source isn't a constant high resolution tick we need
> some local high res clock to use for all normal clock requirements.
> This clock is also inaccurate so we have a combined problem to
> measure the inaccuracy of our local clock vs the source clock.
> - With a local high res clock and an occasional glimpse at an
> upstream clock assumed to be accurate, we can use the two things and
> estimate the "correct current time" based on offsetting the local
> high res clock using a bunch of maths.
> - Note that the local clock doesn't normally match the upstream
> clock, we initially skew it close over some time period and then
> continually monitor it computing some error term based on it's
> observe deviation from the source
> 
> Now you could:
> a) Run one process to sync the local clock, and one or more separate
> ntp processes to sync that clock to other consumers via ntp. All ntp
> processes serve the same single, physical, hardware clock.
> 
> b) Run multiple processes in virtualised spaces, with virtualised
> clocks that drift from the real hardware clock.  Each process
> computes it's own clock error term and serves that via NTP to
> consumers.
> 
> c) Run single process to sync the local clock AND serve NTP to
> consumers. Allow NTP process to answer requests from multiple IP
> addresses, ie masquerade as multiple NTP servers.
> 
> 
> The problem with a) is that the separate NTP processes have no
> knowledge of the sync state with the upstream source clock. All they
> can do is serve the physical hardware clock (which is of course
> being skewed periodically by some separate NTP process).  I don't
> know how well that works in practice, but certainly it seems
> redundant to have multiple NTP processes serving *a single clock*,
> additional processes have no new knowledge and hence no obvious
> advantage over a single NTP process.

I am not saying that multiple processes should serve a single clock.

Let me try some good old ascii art:

        uplink                   local nets
   pool  ---   ntp-only-server1     ---     ntp-client
               ntp-only-server2     ---     ntp-client
               ntp-only-server3     ---     ntp-client
                                    ---     ntp-client
   
The pool is a set of ntp-servers outside my network. Inside my network I
have 4 servers (hardware) each running an ntp-client synchronizing to 3
ntp-only-servers (chronyd instances). The ntp-only servers run on the
same hardware as the ntp-clients but do not sync the system clock. Each
ntp-only server has its own ip address unrelated to the server's ip
address. Some hardware is running ntp-clients only. The ntp-clients do
sync the system clock. Some ntp clients may even be outside my networks.

The ntp-only servers can now bind to its own IP address for *both*
serving ntp as well as sending udp packets to the pool. This way there
is now way for the pool or the ntp-clients to see on what hardware the
ntp-only server is running. We call this IP-virtualization, no need for
virtual machines. This is ideal if there are firewall administrators
who have a policy of only allowing traffic based on single IP numbers
rather than ranges. Also this works with IPv6 as well. Any solution that
requires NAT is a no go as far as we are concerned.

So for the ntp-only servers to function properly they have to have an
accurate system clock which they cannot set. This may be a catch22 on
startup, however I assume that not all local clocks will be off so an
ntp client can still pick an other ntp-only source.

I am approaching this from an networking/firewalling/administration
point of view and hope not to introduce all sorts of timing issues which
I am sure you have thought about much harder than I did.

In the mean time I have prepared a patch to see if i can get this
working. Any thoughts about testing scenarios?

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer@xxxxxxxxx, 035-6773555                         \/

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