Re: [chrony-dev] Running chronyd without syncing system clock
Op 24/02/2012 om 12:32:51 +0100, schreef Miroslav Lichvar: > On Fri, Feb 24, 2012 at 12:12:10PM +0100, Leo Baltus wrote: > > Op 24/02/2012 om 11:43:01 +0100, schreef Miroslav Lichvar: > > > I think that will create a positive feedback loop and will not work > > > well, if at all. The instance which sets the clock needs to compare > > > its clock against a stable clock, not something which includes its > > > own clock. > > > > Wouldn't the one running on its own clock mark it as 'bad' in > > comparison with the others? > > I don't think so, how would it know it's bad? > > Even if it would ignore it, the loop would be just longer, it would go > through the other servers. > > > > > In the mean time I have prepared a patch to see if i can get this > > > > working. Any thoughts about testing scenarios? > > > > > > I'm interested to see what the patch does. > > I think this can work only if the server knows what changes to the > local clock the client did so it can fix its sourcestats. > Ah, I see. Time to go back to the drawing board... -- 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.
Re: [chrony-dev] Running chronyd without syncing system clock
On Fri, Feb 24, 2012 at 12:12:10PM +0100, Leo Baltus wrote: > Op 24/02/2012 om 11:43:01 +0100, schreef Miroslav Lichvar: > > I think that will create a positive feedback loop and will not work > > well, if at all. The instance which sets the clock needs to compare > > its clock against a stable clock, not something which includes its > > own clock. > > Wouldn't the one running on its own clock mark it as 'bad' in > comparison with the others? I don't think so, how would it know it's bad? Even if it would ignore it, the loop would be just longer, it would go through the other servers. > > > In the mean time I have prepared a patch to see if i can get this > > > working. Any thoughts about testing scenarios? > > > > I'm interested to see what the patch does. I think this can work only if the server knows what changes to the local clock the client did so it can fix its sourcestats. -- Miroslav Lichvar -- 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.
Re: [chrony-dev] Running chronyd without syncing system clock
Op 24/02/2012 om 11:43:01 +0100, schreef Miroslav Lichvar:
> On Fri, Feb 24, 2012 at 11:02:55AM +0100, Leo Baltus wrote:
> > 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.
>
> Ok, there are two chronyd instances running on one real hw machine,
> one polls remote NTP servers, but doesn't set the clock. The other
> instance polls the first chronyd and sets the local clock. Is that
> correct?
>
All ntp-clients share the same configuration:
server ntp-only-server1
server ntp-only-server2
server ntp-only-server3
> I think that will create a positive feedback loop and will not work
> well, if at all. The instance which sets the clock needs to compare
> its clock against a stable clock, not something which includes its
> own clock.
Wouldn't the one running on its own clock mark it as 'bad' in
comparison with the others?
> It could work the other way around, the client polling remote
> servers and the server polling the client, but that's probably not
> what you want.
>
Right.
> > In the mean time I have prepared a patch to see if i can get this
> > working. Any thoughts about testing scenarios?
>
> I'm interested to see what the patch does.
>
---
conf.c | 21 +
conf.h |1 +
reference.c | 14 +-
3 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/conf.c b/conf.c
index bbd890c..7da1123 100644
--- a/conf.c
+++ b/conf.c
@@ -94,6 +94,7 @@ static void parse_cmddeny(const char *);
static void parse_cmdport(const char *);
static void parse_rtconutc(const char *);
static void parse_rtcsync(const char *);
+static void parse_nolclsync(const char *);
static void parse_noclientlog(const char *);
static void parse_clientloglimit(const char *);
static void parse_fallbackdrift(const char *);
@@ -165,6 +166,9 @@ static int rtc_on_utc = 0;
/* Flag set if the RTC should be automatically synchronised by kernel */
static int rtc_sync = 0;
+/* Flag set if the local system clock should be synchronised by chrony */
+static int lcl_sync = 1;
+
/* Limit and threshold for clock stepping */
static int make_step_limit = 0;
static double make_step_threshold = 0.0;
@@ -260,6 +264,7 @@ static const Command commands[] = {
{"cmdport", 7, parse_cmdport},
{"rtconutc", 8, parse_rtconutc},
{"rtcsync", 7, parse_rtcsync},
+ {"nolclsync", 7, parse_nolclsync},
{"noclientlog", 11, parse_noclientlog},
{"clientloglimit", 14, parse_clientloglimit},
{"fallbackdrift", 13, parse_fallbackdrift},
@@ -906,6 +911,14 @@ parse_rtcsync(const char *line)
/* == */
static void
+parse_nolclsync(const char *line)
+{
+ lcl_sync = 0;
+}
+
+/* == */
+
+static void
parse_noclientlog(const char *line)
{
no_client_log = 1;
@@ -1579,6 +1592,14 @@ CNF_GetRTCSync(void)
/* == */
+int
+CNF_GetLCLSync(void)
+{
+ return lcl_sync;
+}
+
+/* == */
+
void
CNF_GetMakeStep(int *limit, double *threshold)
{
diff --git a/conf.h b/conf.h
index 7f0f6b3..1fdc616 100644
--- a/conf.h
+++ b/conf.h
@@ -59,6 +59,7 @@ extern int CNF_GetManualEnabled(void);
extern int CNF_GetCommandPort(void);
extern int CNF_GetRTCOnUTC(void);
extern int CNF_GetRTCSync(void);
+extern int CNF_GetLCLSync(void);
extern void CNF_GetMakeStep(int *limit, double *threshold);
extern void CNF_GetMaxChange(int *delay, int *ignore, double *offset);
extern void CNF_GetLogChange(int *enabled, double *threshold);
diff --git a/reference.c b/reference.c
index 7bf8ec7..7c8f414 100644
--- a/reference.c
+++ b/reference.c
@@ -494,7 +494,7 @@ maybe_make_step()
} else if (make_step_limit > 0) {
make_step_limit--;
}
- LCL_MakeStep(make_step_threshold);
+ if (CNF_GetLCLSync()) LCL_MakeStep(make_step_threshold);
}
/* == */
@@ -705,16 +705,20 @@ REF_SetReference(int stratum,
our_residual_freq = new_freq - our_frequency;
-maybe_log_offset(our_offset);
-LCL_AccumulateFrequencyAndOff
Re: [chrony-dev] Running chronyd without syncing system clock
On Fri, Feb 24, 2012 at 11:02:55AM +0100, Leo Baltus wrote: > 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. Ok, there are two chronyd instances running on one real hw machine, one polls remote NTP servers, but doesn't set the clock. The other instance polls the first chronyd and sets the local clock. Is that correct? I think that will create a positive feedback loop and will not work well, if at all. The instance which sets the clock needs to compare its clock against a stable clock, not something which includes its own clock. It could work the other way around, the client polling remote servers and the server polling the client, but that's probably not what you want. > In the mean time I have prepared a patch to see if i can get this > working. Any thoughts about testing scenarios? I'm interested to see what the patch does. -- Miroslav Lichvar -- 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.
Re: [chrony-dev] Running chronyd without syncing system clock
Op 23/02/2012 om 12:34:50 +, schreef Ed W: > On 23/02/2012 08:24, Leo Baltus wrote: > >Op 22/02/2012 om 23:07:51 +, 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
Re: [chrony-dev] Running chronyd without syncing system clock
On Fri, 24 Feb 2012, Leo Baltus wrote: 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 No idea what that means. same hardware as the ntp-clients but do not sync the system clock. Each That makes no sense. Ntp is a procedure for sycnchronising the local clock to a remote clock by periodically comparing the remote clock to the local clock. It has absolutely no idea of time. It cannot serve time. It is a device for comparing two clocks which do have an idea of time. It is like a weighing machine, and you are talking about a balance weighing machine onto whose pans you place nothing, and then saying it is supposed to tell you want weight is. It cannot. 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 Why? What is this for in your scheme? 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? -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ -- 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.
Re: [chrony-dev] Running chronyd without syncing system clock
On 23/02/2012 08:24, Leo Baltus wrote: Op 22/02/2012 om 23:07:51 +, 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. Problem with b) is that you are faking several inaccurate clocks from an upstream "inaccurate" clock... It doesn't seem obvious that a virtualised clock which is allowed to drift from the real hardware clock can be anything other than more unstable and less accurate than the real hardware clock? So now we have multiple processes trying to sync a clock which is the composite of a clock with two sources of jitter/drift (real hardware clock + virtualisation inaccuracies). Therefore this seems less optimal than having the virtual machines use the real hardware clock (and now only one process can be in charge of conditioning the clock again) c) seems most optimal. One NTP process per real physical clock. That single process then has complete knowledge of the modelled inaccuracies of the hardware clock and the upstream source clocks and can make an integrated decision on what to supply to downstream clients. I think you prefer either a) or b), but from what I can see they both have significant disadvantages in terms of accuracy and seem quite redundant? Please shoot down the logic of the above! (be gentle...) My solution was to pin NTP instances to hardware and if they go down then they go down (do you care?) - if you do care then why not make the failover system be something which pushes IPs to working instances (so some individual instances might appear to be two servers) rather than instances which know their IPs..? In that case I cannot bind them to a specific IP adress which is needed to be transparant for firewalls in and outside my network. If so then that seems to only be a limitation of your current virtualisation system? I don't see any reason why it can't be done easily? At the simplest if your IPs are only used for the NTP process then you can literally just attach one or more IPs to an existing virtual machine and it will answer to all those IPs. I haven't double checked, but
Re: [chrony-dev] Running chronyd without syncing system clock
Op 22/02/2012 om 23:07:51 +, 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. > My solution was to pin NTP instances to hardware and if > they go down then they go down (do you care?) - if you do care then > why not make the failover system be something which pushes IPs to > working instances (so some individual instances might appear to be > two servers) rather than instances which know their IPs..? > In that case I cannot bind them to a specific IP adress which is needed to be transparant for firewalls in and outside my network. > The point is that you don't seem to gain anything by running two > instances of ntp on a single physical machine? (Just the appearance > that instances are doing something?) > > What do you think? > I disagree :) -- 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.
Re: [chrony-dev] Running chronyd without syncing system clock
On Thu, 23 Feb 2012, Ed W wrote: On 23/02/2012 08:24, Leo Baltus wrote: Op 22/02/2012 om 23:07:51 +, 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 An important difference between chrony and ntpd is that chrony uses not only the current time difference between the local clock and the remote clock, but also a history of up to 64 previous measurements (compensated for the change in offset and rate that we have imposed on the local clock.) 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. No idea what this means. sync the local clock to what? There is nothing to sync it to without the measurements of the remote clocks. The system has no idea what the "real true" time is except for the measurements made on the remote clocks. (sync is a comparison, you cannot sync one clock on its own, you sync one clock to another, or sync two clocks to each other). And if you have two ntp processes trying to handle the same hardware clock, how does process A know what changes process B has made, and how do they resolve contentions? A wants to speed up the clock, B to slow it down? Do they have a fight? How do they even know that there is a contention? 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. No idea what this means. What is a "virtual clock". Clocks are things in which some hardware delivers a series of hardware "ticks", whether clock interrupts or processor cycles. What is it that "virtual" clocks are supposed to deliver? Number of times that two is multiplied by 3 in the software on that virutual machine? 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. That is the way things run now, but I have no idea why this is "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. Problem with b) is that you are faking several inaccurate clocks from an upstream "inaccurate" clock... It doesn't seem obvious that a virtualised clock which is allowed to drift from the real hardware clock can be anything other than more unstable and less accurate than the real hardware clock? So now we have multiple processes trying to sync a clock which is the composite of a clock with two sources of jitter/drift (real hardware clock + virtualisation inaccuracies). Therefore this seems less optimal than
Re: [chrony-dev] Running chronyd without syncing system clock
Hi 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? My solution was to pin NTP instances to hardware and if they go down then they go down (do you care?) - if you do care then why not make the failover system be something which pushes IPs to working instances (so some individual instances might appear to be two servers) rather than instances which know their IPs..? The point is that you don't seem to gain anything by running two instances of ntp on a single physical machine? (Just the appearance that instances are doing something?) What do you think? Good luck Ed W -- 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.
Re: [chrony-dev] Running chronyd without syncing system clock
On Tue, Feb 21, 2012 at 05:39:54PM +0100, Leo Baltus wrote: > It would be quite nice if we could separate the network service from the > sync-to-system-clock service. In that case we could a) run a local chronyd > which bind()'s to an unusual port and acts as a ntpclient syncing the > system clock, and b) have a network service which communicates to the outside > and serves ntp to network clients, possibly the one which runs locally. > > Now if we stop the network service and start it elsewhere there is > nothing more to do and the clients will just records this as a short > ntp-outage. > > For this to work we 'only' have to have an option that says something > like no-system-clock-sync everything else seems to be there already. If you want to just serve local time, the "local stratum" feature could be used for that, but there is a problem that it doesn't preserve the root delay and dispersion values, so clients could easily mark this server as falseticker. Another possibility would be something similar to ntpd's "disable ntp" which would disable the clock discipline completely. That should be pretty easy to add, I think all is needed is to remove the LCL_Accumulate* calls in REF_SetReference(). -- Miroslav Lichvar -- 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.
[chrony-dev] Running chronyd without syncing system clock
Hi, We would like to use chrony in our environment to replace ntpd. What we really like in chrony is the ability to bind() to an interface so we can make really tight firewall rules. 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 Apart from the ntp network service we of course also like to keep our system clocks synchronized. If we stop chrony and start it elsewhere there is nothing to keep the system clock any more so we have to start a chrony- instance without visible network service. It would be quite nice if we could separate the network service from the sync-to-system-clock service. In that case we could a) run a local chronyd which bind()'s to an unusual port and acts as a ntpclient syncing the system clock, and b) have a network service which communicates to the outside and serves ntp to network clients, possibly the one which runs locally. Now if we stop the network service and start it elsewhere there is nothing more to do and the clients will just records this as a short ntp-outage. For this to work we 'only' have to have an option that says something like no-system-clock-sync everything else seems to be there already. I may be overlooking something in the documentation, otherwise could somebody comment on this or give some pointers on how to implement it? -- 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.
