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 \ /\/ beh...@omroep.nl, 035-6773555 \/ -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.