Re: [ntp:questions] chrony as a server
On 2015-02-25, Paul wrote: > On Tue, Feb 24, 2015 at 4:17 PM, William Unruh wrote: > >> It is superior in that you can do it easily. Whether that is of any >> importance to you is of course up to you. Myself I have never used it. >> > > As is often the case you completely miss the point. As is often the case, you have no point to make. > > >> Fine. It has already been written for chrony. For those that want it, >> this is an advantage for chrony. I could argue that ntpd is >> no better than nothing because I could write a program to do what ntpd >> does. While (possibly) true, it is a silly argument. >> > > If there's an real use case for the feature then writing a few lines of > some scripting language to implement an equivalent solution for NTPd is not > a significant effort. > Again, you cannot read. The claim was this feature was the same as orphan or local mode. You seem to now agree that it is not. That was my point. > If such an add-on was available for NTPd would you stop or would you > continue asserting that Chrony has some unproven advantage. And until > someone shows the level of correction you can expect then it remains > unproven speculation. > As I have said, I do not use it. It is a difference from ntpd. If ntpd had it then I would agree it is not a difference or an advantage for chrony. But until it is written it is. So go ahead and write it, When you do and get it incorporated into ntpd, I will advocate removal of that sentence from the description of the advantages of chrony in the docs. I do not expect to have to do so anytime soon. > >> >> (assuming the presense does not mess other things up). >> > > Yeah there's always that. > > >> Your wristwatch may well be a much better ticker than the localclock >> > > Well mine isn't but that wasn't the point. Come back when you have real > measurements of an end-to-end system. I don't care about the time source. > You assert that there's an advantage to disciplining a clock by hand versus > free-running. So come back in a year and tell me how it went. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-25, Paul wrote: > On Tue, Feb 24, 2015 at 3:22 PM, Charles Swiger wrote: > >> >> Data is available. Feel free to review the papers referenced from: >> > > I was unclear. I mean specific research regarding disciplining a clock via > manual correction not human coordination or fine motor control. > > As I said, an unbiased assessment of long term corrections using manual > correction. Not "well theory says" speculation either on the part of > chrony and/or human performance. I am still unclear as to what you would want. To use an analogy, it sounds like you saying you want original research on disciplining the clock using say tick.microsoft.com, not theory as to how ntpd works, or tick.microsoft.com works. and evidence as to how ntpd works with any other server is irrelevant, you want research on that particular server. What are you looking for, or is this just an excercise in futility. A human clock source is just like any other source, with an offset accuracy somewhere between .2 and 1 seconds. Both chrony and ntpd have been tested ad nausium with clock sources of many different kinds. We understant them, both theoretically and experimentally. What is there about this particular clock source that you would want to investigate. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Tue, Feb 24, 2015 at 4:17 PM, William Unruh wrote: > It is superior in that you can do it easily. Whether that is of any > importance to you is of course up to you. Myself I have never used it. > As is often the case you completely miss the point. > Fine. It has already been written for chrony. For those that want it, > this is an advantage for chrony. I could argue that ntpd is > no better than nothing because I could write a program to do what ntpd > does. While (possibly) true, it is a silly argument. > If there's an real use case for the feature then writing a few lines of some scripting language to implement an equivalent solution for NTPd is not a significant effort. If such an add-on was available for NTPd would you stop or would you continue asserting that Chrony has some unproven advantage. And until someone shows the level of correction you can expect then it remains unproven speculation. > > (assuming the presense does not mess other things up). > Yeah there's always that. > Your wristwatch may well be a much better ticker than the localclock > Well mine isn't but that wasn't the point. Come back when you have real measurements of an end-to-end system. I don't care about the time source. You assert that there's an advantage to disciplining a clock by hand versus free-running. So come back in a year and tell me how it went. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Tue, Feb 24, 2015 at 3:22 PM, Charles Swiger wrote: > > Data is available. Feel free to review the papers referenced from: > I was unclear. I mean specific research regarding disciplining a clock via manual correction not human coordination or fine motor control. As I said, an unbiased assessment of long term corrections using manual correction. Not "well theory says" speculation either on the part of chrony and/or human performance. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-24, Paul wrote:
> On Tue, Feb 24, 2015 at 1:14 PM, Charles Swiger wrote:
>
>> On Feb 23, 2015, at 11:57 PM, David Woolley
>> wrote:
>> > On 23/02/15 21:23, William Unruh wrote:
>> >> manual corrections are probably good to 1 sec.
>> >
>> > It's a long time since I did this, but 200ms is more like it
>>
>> However, if you time things with a rhythm you can get to ~50 ms or better
>>
>
> While these performance anecdotes are interesting they (starting with
> unruh@invalid) are all anecdotes. I didn't mention research and real
> numbers by accident.
>
> The underlying assertion is that the chrony method offers some value and is
> superior to NTPd. So I'd like something more than hand-waving regarding
It is superior in that you can do it easily. Whether that is of any
importance to you is of course up to you. Myself I have never used it.
> the performance and if it's better than just setting the clock once and a
> while I'll write something to create a drift file based on the operator
> listening to USNO ticks (or Emerald Time if you have it) and pressing
> return at the right time.
Fine. It has already been written for chrony. For those that want it,
this is an advantage for chrony. I could argue that ntpd is
no better than nothing because I could write a program to do what ntpd
does. While (possibly) true, it is a silly argument.
>
> Someone else can do a version that uses a microphone to listen to the ticks
> -- a stone-age ACTS driver.
>
> With regard to return on investment and underlying arguments about
> "advantages". I don't buy the "Well someone may want to do this so it's
> worthwhile" argument. Doing something foolish or stupid doesn't make
> Chrony better than NTPd.
It is not either foolish or stupid. It was written because Curnoe had a
bunch of computers that spent a lot of time disconnected from the net.
He had a need. Others may or may not. But if you do, then chrony's
having it is an advantage. If you have no need it is not an advantage to
you, but there are lots of things in most programs that I never have a
need for, but their being there is still an advantage of those programs
(assuming the presense does not mess other things up).
>
> Or to put it another way -- NTPd is about precise time transfer and it
> protects you from falsetickers like your wristwatch.
Your wristwatch may well be a much better ticker than the localclock is
(seconds per year rather than hours per year.)
And listening to the time signal on the radio ("At the beginning of the
long dash it is exactly 12:00" for those that live, or lived in
Canada) is much better than seconds per year.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Feb 24, 2015, at 11:40 AM, Paul wrote: >> However, if you time things with a rhythm you can get to ~50 ms or better > > While these performance anecdotes are interesting they (starting with > unruh@invalid) are all anecdotes. I didn't mention research and real > numbers by accident. Data is available. Feel free to review the papers referenced from: http://en.wikipedia.org/wiki/Keystroke-level_model http://en.wikipedia.org/wiki/GOMS Regards, -- -Chuck PS: I took a Human-Computer Interaction class with Bonnie John many years ago; we used to film people performing tasks on computers and such with a 4x camera (96 FPS) with a millisecond digital timestamp in each frame and compared that with KLM and GOMS / CPM-GOMS / NGOMSL models. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Tue, Feb 24, 2015 at 1:14 PM, Charles Swiger wrote: > On Feb 23, 2015, at 11:57 PM, David Woolley > wrote: > > On 23/02/15 21:23, William Unruh wrote: > >> manual corrections are probably good to 1 sec. > > > > It's a long time since I did this, but 200ms is more like it > > However, if you time things with a rhythm you can get to ~50 ms or better > While these performance anecdotes are interesting they (starting with unruh@invalid) are all anecdotes. I didn't mention research and real numbers by accident. The underlying assertion is that the chrony method offers some value and is superior to NTPd. So I'd like something more than hand-waving regarding the performance and if it's better than just setting the clock once and a while I'll write something to create a drift file based on the operator listening to USNO ticks (or Emerald Time if you have it) and pressing return at the right time. Someone else can do a version that uses a microphone to listen to the ticks -- a stone-age ACTS driver. With regard to return on investment and underlying arguments about "advantages". I don't buy the "Well someone may want to do this so it's worthwhile" argument. Doing something foolish or stupid doesn't make Chrony better than NTPd. Or to put it another way -- NTPd is about precise time transfer and it protects you from falsetickers like your wristwatch. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Charles Swiger wrote: On Feb 23, 2015, at 11:57 PM, David Woolley wrote: On 23/02/15 21:23, William Unruh wrote: manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is about 5 days per measurement or 10 days altogether. It's a long time since I did this, but 200ms is more like it (might have been 100ms). You need digital clock that is, itself, synchronised, and you match the rhythm of the ticks, then let one of them actually move the return key. You have to really believe in setting accurate time not just be following some instructions, to do this. Threshold of perception for a new stimulus is around 80 - 100 ms. Untrained reaction time thus tends to be somewhat longer, right around the timeframes you've mentioned. However, if you time things with a rhythm you can get to ~50 ms or better, and subconscious muscle memory for practiced skills can involve timing on the order of ~5 - 10 ms. (Think of a ping-pong player who understands spin and can target the corners of the table reliably, or a pinball player who can trap the ball on the flipper and then make reliable controlled shots.) The best example is accomplished drummers, they work in the low ms range, but even Ringo would vary his teaming to emphasize various parts of a song: http://musicmachinery.com/2009/03/02/in-search-of-the-click-track/ Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Feb 23, 2015, at 11:57 PM, David Woolley wrote: > On 23/02/15 21:23, William Unruh wrote: >> manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is >> about 5 days per measurement or 10 days altogether. > > It's a long time since I did this, but 200ms is more like it (might have been > 100ms). You need digital clock that is, itself, synchronised, and you match > the rhythm of the ticks, then let one of them actually move the return key. > > You have to really believe in setting accurate time not just be following some > instructions, to do this. Threshold of perception for a new stimulus is around 80 - 100 ms. Untrained reaction time thus tends to be somewhat longer, right around the timeframes you've mentioned. However, if you time things with a rhythm you can get to ~50 ms or better, and subconscious muscle memory for practiced skills can involve timing on the order of ~5 - 10 ms. (Think of a ping-pong player who understands spin and can target the corners of the table reliably, or a pinball player who can trap the ball on the flipper and then make reliable controlled shots.) Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 23/02/15 21:23, William Unruh wrote: manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is about 5 days per measurement or 10 days altogether. It's a long time since I did this, but 200ms is more like it (might have been 100ms). You need digital clock that is, itself, synchronised, and you match the rhythm of the ticks, then let one of them actually move the return key. You have to really believe in setting accurate time not just be following some instructions, to do this. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-23, Harlan Stenn wrote: > William Unruh writes: >> On 2015-02-23, Harlan Stenn wrote: >> > Miroslav Lichvar writes: >> >> On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote: >> >> > On 21/02/2015 17:52, William Unruh wrote: >> >> > [] >> >> > >It will do that too. The crucial item there is "the only method of time >> >> > >correction is manual entry" which is different from ntpd and orphan >> >> > >mode. I have no idea why this conversation is continuing. The two are >> >> > >different. The two methods are trying to solve the same problem >> >> > >(timekeeping of isolated systems) but doing so in a different manner. I >> f >> >> > >you like one better than the other, that is fine. But they are not the >> >> > >same. >> >> > >> >> > Bill, please enlighten me why I cannot, using NTP's orphan mode, set the >> >> > time on one PC manually and have another PC sync to it? >> >> >> >> Well, you can, but it's not as easy. You need to find the orphan >> >> parent first (i.e. the system with the smallest refid), somehow >> >> figure out its phase and frequency error to the real time, and correct >> >> them behind ntpd's back (possibly with the date and ntptime -f >> >> commands). >> >> >> >> With chrony you just run "chronyc -a settime xx:xx:xx" once in a while >> >> on the server and it will do the rest for you. >> > >> > I'm not buying it. >> > >> > It's trivially easy to set up a proper orphan mesh. >> > >> > A proper network configuration will have multiple time servers on it, >> > because sometimes things break. If you want to set up something where a >> > flock of machines follow a single server, that's your choice and there >> > are consequences to that choice when things break. >> > >> > If you implement the recommended setup then the old local refclock >> > scheme will usually pretty much just work, and an an orphan scheme will >> > just work. >> >> Of course it will "work" but the clocks will go wandering off, with no >> way of hauling them back into time. > > Bullshit. As soon as a proper time source is found the servers will use > it. ??? That is true in both cases. The assumption was that you have a clock which has no connectivity for months. Ie, no proper time source will be found. The question is about disciplining the clock in that case. If time sources are available, then yes, please use them. > >> Lets start with a single machine >> with a drift rate of 30PPM. By the end of the month it will be a minute >> out. So if that is working, then it works. As Lichvar says with chrony >> you periodically read your watch, or listen to radio, and set the time >> and chrony figures out that you have a drift rate of about 30PPM and >> corrects. Now you may not value that possibility, which is perfectly all >> right, but some people might. > > So you are assuming that an orphan mesh kicks in at a time when there is > an uncorrected drift of 30ppm, and this is at a site where time synch is > important and they're OK with no proper time source for a month? Sure. The computer starts up with no time sources availble. The drift could well be 30PPm. > > What would happen if chrony happened to lose its time source while there > was an uncorrected drift of 30ppm? Anything different? Yes, you would feed it time manually, and it would use that as its time source. That is what we are discussing. > > With ntpd and chrony it's possible to adjust the frequency in this case. It is possible sure. It is just that chrony does it differently. The question that was raised was whether or not chrony's handling of a time island is identical with ntpd's. It is not. Now you may not care, or may not believe anone could be interested in the difference. But they are different. > > It's posts like these from you that cause me to wonder if you are just a > troll. It's why I tend to not respond to you, but sometimes I do > respond to at least some of your more egregious posts. ??? Clearly you have not been following the discussion. The claim was that chrony's ability to use manual time input as a time source was identical with ntpd's orphan or local clock modes. All I have said is that it is not. No idea why you call that trolling. > > H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-23, Paul wrote: > On Mon, Feb 23, 2015 at 12:53 PM, William Unruh wrote: > >> As Lichvar says with chrony >> you periodically read your watch, or listen to radio, and set the time >> and chrony figures out that you have a drift rate of about 30PPM and >> corrects. Now you may not value that possibility, which is perfectly all >> right, but some people might. >> > > Seems like someone should do some unbiased research and determine just how > long it takes to find clock drift, say to 2 ppm, using chrony with manual > corrections. Finding a nice (efficient) method would be useful too. manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is about 5 days per measurement or 10 days altogether. > > With NTPd I might set the clock, wait a month check the time and create a > drift file. Yes, But as Lichvar said, having the program do the work for you is easier. You could also measure offsets by hand and use adjtimex to adjust the clock yourself and not use either chrony or ntpd. > > Sometimes you have to examine a use case and conclude that it's poor return > on investment. I think trying to discpline an uncharaterized oscillator > with a wristwatch is certainly marginal. Up to you. The option is there for chrony. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 23, 2015 at 12:53 PM, William Unruh wrote: > As Lichvar says with chrony > you periodically read your watch, or listen to radio, and set the time > and chrony figures out that you have a drift rate of about 30PPM and > corrects. Now you may not value that possibility, which is perfectly all > right, but some people might. > Seems like someone should do some unbiased research and determine just how long it takes to find clock drift, say to 2 ppm, using chrony with manual corrections. Finding a nice (efficient) method would be useful too. With NTPd I might set the clock, wait a month check the time and create a drift file. Sometimes you have to examine a use case and conclude that it's poor return on investment. I think trying to discpline an uncharaterized oscillator with a wristwatch is certainly marginal. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-23, Harlan Stenn wrote: > Miroslav Lichvar writes: >> On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote: >> > On 21/02/2015 17:52, William Unruh wrote: >> > [] >> > >It will do that too. The crucial item there is "the only method of time >> > >correction is manual entry" which is different from ntpd and orphan >> > >mode. I have no idea why this conversation is continuing. The two are >> > >different. The two methods are trying to solve the same problem >> > >(timekeeping of isolated systems) but doing so in a different manner. If >> > >you like one better than the other, that is fine. But they are not the >> > >same. >> > >> > Bill, please enlighten me why I cannot, using NTP's orphan mode, set the >> > time on one PC manually and have another PC sync to it? >> >> Well, you can, but it's not as easy. You need to find the orphan >> parent first (i.e. the system with the smallest refid), somehow >> figure out its phase and frequency error to the real time, and correct >> them behind ntpd's back (possibly with the date and ntptime -f >> commands). >> >> With chrony you just run "chronyc -a settime xx:xx:xx" once in a while >> on the server and it will do the rest for you. > > I'm not buying it. > > It's trivially easy to set up a proper orphan mesh. > > A proper network configuration will have multiple time servers on it, > because sometimes things break. If you want to set up something where a > flock of machines follow a single server, that's your choice and there > are consequences to that choice when things break. > > If you implement the recommended setup then the old local refclock > scheme will usually pretty much just work, and an an orphan scheme will > just work. Of course it will "work" but the clocks will go wandering off, with no way of hauling them back into time. Lets start with a single machine with a drift rate of 30PPM. By the end of the month it will be a minute out. So if that is working, then it works. As Lichvar says with chrony you periodically read your watch, or listen to radio, and set the time and chrony figures out that you have a drift rate of about 30PPM and corrects. Now you may not value that possibility, which is perfectly all right, but some people might. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar writes: > On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote: > > On 21/02/2015 17:52, William Unruh wrote: > > [] > > >It will do that too. The crucial item there is "the only method of time > > >correction is manual entry" which is different from ntpd and orphan > > >mode. I have no idea why this conversation is continuing. The two are > > >different. The two methods are trying to solve the same problem > > >(timekeeping of isolated systems) but doing so in a different manner. If > > >you like one better than the other, that is fine. But they are not the > > >same. > > > > Bill, please enlighten me why I cannot, using NTP's orphan mode, set the > > time on one PC manually and have another PC sync to it? > > Well, you can, but it's not as easy. You need to find the orphan > parent first (i.e. the system with the smallest refid), somehow > figure out its phase and frequency error to the real time, and correct > them behind ntpd's back (possibly with the date and ntptime -f > commands). > > With chrony you just run "chronyc -a settime xx:xx:xx" once in a while > on the server and it will do the rest for you. I'm not buying it. It's trivially easy to set up a proper orphan mesh. A proper network configuration will have multiple time servers on it, because sometimes things break. If you want to set up something where a flock of machines follow a single server, that's your choice and there are consequences to that choice when things break. If you implement the recommended setup then the old local refclock scheme will usually pretty much just work, and an an orphan scheme will just work. -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote: > On 21/02/2015 17:52, William Unruh wrote: > [] > >It will do that too. The crucial item there is "the only method of time > >correction is manual entry" which is different from ntpd and orphan > >mode. I have no idea why this conversation is continuing. The two are > >different. The two methods are trying to solve the same problem > >(timekeeping of isolated systems) but doing so in a different manner. If > >you like one better than the other, that is fine. But they are not the > >same. > > Bill, please enlighten me why I cannot, using NTP's orphan mode, set the > time on one PC manually and have another PC sync to it? Well, you can, but it's not as easy. You need to find the orphan parent first (i.e. the system with the smallest refid), somehow figure out its phase and frequency error to the real time, and correct them behind ntpd's back (possibly with the date and ntptime -f commands). With chrony you just run "chronyc -a settime xx:xx:xx" once in a while on the server and it will do the rest for you. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-21, Paul wrote: > On Sat, Feb 21, 2015 at 1:57 AM, William Unruh wrote: >> >> On 2015-02-21, Paul wrote: >> > On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote: >> > >> >> ??? how do assume that the chrony docs do not tell the truth? >> ^ you >> > > Okay, I'll assume (or pretend) that you mean "Why do I assume the Chrony > documentation is in error" and the answer is believing you. This is why I > suggest you stop paraphrasing and stop asking for paraphrasing. Provide > references to sources and stop doing original research. I was asking with respect to a specific claim that was made ( and you have erased) and wondering what you meant by it. > > You said: "Lichvar did some tests with PPS and found that chrony > disciplined the clock much better than did ntpd (factors of over 10)" and > since NTPd can get to sub-microsecond your statement means Chrony is > getting at least O(10) nanoseconds. ??? No it does not mean that. I was reporting the results of his experiments. His experiments were NOT "What is the best that can be achieved" but "here are the results on the same hardware". > > The Chrony document says: "With a good reference clock the accuracy can > reach one microsecond." That is not wrong. It may be conservative, but is not wrong. (if you get one picosecond accuracy that is also 1 second accuracy). > > So one of you is wrong. Except it turns out you're both wrong. Miroslav > Lichvar says "If the clock is stable enough, they can perform similarly." > so the Chrony doc understates the performance and you overstate it > considering the current/recent state of the art. Again, I report experiments I ran. I got about a factor of 2-3 better. Same computer, same setup (local network server), same situation (computer in use with varying loads). > > And now some original research: I switched my most challenging *client* > (stratum 2 on a powerline network) from NTPd to Ntimed-client to Chrony. > NTPd had excursions in O(10) to O(100) microseconds, Ntimed-client managed > O(1) to O(10) microseconds and Chrony managed a reasonably consistent 1 > millisecond offset. I used stock conf files except Ntimed-client doesn't > use one. So points to Chrony for being more consistent. Well, then there is some difference. No idea what you did. Note that I have plots, for about 5 years now, of my machines offsets. I have neglected them for about the past 3 years. I used to have one machine running ntpd and the rest chrony. If you are only getting 1ms, something is wrong, either in your configuration or something. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Sat, Feb 21, 2015 at 1:57 AM, William Unruh wrote: > > On 2015-02-21, Paul wrote: > > On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote: > > > >> ??? how do assume that the chrony docs do not tell the truth? > ^ you > Okay, I'll assume (or pretend) that you mean "Why do I assume the Chrony documentation is in error" and the answer is believing you. This is why I suggest you stop paraphrasing and stop asking for paraphrasing. Provide references to sources and stop doing original research. You said: "Lichvar did some tests with PPS and found that chrony disciplined the clock much better than did ntpd (factors of over 10)" and since NTPd can get to sub-microsecond your statement means Chrony is getting at least O(10) nanoseconds. The Chrony document says: "With a good reference clock the accuracy can reach one microsecond." So one of you is wrong. Except it turns out you're both wrong. Miroslav Lichvar says "If the clock is stable enough, they can perform similarly." so the Chrony doc understates the performance and you overstate it considering the current/recent state of the art. And now some original research: I switched my most challenging *client* (stratum 2 on a powerline network) from NTPd to Ntimed-client to Chrony. NTPd had excursions in O(10) to O(100) microseconds, Ntimed-client managed O(1) to O(10) microseconds and Chrony managed a reasonably consistent 1 millisecond offset. I used stock conf files except Ntimed-client doesn't use one. So points to Chrony for being more consistent. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 21/02/2015 17:52, William Unruh wrote: [] It will do that too. The crucial item there is "the only method of time correction is manual entry" which is different from ntpd and orphan mode. I have no idea why this conversation is continuing. The two are different. The two methods are trying to solve the same problem (timekeeping of isolated systems) but doing so in a different manner. If you like one better than the other, that is fine. But they are not the same. Bill, please enlighten me why I cannot, using NTP's orphan mode, set the time on one PC manually and have another PC sync to it? If you are saying that Chrony cannot work on isolated networks /without/ using manual time entry, I would consider that a significant disadvantage. I'm sure that isn't the case. I thought I might learn something about orphan mode from the discussion, as it's not something I have used or had the need for here. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh wrote: > What are you using? Are you on ntpd or chrony? Please do not followup to my postings when you don't care to follow the thread! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-21, Rob wrote: > William Unruh wrote: >> On 2015-02-19, Rob wrote: >>> Miroslav Lichvar wrote: On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote: > I am still finding out what sensor is best to use, we do have a room > temperature sensor that has .1C resolution and is readable via snmp, > and there are the usual sensors for board- and inlet air temperature. > (and of course CPU temperature) > > It does not matter if it is only a course indication, the room temperature > varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not > bad relative to that. In my tests using a sensor with 1C resolution it was barely useful with NTP sources and 1024s polling interval. If the sensitivity is around 0.1 ppm per degree, 1C resolution means the compensation jumping the frequency in 0.1ppm steps. That's a lot, especially if you compare it to the tracking skew with a refclock. >>> >>> Ok but of course we are using PPS and a 16 second polling interval. >>> (or maybe the PPS refclock polls even faster although it displays 4 as >>> the poll interval indicator) >> >> The shm refclock will get one pulse per second, and then average the >> offsets over a 16 sec period after getting rid of the outliers. > > I am not using the SHM refclock in those systems. What are you using? Are you on ntpd or chrony? As I recall ntpd in its pps refclock also collect say 16 outputs of PPS, finds the median, thros away the 40% greatest outliers and reports the resultant median to ntpd as the current offset. That is the same kind of filter chrony uses in its shm driver. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-21, Rob wrote: > William Unruh wrote: >> On 2015-02-19, Rob wrote: >>> Miroslav Lichvar wrote: On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote: > We have systems in places that are not temperature controlled and then > chrony is much better. I am looking for the best way to find the > values to use in the tempcomp configuration directive. What resolution does the sensor have? Don't expect good results with 1C or 0.5C resolution that sensors on mainboards typically have. >>> >>> I am still finding out what sensor is best to use, we do have a room >>> temperature sensor that has .1C resolution and is readable via snmp, >>> and there are the usual sensors for board- and inlet air temperature. >>> (and of course CPU temperature) >>> >>> It does not matter if it is only a course indication, the room temperature >>> varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not >>> bad relative to that. >> >> It is of course the temperature of the crystal itself that is important. >> Ie, the room temp could be constant and the computer varies in its >> workload and thus its internal temperature. Unfortunately temp sensors >> on the crystal are rare in commodity computers. > > I am not looking for a precise crystal temperature but for a ballpark > value that will compensate for the quick temperature swings that occur > when this system (which is in an unheated glasshouse) quickly warms up > when the sun rises, and cools down when the sun sets. It is the crystal temperature that determines the rate change. That crystal temp will be affected by the room temperature (with a lag since it it takes a while for the heat in the air to diffuse into the crystal--I have no idea how long that is, but is probably minutes rather than hours) how hard the machine is working (again the cpu heats up which eventually heats up the crystal) etc. One could probably use any of the temperature measurements that most motherboards have as proxies for the crystal temperature and get improved performance. Remember that the cpu temperature can vary by 20C which is probably more than the room does, and the motherboard forms a heat pipe from the cpu to the crystal. If you really want to study this, get a gps with a PPS and track the offset from the gps and one of those temperature measurements. You could switch off all clock discipline so that it cannot affect your measurements of rate as a function of temperature. Plot offset vs temperature. Look at the averaged slope of the curve to get a measure of how that temperature correlates with the rate. You could fit a curve (probably a quadratic in temperature would be fine.) Or run chrony or ntpd and plot the drift as a function of temperature with a low poll interval. chrony would probably be better in that it responds more quickly to changes in drift. (chrony has some tools for helping with this). Once you have measured this, you could use it in either the forks of ntpd which have temperature compensation, or with chrony. > > In ntpd these events result in offset swings that are the derivative > of the temperature. In chrony the swings are smaller, but it may be > deceptive because I have not yet found a completely satisfactory way > of gathering an "average offset" that is similar to the offset value > in ntpq -c rv. chrony's offset IS an average offset. It is fit to the past N measurements, where N varies depending on how good the linear fit is. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Brian Inglis wrote:
> On 2015-02-21 01:00, Rob wrote:
>> William Unruh wrote:
>>> On 2015-02-19, Rob wrote:
Miroslav Lichvar wrote:
> On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
>> We have systems in places that are not temperature controlled and then
>> chrony is much better. I am looking for the best way to find the
>> values to use in the tempcomp configuration directive.
>
> What resolution does the sensor have? Don't expect good results
> with 1C or 0.5C resolution that sensors on mainboards typically have.
I am still finding out what sensor is best to use, we do have a room
temperature sensor that has .1C resolution and is readable via snmp,
and there are the usual sensors for board- and inlet air temperature.
(and of course CPU temperature)
It does not matter if it is only a course indication, the room temperature
varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not
bad relative to that.
>>>
>>> It is of course the temperature of the crystal itself that is important.
>>> Ie, the room temp could be constant and the computer varies in its
>>> workload and thus its internal temperature. Unfortunately temp sensors
>>> on the crystal are rare in commodity computers.
>>
>> I am not looking for a precise crystal temperature but for a ballpark
>> value that will compensate for the quick temperature swings that occur
>> when this system (which is in an unheated glasshouse) quickly warms up
>> when the sun rises, and cools down when the sun sets.
>>
>> In ntpd these events result in offset swings that are the derivative
>> of the temperature. In chrony the swings are smaller, but it may be
>> deceptive because I have not yet found a completely satisfactory way
>> of gathering an "average offset" that is similar to the offset value
>> in ntpq -c rv.
>
> Hi Rob,
> If the systems can run x86/x64 Linux with Mono and WinForms or Windows
> with .NET 2+ then OpenHardwareMonitor may be able to log the system
> sensors.
> For Linux see if lm_sensors/sensord/sensors/sensors-detect are available
> on or for your system and look for data in:
> /proc/acpi/thermal_zone/
> /sys/bus/platform/devices/*temp*/
> /sys/class/hwmon/hwmon[0-9]*/
> /sys/class/thermal/{thermal_zone,cooling_device}[0-9]*/
> Once you have the data, you may want to try weighted or windowed incremental
> RMS values of temperature and frequency drift to see if they can be
> correlated.
I know how to access the sensors but I have not yet decided which sensor
is best to use, and how to calibrate the chrony configuration to it.
But even without the sensor input the offset is already much smaller than
with ntpd.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-21, David Taylor wrote: > On 21/02/2015 07:04, William Unruh wrote: > [] >> orphan mode is about a group of computers. "Orphan Mode allows a group >> of ntpd processes to automonously select a leader in the event that all >> real time sources become unreachable (i.e. are inaccessible)." >> >> chrony's is that you can enter the time by hand (Ie, by typing a current >> time and hitting enter) on a single machine. You are the "remote clock". >> Now, how useful that >> is now adays is open to question, but in the past with telephone modems >> and flaky connections it was worth something. And if you are setting up >> something on the Hebrides or on a buoy in the Atlantic where no >> connection of anykind is possible, it could be useful. >> Ie, it IS different from orphan mode. > > "Things chronyd can do that ntpd can?t: chronyd provides support for > isolated networks whether the only method of time correction is manual > entry (e.g. by the administrator looking at a clock)." > > The claim is for "networks", not single machines. It will do that too. The crucial item there is "the only method of time correction is manual entry" which is different from ntpd and orphan mode. I have no idea why this conversation is continuing. The two are different. The two methods are trying to solve the same problem (timekeeping of isolated systems) but doing so in a different manner. If you like one better than the other, that is fine. But they are not the same. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-21 01:00, Rob wrote:
William Unruh wrote:
On 2015-02-19, Rob wrote:
Miroslav Lichvar wrote:
On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
We have systems in places that are not temperature controlled and then
chrony is much better. I am looking for the best way to find the
values to use in the tempcomp configuration directive.
What resolution does the sensor have? Don't expect good results
with 1C or 0.5C resolution that sensors on mainboards typically have.
I am still finding out what sensor is best to use, we do have a room
temperature sensor that has .1C resolution and is readable via snmp,
and there are the usual sensors for board- and inlet air temperature.
(and of course CPU temperature)
It does not matter if it is only a course indication, the room temperature
varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not
bad relative to that.
It is of course the temperature of the crystal itself that is important.
Ie, the room temp could be constant and the computer varies in its
workload and thus its internal temperature. Unfortunately temp sensors
on the crystal are rare in commodity computers.
I am not looking for a precise crystal temperature but for a ballpark
value that will compensate for the quick temperature swings that occur
when this system (which is in an unheated glasshouse) quickly warms up
when the sun rises, and cools down when the sun sets.
In ntpd these events result in offset swings that are the derivative
of the temperature. In chrony the swings are smaller, but it may be
deceptive because I have not yet found a completely satisfactory way
of gathering an "average offset" that is similar to the offset value
in ntpq -c rv.
Hi Rob,
If the systems can run x86/x64 Linux with Mono and WinForms or Windows
with .NET 2+ then OpenHardwareMonitor may be able to log the system
sensors.
For Linux see if lm_sensors/sensord/sensors/sensors-detect are available
on or for your system and look for data in:
/proc/acpi/thermal_zone/
/sys/bus/platform/devices/*temp*/
/sys/class/hwmon/hwmon[0-9]*/
/sys/class/thermal/{thermal_zone,cooling_device}[0-9]*/
Once you have the data, you may want to try weighted or windowed incremental
RMS values of temperature and frequency drift to see if they can be correlated.
--
Take care. Thanks, Brian Inglis
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
David Taylor wrote: On 21/02/2015 07:04, William Unruh wrote: [] orphan mode is about a group of computers. "Orphan Mode allows a group of ntpd processes to automonously select a leader in the event that all real time sources become unreachable (i.e. are inaccessible)." chrony's is that you can enter the time by hand (Ie, by typing a current time and hitting enter) on a single machine. You are the "remote clock". Now, how useful that is now adays is open to question, but in the past with telephone modems and flaky connections it was worth something. And if you are setting up something on the Hebrides or on a buoy in the Atlantic where no connection of anykind is possible, it could be useful. Ie, it IS different from orphan mode. "Things chronyd can do that ntpd can?t: chronyd provides support for isolated networks whether the only method of time correction is manual entry (e.g. by the administrator looking at a clock)." The claim is for "networks", not single machines. When I was on dialup with Demon, I used chrony on the dialup pc and my network of several pcs, mostly with ntpd, synced to that. I'd have a problem looking up the logs that far back but I don't think drift from chrony offline was above a few ms. My pcs in the late 80s through early 90s seemed to have better system clocks than modern pcs and also had provision to use an external source as system clock. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh wrote: > On 2015-02-19, Rob wrote: >> Miroslav Lichvar wrote: >>> On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote: We have systems in places that are not temperature controlled and then chrony is much better. I am looking for the best way to find the values to use in the tempcomp configuration directive. >>> >>> What resolution does the sensor have? Don't expect good results >>> with 1C or 0.5C resolution that sensors on mainboards typically have. >> >> I am still finding out what sensor is best to use, we do have a room >> temperature sensor that has .1C resolution and is readable via snmp, >> and there are the usual sensors for board- and inlet air temperature. >> (and of course CPU temperature) >> >> It does not matter if it is only a course indication, the room temperature >> varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not >> bad relative to that. > > It is of course the temperature of the crystal itself that is important. > Ie, the room temp could be constant and the computer varies in its > workload and thus its internal temperature. Unfortunately temp sensors > on the crystal are rare in commodity computers. I am not looking for a precise crystal temperature but for a ballpark value that will compensate for the quick temperature swings that occur when this system (which is in an unheated glasshouse) quickly warms up when the sun rises, and cools down when the sun sets. In ntpd these events result in offset swings that are the derivative of the temperature. In chrony the swings are smaller, but it may be deceptive because I have not yet found a completely satisfactory way of gathering an "average offset" that is similar to the offset value in ntpq -c rv. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
David Taylor writes: > On 21/02/2015 07:04, William Unruh wrote: > [] > > orphan mode is about a group of computers. "Orphan Mode allows a group > > of ntpd processes to automonously select a leader in the event that all > > real time sources become unreachable (i.e. are inaccessible)." > > > > chrony's is that you can enter the time by hand (Ie, by typing a current > > time and hitting enter) on a single machine. You are the "remote clock". N > ow, how useful that > > is now adays is open to question, but in the past with telephone modems > > and flaky connections it was worth something. And if you are setting up > > something on the Hebrides or on a buoy in the Atlantic where no > > connection of anykind is possible, it could be useful. > > Ie, it IS different from orphan mode. > > "Things chronyd can do that ntpd can?t: chronyd provides support for > isolated networks whether the only method of time correction is manual > entry (e.g. by the administrator looking at a clock)." > > The claim is for "networks", not single machines. And how does ntpd not support this case? (David, I know this is not something you are claiming.) H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh wrote: > On 2015-02-19, Rob wrote: >> Miroslav Lichvar wrote: >>> On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote: I am still finding out what sensor is best to use, we do have a room temperature sensor that has .1C resolution and is readable via snmp, and there are the usual sensors for board- and inlet air temperature. (and of course CPU temperature) It does not matter if it is only a course indication, the room temperature varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not bad relative to that. >>> >>> In my tests using a sensor with 1C resolution it was barely useful >>> with NTP sources and 1024s polling interval. If the sensitivity is >>> around 0.1 ppm per degree, 1C resolution means the compensation >>> jumping the frequency in 0.1ppm steps. That's a lot, especially if you >>> compare it to the tracking skew with a refclock. >> >> Ok but of course we are using PPS and a 16 second polling interval. >> (or maybe the PPS refclock polls even faster although it displays 4 as >> the poll interval indicator) > > The shm refclock will get one pulse per second, and then average the > offsets over a 16 sec period after getting rid of the outliers. I am not using the SHM refclock in those systems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 21/02/2015 07:04, William Unruh wrote: [] orphan mode is about a group of computers. "Orphan Mode allows a group of ntpd processes to automonously select a leader in the event that all real time sources become unreachable (i.e. are inaccessible)." chrony's is that you can enter the time by hand (Ie, by typing a current time and hitting enter) on a single machine. You are the "remote clock". Now, how useful that is now adays is open to question, but in the past with telephone modems and flaky connections it was worth something. And if you are setting up something on the Hebrides or on a buoy in the Atlantic where no connection of anykind is possible, it could be useful. Ie, it IS different from orphan mode. "Things chronyd can do that ntpd can?t: chronyd provides support for isolated networks whether the only method of time correction is manual entry (e.g. by the administrator looking at a clock)." The claim is for "networks", not single machines. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-21, Paul wrote: > On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote: > >> ??? how do assume that the chrony docs do not tell the truth? ^ you > > > I don't understand that sentence. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-21, David Taylor wrote: > On 20/02/2015 20:22, William Unruh wrote: > [] >> No. The local clock simply trusts the time (Ie all offsets are defined >> to be zero) chrony takes the time as entered by hand by the operator and >> uses that to determine the offset. Of course that will not be terribly >> accurate ( a second is probably good), but if you are disconnected for a >> month, a second is probably pretty good accuracy. > > In practice, how does that differ from orphan mode? I think that > statement on behalf of chrony needs to be clarified as it may be misleading. orphan mode is about a group of computers. "Orphan Mode allows a group of ntpd processes to automonously select a leader in the event that all real time sources become unreachable (i.e. are inaccessible)." chrony's is that you can enter the time by hand (Ie, by typing a current time and hitting enter) on a single machine. You are the "remote clock". Now, how useful that is now adays is open to question, but in the past with telephone modems and flaky connections it was worth something. And if you are setting up something on the Hebrides or on a buoy in the Atlantic where no connection of anykind is possible, it could be useful. Ie, it IS different from orphan mode. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 20/02/2015 20:22, William Unruh wrote: [] No. The local clock simply trusts the time (Ie all offsets are defined to be zero) chrony takes the time as entered by hand by the operator and uses that to determine the offset. Of course that will not be terribly accurate ( a second is probably good), but if you are disconnected for a month, a second is probably pretty good accuracy. In practice, how does that differ from orphan mode? I think that statement on behalf of chrony needs to be clarified as it may be misleading. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote: > ??? how do assume that the chrony docs do not tell the truth? I don't understand that sentence. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-19, Paul wrote: > On Thu, Feb 19, 2015 at 5:34 AM, David Taylor < > david-tay...@blueyonder.co.uk.invalid> wrote: > >> Does not NTP's orphan mode and local clock driver provide this? > > > Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release > it's useless* but "Orphan mode is intended to replace the local clock > driver. It provides a single simulated UTC source ...". Note that I > provided a link not any commentary on the correctness of the claims at that > link. It would be nice if the Chrony docs told the truth but likewise the > NTP docs. ??? how do assume that the chrony docs do not tell the truth? > > *Previously LOCL+PPS was a useful configuration, now you need (or should) > use kernel PPS. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-19, Rob wrote: > Miroslav Lichvar wrote: >> My update to that after the years would be that 3x is not really the >> minimum difference. If the clock is stable enough, they can perform >> similarly. > > Indeed when a system is in a reasonably constant temperature and the > clock happens to be good, ntpd performs similar to chrony. As I said, I believe that one of the reasons chrony is better is because it reacts to changes, like temp change, much faster. If there are no changes, I suspect, but cannot prove, that they are very similar. But most people do not have temperature controlled crystals on their computer, and most people have variable work that their computer does, so the internal temperature fluctuates. > > We have systems in places that are not temperature controlled and then > chrony is much better. I am looking for the best way to find the > values to use in the tempcomp configuration directive. > > Ideally there would be a program that analyzes a log of momentary > temperature and frequency values to find the coefficients, but how > is such a logfile even generated? > > Should I enter a tempcomp line with zero coefficients and then use > the tempcomp logging? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-19, David Taylor wrote: > On 19/02/2015 01:24, Paul wrote: > [] >> Chrony (in general) pros and cons: < >> http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages> > [] > > ... whwre it says: "Things chronyd can do that ntpd can?t: chronyd > provides support for isolated networks whether the only method of time > correction is manual entry (e.g. by the administrator looking at a clock)." > > Does not NTP's orphan mode and local clock driver provide this? > No. The local clock simply trusts the time (Ie all offsets are defined to be zero) chrony takes the time as entered by hand by the operator and uses that to determine the offset. Of course that will not be terribly accurate ( a second is probably good), but if you are disconnected for a month, a second is probably pretty good accuracy. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-19, Rob wrote: > Miroslav Lichvar wrote: >> On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote: >>> We have systems in places that are not temperature controlled and then >>> chrony is much better. I am looking for the best way to find the >>> values to use in the tempcomp configuration directive. >> >> What resolution does the sensor have? Don't expect good results >> with 1C or 0.5C resolution that sensors on mainboards typically have. > > I am still finding out what sensor is best to use, we do have a room > temperature sensor that has .1C resolution and is readable via snmp, > and there are the usual sensors for board- and inlet air temperature. > (and of course CPU temperature) > > It does not matter if it is only a course indication, the room temperature > varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not > bad relative to that. It is of course the temperature of the crystal itself that is important. Ie, the room temp could be constant and the computer varies in its workload and thus its internal temperature. Unfortunately temp sensors on the crystal are rare in commodity computers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-19, Rob wrote: > Miroslav Lichvar wrote: >> On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote: >>> I am still finding out what sensor is best to use, we do have a room >>> temperature sensor that has .1C resolution and is readable via snmp, >>> and there are the usual sensors for board- and inlet air temperature. >>> (and of course CPU temperature) >>> >>> It does not matter if it is only a course indication, the room temperature >>> varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not >>> bad relative to that. >> >> In my tests using a sensor with 1C resolution it was barely useful >> with NTP sources and 1024s polling interval. If the sensitivity is >> around 0.1 ppm per degree, 1C resolution means the compensation >> jumping the frequency in 0.1ppm steps. That's a lot, especially if you >> compare it to the tracking skew with a refclock. > > Ok but of course we are using PPS and a 16 second polling interval. > (or maybe the PPS refclock polls even faster although it displays 4 as > the poll interval indicator) The shm refclock will get one pulse per second, and then average the offsets over a 16 sec period after getting rid of the outliers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 10:58:14PM +, Harlan Stenn wrote: > Would the temperature monitoring script and coefficient > generation/processsing stuff be a good GSoC project? Not really, it would be probably easier to write the scripts than write the GSoC application. I'd be more interested in some research on software temperature compensation itself, how good the measurements need to be for a given time reference to be useful etc. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 04:15:45PM +, Rob wrote: > > The default PPS refclock driver poll is 0 (1s), this be changed too > > if the PPS signal has a higher rate. Some GPS units seems to have this > > configurable (e.g. ublox NEO-6T). > > The PPS really is 1 PPS, but I am not sure if chrony is evaluating each > pulse separately or is averaging 16 pulse measurements into one clock > adjustment group. (as it says poll 4) It's the latter. The PPS samples collected in one poll interval are processed by a median filter and the result is used to update the source statistics and update the clock. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 6:16 PM, Harlan Stenn wrote: > While that document is old and unmaintained > So put an appropriate note at the top of it and on the link to it from the WebHome page. No one that stumbles onto it is going to find any "gems". ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Paul writes: > On Thu, Feb 19, 2015 at 12:35 PM, David Taylor < > david-tay...@blueyonder.co.uk.invalid> wrote: > > > Accurate and current documentation is both essential and invaluable for > > any project! > > Well then under no circumstances should you read the ntp faq/howto at < > http://www.ntp.org/ntpfaq/NTP-a-faq.htm>. While that document is old and unmaintained, I've had dreams of somebody going over it to find any remaining "gems" and get that content added to support.ntp.org so the old FAQ can be removed. Hasn't happened yet. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Would the temperature monitoring script and coefficient generation/processsing stuff be a good GSoC project? If so, if somebody wants to mentor this please add it as an idea at http://support.ntp.org/bin/view/Dev/GSoCProjectIdeas H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 19/02/2015 18:09, Paul wrote: On Thu, Feb 19, 2015 at 12:35 PM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: Accurate and current documentation is both essential and invaluable for any project! Well then under no circumstances should you read the ntp faq/howto at < http://www.ntp.org/ntpfaq/NTP-a-faq.htm>. Yes, what with me also knowing very little Linux, I ended up writing my own "as built" rather than "as designed" guides, such as: http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html http://www.satsignal.eu/ntp/setup.html with much help from the folk here! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
I admit that I have not looked at the chrony code/doc and do not use it as it when I did take a look, it had no ref clock support so I don’t know what the objective is here. That said, from the current discussion I have a feeling that integrating temperature data into the clock control loop is not the right use for that info. Where frequency stability is paramount as in quartz/rubidium frequency standards which have stability 2 or more orders of magnitudes better than any cpu system clock, none of those use temperature data in their control loops and for good reason. The only instance where it could possibly be useful, but where there are no commercial implementation AFAIK would be where a 1PPS ref was lost. Use temperature date by all means, but use it to control the environment and not the loop, for what you are measuring with the clock offset is the result of the total perturbations on the system, temperature being the most important in the short term. With a modern cpu, chip temperature, for which you can get data has extremely erratic and rapid swings according to load. Trying to follow those is unlikely be productive as you have recognized . "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin > Le 19 févr. 2015 à 15:18, Miroslav Lichvar a écrit : > > On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote: >> I am still finding out what sensor is best to use, we do have a room >> temperature sensor that has .1C resolution and is readable via snmp, >> and there are the usual sensors for board- and inlet air temperature. >> (and of course CPU temperature) >> >> It does not matter if it is only a course indication, the room temperature >> varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not >> bad relative to that. > > In my tests using a sensor with 1C resolution it was barely useful > with NTP sources and 1024s polling interval. If the sensitivity is > around 0.1 ppm per degree, 1C resolution means the compensation > jumping the frequency in 0.1ppm steps. That's a lot, especially if you > compare it to the tracking skew with a refclock. > > I'd probably try a shorter polling interval first and maybe get a PPS > with higher rate if possible to minimize the swings due to temperature > changes. > > -- > Miroslav Lichvar > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 12:35 PM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: > Accurate and current documentation is both essential and invaluable for > any project! Well then under no circumstances should you read the ntp faq/howto at < http://www.ntp.org/ntpfaq/NTP-a-faq.htm>. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 19/02/2015 14:20, Paul wrote: On Thu, Feb 19, 2015 at 5:34 AM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: Does not NTP's orphan mode and local clock driver provide this? Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release it's useless* but "Orphan mode is intended to replace the local clock driver. It provides a single simulated UTC source ...". Note that I provided a link not any commentary on the correctness of the claims at that link. It would be nice if the Chrony docs told the truth but likewise the NTP docs. *Previously LOCL+PPS was a useful configuration, now you need (or should) use kernel PPS. Thanks for the update, Paul. It's something I've never used so please excuse me for confusing the two, and not being quite up-to-date with this. Accurate and current documentation is both essential and invaluable for any project! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Thu, Feb 19, 2015 at 02:42:39PM +, Rob wrote: >> Ok but of course we are using PPS and a 16 second polling interval. >> (or maybe the PPS refclock polls even faster although it displays 4 as >> the poll interval indicator) > > You may want to try a shorter polling interval and see if the swings > are still there. If poll 3 doesn't help, you can try even shorter, but > normal timekeeping when the temperature isn't changing rapidly will > likely get worse. Well, as it is now we see no real "swings" as with ntpd, but more like random spikes in each direction. It was only my guess that these could be lessened when chrony knows about clock rate changes beforehand. The excursions are about ten times less than the swings in ntpd. > The default PPS refclock driver poll is 0 (1s), this be changed too > if the PPS signal has a higher rate. Some GPS units seems to have this > configurable (e.g. ublox NEO-6T). The PPS really is 1 PPS, but I am not sure if chrony is evaluating each pulse separately or is averaging 16 pulse measurements into one clock adjustment group. (as it says poll 4) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 9:42 AM, Rob wrote: > > Ok but of course we are using PPS and a 16 second polling interval. > Use eight unless your system is broken in which replace it and then use eight. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 02:42:39PM +, Rob wrote: > Ok but of course we are using PPS and a 16 second polling interval. > (or maybe the PPS refclock polls even faster although it displays 4 as > the poll interval indicator) You may want to try a shorter polling interval and see if the swings are still there. If poll 3 doesn't help, you can try even shorter, but normal timekeeping when the temperature isn't changing rapidly will likely get worse. The default PPS refclock driver poll is 0 (1s), this be changed too if the PPS signal has a higher rate. Some GPS units seems to have this configurable (e.g. ublox NEO-6T). -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote: >> I am still finding out what sensor is best to use, we do have a room >> temperature sensor that has .1C resolution and is readable via snmp, >> and there are the usual sensors for board- and inlet air temperature. >> (and of course CPU temperature) >> >> It does not matter if it is only a course indication, the room temperature >> varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not >> bad relative to that. > > In my tests using a sensor with 1C resolution it was barely useful > with NTP sources and 1024s polling interval. If the sensitivity is > around 0.1 ppm per degree, 1C resolution means the compensation > jumping the frequency in 0.1ppm steps. That's a lot, especially if you > compare it to the tracking skew with a refclock. Ok but of course we are using PPS and a 16 second polling interval. (or maybe the PPS refclock polls even faster although it displays 4 as the poll interval indicator) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 5:34 AM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: > Does not NTP's orphan mode and local clock driver provide this? Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release it's useless* but "Orphan mode is intended to replace the local clock driver. It provides a single simulated UTC source ...". Note that I provided a link not any commentary on the correctness of the claims at that link. It would be nice if the Chrony docs told the truth but likewise the NTP docs. *Previously LOCL+PPS was a useful configuration, now you need (or should) use kernel PPS. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote: > I am still finding out what sensor is best to use, we do have a room > temperature sensor that has .1C resolution and is readable via snmp, > and there are the usual sensors for board- and inlet air temperature. > (and of course CPU temperature) > > It does not matter if it is only a course indication, the room temperature > varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not > bad relative to that. In my tests using a sensor with 1C resolution it was barely useful with NTP sources and 1024s polling interval. If the sensitivity is around 0.1 ppm per degree, 1C resolution means the compensation jumping the frequency in 0.1ppm steps. That's a lot, especially if you compare it to the tracking skew with a refclock. I'd probably try a shorter polling interval first and maybe get a PPS with higher rate if possible to minimize the swings due to temperature changes. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote: >> We have systems in places that are not temperature controlled and then >> chrony is much better. I am looking for the best way to find the >> values to use in the tempcomp configuration directive. > > What resolution does the sensor have? Don't expect good results > with 1C or 0.5C resolution that sensors on mainboards typically have. I am still finding out what sensor is best to use, we do have a room temperature sensor that has .1C resolution and is readable via snmp, and there are the usual sensors for board- and inlet air temperature. (and of course CPU temperature) It does not matter if it is only a course indication, the room temperature varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not bad relative to that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote: > We have systems in places that are not temperature controlled and then > chrony is much better. I am looking for the best way to find the > values to use in the tempcomp configuration directive. What resolution does the sensor have? Don't expect good results with 1C or 0.5C resolution that sensors on mainboards typically have. > Ideally there would be a program that analyzes a log of momentary > temperature and frequency values to find the coefficients, but how > is such a logfile even generated? > > Should I enter a tempcomp line with zero coefficients and then use > the tempcomp logging? Yes, you can use that or you can collect data from the sensor file with a "while true; do echo $(date +'%s'; cat /sys/...); sleep 1; done" script independently from chronyd. After collecting enough data over a wide range of temperature you need to pair the temperature values with frequency from the tracking log and find the coefficients for the quadratic function, or (with 2.0-pre1) it's easier to create a file containing list of (temperature, correction) points for the second form of the tempcomp configuration. For example, you could divide temperature in 0.1C intervals and use mean frequency offset as the correction. Not sure if it needs to be negated or not, I always forget. I agree it would be nice to have a script that would automate this process. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 19/02/2015 01:24, Paul wrote: [] Chrony (in general) pros and cons: < http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages> [] ... whwre it says: "Things chronyd can do that ntpd can’t: chronyd provides support for isolated networks whether the only method of time correction is manual entry (e.g. by the administrator looking at a clock)." Does not NTP's orphan mode and local clock driver provide this? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > My update to that after the years would be that 3x is not really the > minimum difference. If the clock is stable enough, they can perform > similarly. Indeed when a system is in a reasonably constant temperature and the clock happens to be good, ntpd performs similar to chrony. We have systems in places that are not temperature controlled and then chrony is much better. I am looking for the best way to find the values to use in the tempcomp configuration directive. Ideally there would be a program that analyzes a log of momentary temperature and frequency values to find the coefficients, but how is such a logfile even generated? Should I enter a tempcomp line with zero coefficients and then use the tempcomp logging? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Wed, Feb 18, 2015 at 10:00:08PM -0500, Paul wrote: > On Wed, Feb 18, 2015 at 8:53 PM, William Unruh wrote: > > On 2015-02-19, Paul wrote: > > > In the specific case of PPS I don't see any advantage. > > > > Well, no. Lichvar did some tests with PPS and found that chrony > > disciplined the clock much better than did ntpd (factors of over 10). I > > think that is a difference. > > > > Do you have a link to that? The graphs I saw were all for (simulated?) > clients. But it's been a while. It could be this post http://lists.ntp.org/pipermail/questions/2010-March/026157.html My update to that after the years would be that 3x is not really the minimum difference. If the clock is stable enough, they can perform similarly. > A difference is not necessarily an advantage (I said advantage not > difference) but I would have assumed that < > https://github.com/mlichvar/chrony/blob/master/README> was correct which > says one microsecond* (I assume offset but it's unclear) but let's go with > 10x NTPd. On my machines NTPd offsets and jitter can be sub-microsecond. > So the target is O(10) nanoseconds? I don't think 10 nanoseconds is possible with 1us jitter and normal unstabilized clock. When using a PTP clock on PCIe as a reference it can get quite close though, see this graph from stats collected over a few hours: https://mlichvar.fedorapeople.org/chrony/refclock_phc0.png -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh wrote: >> In the specific case of PPS I don't see any advantage. > > Well, no. Lichvar did some tests with PPS and found that chrony > disciplined the clock much better than did ntpd (factors of over 10). I > think that is a difference. I am seeing the same thing on our PPS synchronized servers. When the temperature changes, the swing observed in time offset is about a factor of 10 less with chrony than with ntpd. With ntpd the excursions are up to about 3us, with chrony up to about 300ns. With chrony there is just a random offset sometimes, with ntpd the derivative of the temperature can clearly be seen in the offset plots. And I have not yet configured the temperature compensation in chrony. (first have to figure out how to calibrate it) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Wed, Feb 18, 2015 at 8:53 PM, William Unruh wrote: > On 2015-02-19, Paul wrote: > > On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott > > > wrote: > > > >> If you don't mind me asking, why is chrony superior to NTPD > >> for tracking a PPS signal, or even in general > > > > > > Chrony (in general) pros and cons: < > > > http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages > > > > Just so people reading this know what you are saying > You've really got to let go of the need for third party paraphrase. *I'm* not saying anything about Chrony or Ntimed-client. The authorities on those programs should be accepted as authorities. People that want to know about Chrony can click on the link and read for themselves unfiltered by you. > > In the specific case of PPS I don't see any advantage. > > Well, no. Lichvar did some tests with PPS and found that chrony > disciplined the clock much better than did ntpd (factors of over 10). I > think that is a difference. > Do you have a link to that? The graphs I saw were all for (simulated?) clients. But it's been a while. A difference is not necessarily an advantage (I said advantage not difference) but I would have assumed that < https://github.com/mlichvar/chrony/blob/master/README> was correct which says one microsecond* (I assume offset but it's unclear) but let's go with 10x NTPd. On my machines NTPd offsets and jitter can be sub-microsecond. So the target is O(10) nanoseconds? >Note that Ntimed... > > That is a promise not fact. Lets see how it works out. If it uses the same > design > as ntpd, it is hard to see how it will "fix" the "deficiencies". But we > will see. > In fact it's a fact. Please stop refusing to read the Ntimed notes. It just makes you look bad. Besides if you read the notes you can find the glaring error and complain about it. *"With a good reference clock the accuracy can reach one microsecond." ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-19, Paul wrote: > On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott > wrote: > >> If you don't mind me asking, why is chrony superior to NTPD >> for tracking a PPS signal, or even in general > > > Chrony (in general) pros and cons: < > http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages> Just so people reading this know what you are saying (in the cons package) "Things ntpd can do that chronyd can’t: ntpd fully supports NTP version 4 (RFC5905), including broadcast, multicast, manycast clients / servers and the orphan mode. It also supports extra authentication schemes based on public-key cryptography (RFC5906). chronyd uses NTP version 3 (RFC1305), which is compatible with version 4. ntpd has been ported to more types of computer / operating system. ntpd includes drivers for many reference clocks. chronyd relies on other programs (e.g. gpsd) to access the data from the reference clocks. " So, if you run Windows, chrony is not for you. If you need the version 4 things again use ntpd. On the other hand if you want your system time to be closer to UTC use chrony (in part because of the faster response of chrony to changes like temperature changes). Both will discipline your clock, and work well at doing so. > > > In the specific case of PPS I don't see any advantage. Well, no. Lichvar did some tests with PPS and found that chrony disciplined the clock much better than did ntpd (factors of over 10). I think that is a difference. >Note that Ntimed is > intended to "fix" nearly all the "deficiencies" (of consequence) of ntpd > relative to chrony, That is a promise not fact. Lets see how it works out. If it uses the same design as ntpd, it is hard to see how it will "fix" the "deficiencies". But we will see. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott wrote: > If you don't mind me asking, why is chrony superior to NTPD > for tracking a PPS signal, or even in general Chrony (in general) pros and cons: < http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages> In the specific case of PPS I don't see any advantage. Note that Ntimed is intended to "fix" nearly all the "deficiencies" (of consequence) of ntpd relative to chrony, ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
If you don't mind me asking, why is chrony superior to NTPD for tracking a PPS signal, or even in general? Charles Elliott > -Original Message- > From: questions-bounces+elliott.ch=comcast@lists.ntp.org > [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On > Behalf Of Rob > Sent: Tuesday, February 17, 2015 3:27 AM > To: questions@lists.ntp.org > Subject: Re: [ntp:questions] chrony as a server > > David Woolley wrote: > > On 15/02/15 22:40, Rob wrote: > >> it is tracking very nicely > > > > Tracking what? > > The PPS signal. > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-17, Rob wrote: > William Unruh wrote: >> As I said I have six machines, one of which is at home over an cable >> modem line, all getting their time from chrony on a server. No trouble >> whatsoever, and I have never had any. This suggests that there is >> something else going on. Now, I do not have the very latest chrony >> running on my server (1.29.1) so it is possible that there is a bug in >> your version. > > The problem was already located, see elsewhere in the thread. > It is a bug. Yes, I noticed those after I had responded. I was protected by not using 30 or 31:-) (and not having "loops" where servers referenced servers.) Glad the bug has been tracked down. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh wrote: > As I said I have six machines, one of which is at home over an cable > modem line, all getting their time from chrony on a server. No trouble > whatsoever, and I have never had any. This suggests that there is > something else going on. Now, I do not have the very latest chrony > running on my server (1.29.1) so it is possible that there is a bug in > your version. The problem was already located, see elsewhere in the thread. It is a bug. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 16/02/2015 19:54, Paul wrote: On Mon, Feb 16, 2015 at 2:57 AM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: For me, there are two show-stoppers with Chrony: - no support for standard NTP monitoring commands. - no support for ref-clocks on Windows. Like many others, I have built up a considerable monitoring architecture based on using ntpq Flexibility is good. Perhaps snmp should be your way forward. Yes, that would be a possibility, although there is no SNMP support in the current Windows port at the moment, and I don't have the expertise to write it (and if I did, it would be written in Delphi in any case). I'm sure that others would rather stick with the ntpq commands they have developed over the decades rather than having to change for no perceived benefit. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-16, Rob wrote: > William Unruh wrote: >> On 2015-02-15, Rob wrote: >>> I am experimenting with chrony 1.31 as an alternative on some PPS >>> synchronized servers. It appears to run OK, it is tracking very nicely: >>> >>> Reference ID: 80.80.83.48 (PPS0) >>> Stratum : 1 >>> Ref time (UTC) : Sun Feb 15 22:34:01 2015 >>> System time : 0.00076 seconds fast of NTP time >>> Last offset : +0.00085 seconds >>> RMS offset : 0.00751 seconds >>> Frequency : 10.014 ppm slow >>> Residual freq : -0.004 ppm >>> Skew: 0.042 ppm >>> Root delay : 0.00 seconds >>> Root dispersion : 0.17 seconds >>> Update interval : 16.0 seconds >>> Leap status : Normal >>> >>> However, it does not reply to NTP requests from other systems with ntpd. >>> (I can confirm that in a network trace) >>> >>> The config includes: >>> >>> allow 0/0 >> >> Try 0.0.0.0/0 >> instead. >> Or allow 192.168.0.0/16 > > The 0/0 is from the manual. It is specified to allow all sources. > As I wrote: > I have also tried other allow lines, like allow 192.168.42.0/24 for the > subnet it is on. No difference. > > Note that it processes the cmdallow with the same subnet OK, i.e. I can > use chronyc from another computer, but it does not reply to time requests > from that computer. Before, when ntpd was running, it worked. There > is no firewall that drops the packets. As I said I have six machines, one of which is at home over an cable modem line, all getting their time from chrony on a server. No trouble whatsoever, and I have never had any. This suggests that there is something else going on. Now, I do not have the very latest chrony running on my server (1.29.1) so it is possible that there is a bug in your version. Unfortunately I cannot test the latest right now. But you could try going to an earlier version and seeing if the problem persists. If it does not, then please file a bug report. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 07:19:39PM +, Rob wrote: > The PPS refclock has changed is refid from PPP0 to PPP1 with this version. That is a bug, the refid numbering wasn't supposted to change in the new version. Fixed in git. Thanks. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
David Woolley wrote: > On 15/02/15 22:40, Rob wrote: >> it is tracking very nicely > > Tracking what? The PPS signal. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: On Mon, Feb 16, 2015 at 03:51:07PM +, David Lord wrote: Miroslav Lichvar wrote: As a workaround you can add "acquisitionport 123" to chrony.conf to use just one socket for all (client, peer, server) communication, which will effectively disable the check in which the server's request is failing. Done and ready for next restart. Apparently, that workaround is not usable with 1.31, sorry for the noise. That was it, as restart after the client had been removed from chrony.conf the client picked up a reply from chrony. So that bug still needs fixing. I'm not sure what's wrong, it seems to be working for me with 2.0-pre1. Nothing wrong, it started working ok after I had removed that client from the config file. I meant with 2.0-pre1 the clients should be getting responses even if they are configured as servers in chrony.conf with otherwise standard configuration. It seems to work for me. If it doesn't for you, can you please post your chronyd -d -d output? Hi I am using 2.0-pre1. The clients were not getting responses when they were configured as servers in my original chrony.conf. Since I added the "acquisitionport 123" line it has been responding to requests. I saw that the chronyd -d -d output flagged errors due to either chrony.keys and/or keys directory from ntpd and after these were cleared chronyd started ok and was responding to requests without need of the "acquisitionport 123" line. Script started on Tue Feb 17 01:37:23 2015 bash-4.3# /usr/local/sbin/chronyd -d -d -4 -f /usr/local/etc/chrony/chrony.conf 2015-02-17T01:37:29Z main.c:433:(main) chronyd version 2.0-pre1 starting (+CMDMON +NTP +REFCLOCK -RTC -PRIVDROP -DEBUG +ASYNCDNS +IPV6 -SECHASH) 2015-02-17T01:37:29Z reference.c:193:(REF_Initialise) Frequency -0.073 +/- 4.049 ppm read from /var/db/chrony/chrony.drift 2015-02-17T01:37:34Z sources.c:454:(log_selection_message) Selected source 192.168.59.61 2015-02-17T01:54:32Z main.c:528:(main) chronyd exiting bash-4.3# exit Script done on Tue Feb 17 01:54:42 2015 Thanks David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 15/02/15 22:40, Rob wrote: it is tracking very nicely Tracking what? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 12:14 PM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: > I have a non-trivial interest I meant in Ntimed (the system) not time transfer in general. > If ntimed is not going to be available for Windows and OS/X that rules it > out for the great majority of the world's computers. It's sad that systems that want accurate time are developed on platforms that have trouble delivering on that need. However in the case of MacOS X it's a non-issue. The NTPd that ships post 10.9 doesn't steer the clock. That's done by Pacemaker. So Apple has already gone their own way. Of course the bulk of Apple devices (iOS) do use NTP but rather more like ntpdate. > The NTP team has made outstanding efforts to encourage cross-platform > portability such that the same source code can be compiled and run on > multiple platforms, and the same management interface used even across > platforms > I expect the same thing of Ntimed but I wouldn't be surprised if the management interface has little in common with reference NTP ntpq presentation. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 2:57 AM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: > For me, there are two show-stoppers with Chrony: > > - no support for standard NTP monitoring commands. > > - no support for ref-clocks on Windows. > > Like many others, I have built up a considerable monitoring architecture > based on using ntpq > Flexibility is good. Perhaps snmp should be your way forward. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Mon, Feb 16, 2015 at 03:30:52PM +, Rob wrote: >> Miroslav Lichvar wrote: >> > On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote: >> >> Is chronyc of 1.31 compatible with chronyd 2.0? >> > >> > Yes, old configuration should still work. But you can use >> > "acquisitionport 123" as a workaround if you prefer stable version. >> >> Well I tried that before and it did not solve that issue. > > Hm, you are right. I tried it again and it seems this works only with > 1.30 and not 1.31. > >> What I mean is can I manage a mix of 1.31 and 2.0 servers from a single >> system with one version of chronyc. > > Yes, that should be compatible. The cmdmon protocol was just extended > (with one command - runtime makestep configuration) between 1.31 and > 2.0. With 2.0 chronyc you can do everything 1.31 chronyc does, with > 1.31 chronyc you can do everything except that one command. > > For 2.0, you will need to add "bindcmdaddress 0.0.0.0" to chrony.conf > for as it binds to the loopback interface by default now. Ok I have compiled the new version and changed those config items and now it replies to NTP requests. Thanks. The PPS refclock has changed is refid from PPP0 to PPP1 with this version. I have added "refid PPS" now. Now I am going to monitor it a bit and see if it can be installed on the other PPS synced servers (instead of ntpd). I am still experimenting with the field from "tracking" to use instead of the var "offset" in ntpq. (I am graphing this value in nagios to watch the time inaccuracy, which should be within a few microseconds in my application) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 03:12:27PM +0100, Terje Mathisen wrote: > William Unruh wrote: > >I think, but am not sure, that the biggest problem with porting chrony > >to windows is that windows does not have a good way of having the kernel > >discipline the clock-- the equivalent of adjtimex on Linux. > > If this is the biggest problem, then it would already be running there! There is also the part with porting all the code to Win32/Cygwin :). > GetSystemTimeAdjustment() > SetSystemTimeAdjustment() > > The only "hard" part is that you have to manually convert the adjustment > rate to an absolute value: > > Call Get* to retrieve the amount the system clock is incremented by on each > timer tick/basic clock interval, then scale this value by the adjustment > rate, i.e. to add 5.6ppm you would take the base value and multiply by > 1.056. In what resolution can be the frequency controlled? I'm not sure if I remember correctly, I thought it was rather bad and would require dithering. Looking at nt_clockstuff.c in the ntp distribution, it certainly doesn't look easy. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 16/02/2015 15:59, Paul wrote: [] If you have a non-trivial interest I suggest reading the notes. E.g. "Ntimed-client puts the entire interface to the OS timekeeping in four trivial functions for portability, but there are other nits and downright idiotic incompatibilities, because, quite frankly, the UNIX ecosystem is filled with narrowsighted bigots. At the timekeeping-level, Windows and OS/X are the odd ones out, and both of these will need a dedicated set of the four functions. I hope somebody with skills and access to those platforms will contribute them." Of course at the end of the day you're going to be a bit disappointed. I have a non-trivial interest in that I have hundreds of users (mostly non-computer experts) who rely on NTP on Windows to get their machines in sync for a collaborative data-sharing effort. There are also many radio amateurs who need Windows PCs synced to within 100 milliseconds for propagation and other measurements. If ntimed is not going to be available for Windows and OS/X that rules it out for the great majority of the world's computers. No problem if it starts on Linux, with the clear intention of making it portable - client /and/ server. But as I mentioned, NTP has already been very successfully ported to Windows, and found little difficulty in using the available OS calls to control both the rate and the absolute value of time, so I see no reason why ntimed should not do the same. For the present, I have found very, very few who are in any way dissatisfied with NTP 4.2.8p1 and its successors - perhaps just those with really bad clocks! The NTP team has made outstanding efforts to encourage cross-platform portability such that the same source code can be compiled and run on multiple platforms, and the same management interface used even across platforms, and I know many, many people who are very grateful for that effort. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 03:51:07PM +, David Lord wrote: > Miroslav Lichvar wrote: > >As a workaround you can add "acquisitionport 123" to chrony.conf to > >use just one socket for all (client, peer, server) communication, > >which will effectively disable the check in which the server's request > >is failing. > > Done and ready for next restart. Apparently, that workaround is not usable with 1.31, sorry for the noise. > >>That was it, as restart after the client had been removed from > >>chrony.conf the client picked up a reply from chrony. So that > >>bug still needs fixing. > > > >I'm not sure what's wrong, it seems to be working for me with > >2.0-pre1. > > Nothing wrong, it started working ok after I had removed that > client from the config file. I meant with 2.0-pre1 the clients should be getting responses even if they are configured as servers in chrony.conf with otherwise standard configuration. It seems to work for me. If it doesn't for you, can you please post your chronyd -d -d output? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 03:30:52PM +, Rob wrote: > Miroslav Lichvar wrote: > > On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote: > >> Is chronyc of 1.31 compatible with chronyd 2.0? > > > > Yes, old configuration should still work. But you can use > > "acquisitionport 123" as a workaround if you prefer stable version. > > Well I tried that before and it did not solve that issue. Hm, you are right. I tried it again and it seems this works only with 1.30 and not 1.31. > What I mean is can I manage a mix of 1.31 and 2.0 servers from a single > system with one version of chronyc. Yes, that should be compatible. The cmdmon protocol was just extended (with one command - runtime makestep configuration) between 1.31 and 2.0. With 2.0 chronyc you can do everything 1.31 chronyc does, with 1.31 chronyc you can do everything except that one command. For 2.0, you will need to add "bindcmdaddress 0.0.0.0" to chrony.conf for as it binds to the loopback interface by default now. > It would be nice when chronyd could be contacted using ntpq with at > least the -p and the -c rv commands. Then the monitoring system does > not need to know what kind of ntp daemon is running on the servers. It would make the monitoring easier, but chronyd has different internal variables so it would have to be an emulation even if only the -p and -c rv commands were supported. >From the security point of view, I'd prefer to not have any support for the private/control modes of NTP. The chrony protocol runs on a separate port and the access can be tightly controlled, independently from NTP access. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: On Mon, Feb 16, 2015 at 12:56:27PM +, David Lord wrote: I've just fetched chrony-2.0-pre1. It seemed to compile and install ok on NetBSD-6/i386. The client IS one of the servers configured in chrony.conf and it behaved same as with 1.31. I didn't know this was such a common configuration. As a workaround you can add "acquisitionport 123" to chrony.conf to use just one socket for all (client, peer, server) communication, which will effectively disable the check in which the server's request is failing. Done and ready for next restart. That was it, as restart after the client had been removed from chrony.conf the client picked up a reply from chrony. So that bug still needs fixing. I'm not sure what's wrong, it seems to be working for me with 2.0-pre1. Nothing wrong, it started working ok after I had removed that client from the config file. I'd just used the same server lines as I had in my ntp.conf. Assuming "acquisitionport 123" works I can use the same peer and server lines. thanks David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 5:22 AM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: > I hope that ntimed will not be available only on Linux If you have a non-trivial interest I suggest reading the notes. E.g. "Ntimed-client puts the entire interface to the OS timekeeping in four trivial functions for portability, but there are other nits and downright idiotic incompatibilities, because, quite frankly, the UNIX ecosystem is filled with narrowsighted bigots. At the timekeeping-level, Windows and OS/X are the odd ones out, and both of these will need a dedicated set of the four functions. I hope somebody with skills and access to those platforms will contribute them." Of course at the end of the day you're going to be a bit disappointed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote: >> Is chronyc of 1.31 compatible with chronyd 2.0? > > Yes, old configuration should still work. But you can use > "acquisitionport 123" as a workaround if you prefer stable version. Well I tried that before and it did not solve that issue. What I mean is can I manage a mix of 1.31 and 2.0 servers from a single system with one version of chronyc. It is not that important, now I can still update everything in one go. It would be nice when chronyd could be contacted using ntpq with at least the -p and the -c rv commands. Then the monitoring system does not need to know what kind of ntp daemon is running on the servers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote: > Is chronyc of 1.31 compatible with chronyd 2.0? Yes, old configuration should still work. But you can use "acquisitionport 123" as a workaround if you prefer stable version. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh wrote: On 2015-02-16, David Taylor wrote: On 16/02/2015 07:59, William Unruh wrote: [] ?? There are chonyc which is its own monitoring. chrony is not ntpd, so why would you expect ntpc monitoring commands to work? [] As I already said, compatibility with the installed base would greatly increase the acceptance on different software. I think, but am not sure, that the biggest problem with porting chrony to windows is that windows does not have a good way of having the kernel discipline the clock-- the equivalent of adjtimex on Linux. If this is the biggest problem, then it would already be running there! GetSystemTimeAdjustment() SetSystemTimeAdjustment() The only "hard" part is that you have to manually convert the adjustment rate to an absolute value: Call Get* to retrieve the amount the system clock is incremented by on each timer tick/basic clock interval, then scale this value by the adjustment rate, i.e. to add 5.6ppm you would take the base value and multiply by 1.056. Finally you call Set* to program the new clock frequency. Obviously you have call the Set* function once more to turn off or modify the adjustment. The only way to make it much simpler is to have something like the Netware clock, where you got a pointer to the clock data: Basic increment per timer tick Current increment per tick Current additional increment/decrement Nr of timer ticks when that additional adjustment should be applied Final extra adjustment. The last variable was in order to make it easier to get an exact adjustment by taking the total adjustment and dividing by the number of ticks to spread it over, with the remainder to go in that final field. Terje Let's hope that ntimed is usable with Windows, otherwise it too will be out of the window. -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 12:56:27PM +, David Lord wrote: > I've just fetched chrony-2.0-pre1. It seemed to compile and > install ok on NetBSD-6/i386. The client IS one of the servers > configured in chrony.conf and it behaved same as with 1.31. I didn't know this was such a common configuration. As a workaround you can add "acquisitionport 123" to chrony.conf to use just one socket for all (client, peer, server) communication, which will effectively disable the check in which the server's request is failing. > That was it, as restart after the client had been removed from > chrony.conf the client picked up a reply from chrony. So that > bug still needs fixing. I'm not sure what's wrong, it seems to be working for me with 2.0-pre1. ntp.conf (for ntp-4.2.6p5) on host 1: server 192.168.100.2 minpoll 3 maxpoll 3 driftfile /var/lib/ntp/drift chrony.conf on host 2: pool 2.pool.ntp.org iburst server 192.168.100.1 minpoll 3 maxpoll 3 driftfile /var/lib/chrony/drift allow 0/0 # /usr/sbin/chronyd -d -d ... 2015-02-16T14:16:27Z ntp_core.c:906:(transmit_timeout) Transmit timeout for [192.168.100.1:123 ] (this is chrony sending its client request) 2015-02-16T14:16:27Z ntp_io.c:679:(send_packet) Sent 48 bytes to 192.168.100.1:123 from [UNSPE C] fd 6 (receiving reply from ntpd) 2015-02-16T14:16:27Z ntp_io.c:562:(read_from_socket) Received 48 bytes from 192.168.100.1:123 to 192.168.100.2 fd 6 ... (discarding it for synchronization loop testD=0) 2015-02-16T14:16:27Z ntp_core.c:1287:(receive_packet) test123=111 test567=111 testABCD=1110 kod_rate=0 valid=1 good=0 (this is ntpd's request) 2015-02-16T14:16:33Z ntp_io.c:562:(read_from_socket) Received 48 bytes from 192.168.100.1:123 to 192.168.100.2 fd 5 (and chrony sending reply) 2015-02-16T14:16:33Z ntp_io.c:679:(send_packet) Sent 48 bytes to 192.168.100.1:123 from 192.168.100.2 fd 5 # ntpq -pn remote refid st t when poll reach delay offset jitter == *192.168.100.2 176.9.1.148 4 u68 3770.1430.044 0.055 If you compile chrony with --enable-debug, do you see similar Received and Sent message pairs in the chronyd -d -d output? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote: >> I have strace'd the daemon and I see that it does receive the datagram >> from the socket, but it does not send a reply. > > Hm, interesting. Can you post what follows that recvmsg() call? I can not do that right now but I remember that it received a 48 byte datagram. > You could try running it with -d -d (after it's compiled with > --enable-debug) and see if there are any debug messages indicating why > it's dropping the client request. If there aren't any, you could try > it with chrony-2.0-pre1 and see if it's different. I had tried that but I had not yet compiled it with de debug option. It did issue messages but not about this. Something to try tonight. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Mon, Feb 16, 2015 at 11:29:31AM +0100, Miroslav Lichvar wrote: >> On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote: >> > I have strace'd the daemon and I see that it does receive the datagram >> > from the socket, but it does not send a reply. >> >> Hm, interesting. Can you post what follows that recvmsg() call? >> >> You could try running it with -d -d (after it's compiled with >> --enable-debug) and see if there are any debug messages indicating why >> it's dropping the client request. If there aren't any, you could try >> it with chrony-2.0-pre1 and see if it's different. > > BTW, could it be that the client is one of the servers configured in > chrony.conf? The client request from the configured server would be > dropped as an invalid reply to chrony's own client request. This bug > was in 1.30 and 1.31, it should be fixed in 2.0-pre1. I think that is the reason! Both sources that I tried are also defined as server. I will try to install the new version. Is chronyc of 1.31 compatible with chronyd 2.0? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: On Mon, Feb 16, 2015 at 11:29:31AM +0100, Miroslav Lichvar wrote: On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote: I have strace'd the daemon and I see that it does receive the datagram from the socket, but it does not send a reply. Hm, interesting. Can you post what follows that recvmsg() call? You could try running it with -d -d (after it's compiled with --enable-debug) and see if there are any debug messages indicating why it's dropping the client request. If there aren't any, you could try it with chrony-2.0-pre1 and see if it's different. BTW, could it be that the client is one of the servers configured in chrony.conf? The client request from the configured server would be dropped as an invalid reply to chrony's own client request. This bug was in 1.30 and 1.31, it should be fixed in 2.0-pre1. Hi I've just fetched chrony-2.0-pre1. It seemed to compile and install ok on NetBSD-6/i386. The client IS one of the servers configured in chrony.conf and it behaved same as with 1.31. That was it, as restart after the client had been removed from chrony.conf the client picked up a reply from chrony. So that bug still needs fixing. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 11:29:31AM +0100, Miroslav Lichvar wrote: > On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote: > > I have strace'd the daemon and I see that it does receive the datagram > > from the socket, but it does not send a reply. > > Hm, interesting. Can you post what follows that recvmsg() call? > > You could try running it with -d -d (after it's compiled with > --enable-debug) and see if there are any debug messages indicating why > it's dropping the client request. If there aren't any, you could try > it with chrony-2.0-pre1 and see if it's different. BTW, could it be that the client is one of the servers configured in chrony.conf? The client request from the configured server would be dropped as an invalid reply to chrony's own client request. This bug was in 1.30 and 1.31, it should be fixed in 2.0-pre1. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote: > I have strace'd the daemon and I see that it does receive the datagram > from the socket, but it does not send a reply. Hm, interesting. Can you post what follows that recvmsg() call? You could try running it with -d -d (after it's compiled with --enable-debug) and see if there are any debug messages indicating why it's dropping the client request. If there aren't any, you could try it with chrony-2.0-pre1 and see if it's different. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 16/02/2015 08:46, William Unruh wrote: [] I think, but am not sure, that the biggest problem with porting chrony to windows is that windows does not have a good way of having the kernel discipline the clock-- the equivalent of adjtimex on Linux. NTP already manages that very well on Windows. I hope that ntimed will not be available only on Linux. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
I have strace'd the daemon and I see that it does receive the datagram from the socket, but it does not send a reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Miroslav Lichvar wrote: > On Sun, Feb 15, 2015 at 10:40:11PM +, Rob wrote: >> However, it does not reply to NTP requests from other systems with ntpd. >> (I can confirm that in a network trace) > >> Is there a magic command that has to be in the config to make it work >> as a server? > > No, your configuration looks good. Any chance there is a forgotten > firewall rule blocking NTP or that clients are actually using IPv6? There is an iptables firewall active but it is only for another interface, for eth0 it allows everything: 430M 123G ACCEPT all -- eth0 * 0.0.0.0/00.0.0.0/0 The local network on which this is running is exclusively IPv4. (we do have IPv6 on internet but that is on another machine) > Is chronyd listening on the port? > > # netstat -a -n -p | grep 123 > udp0 0 0.0.0.0:123 0.0.0.0:* > 29615/chronyd > udp6 0 0 :::123 :::* > 29615/chronyd Yes: netstat -a -n -p | grep 23 udp0 0 0.0.0.0:123 0.0.0.0:* 19707/chronyd udp0 0 0.0.0.0:323 0.0.0.0:* 19707/chronyd udp6 0 0 :::123 :::* 19707/chronyd udp6 0 0 :::323 :::* 19707/chronyd When I trace udp port 123 I see it sending/receiving its requests to the other servers, and I see the incoming requests from two other systems, but there are no replies to those going out. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
David Lord wrote: Rob wrote: I am experimenting with chrony 1.31 as an alternative on some PPS synchronized servers. It appears to run OK, it is tracking very nicely: . Me too, I downloaded compiled and installed earlier this morning on NetBSD-6/i386. When I was on dialup, I used chrony on linux from mid 80s then on MetBSD and FreeBSD from 1997 to 2005. My internal network used ntpd and had no problem with that getting time from the router running chrony. I might try to search out an old chrony.conf as I still used it on my laptops for a while after 2005. I've now tried with chrony.conf from 20140703 and 20100104 and see same failure to connect of ntpd clients (I couldn't see any significant differences in those conf file anyway). I'll try to find chrony-1.27. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 2015-02-16, David Taylor wrote: > On 16/02/2015 07:59, William Unruh wrote: > [] >> ?? There are chonyc which is its own monitoring. chrony is not ntpd, so >> why would you expect ntpc monitoring commands to work? > [] > > As I already said, compatibility with the installed base would greatly > increase the acceptance on different software. I think, but am not sure, that the biggest problem with porting chrony to windows is that windows does not have a good way of having the kernel discipline the clock-- the equivalent of adjtimex on Linux. > > Let's hope that ntimed is usable with Windows, otherwise it too will be > out of the window. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh wrote: > On 2015-02-15, Rob wrote: >> I am experimenting with chrony 1.31 as an alternative on some PPS >> synchronized servers. It appears to run OK, it is tracking very nicely: >> >> Reference ID: 80.80.83.48 (PPS0) >> Stratum : 1 >> Ref time (UTC) : Sun Feb 15 22:34:01 2015 >> System time : 0.00076 seconds fast of NTP time >> Last offset : +0.00085 seconds >> RMS offset : 0.00751 seconds >> Frequency : 10.014 ppm slow >> Residual freq : -0.004 ppm >> Skew: 0.042 ppm >> Root delay : 0.00 seconds >> Root dispersion : 0.17 seconds >> Update interval : 16.0 seconds >> Leap status : Normal >> >> However, it does not reply to NTP requests from other systems with ntpd. >> (I can confirm that in a network trace) >> >> The config includes: >> >> allow0/0 > > Try 0.0.0.0/0 > instead. > Or allow 192.168.0.0/16 The 0/0 is from the manual. It is specified to allow all sources. As I wrote: I have also tried other allow lines, like allow 192.168.42.0/24 for the subnet it is on. No difference. Note that it processes the cmdallow with the same subnet OK, i.e. I can use chronyc from another computer, but it does not reply to time requests from that computer. Before, when ntpd was running, it worked. There is no firewall that drops the packets. How can I determine why it is ignoring the requests? I started it with -d and it outputs debug info about the clock selection, but nothing for the incoming requests. >> I have also tried other allow lines, like allow 192.168.42.0/24 for the >> subnet it is on. No difference. >> >> I added: >> >> local stratum 10 >> >> because it appeared to be in an example. no difference. >> >> Is there a magic command that has to be in the config to make it work >> as a server? > > Nope. Mine words fine as a server. Is there anything not mentioned below that is required for a server? >> >> Configuration: >> >> driftfile /var/lib/ntp/ntp.drift >> logdir /var/log/ntpstats >> log statistics measurements tracking tempcomp >> local stratum 10 >> makestep10 3 >> refclockPPS /dev/pps0 >> server 192.168.42.1 iburst >> server 192.168.42.60iburst >> server 192.168.42.61iburst >> allow 0/0 >> cmdallow192.168.42.0/24 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
David Taylor wrote: > On 15/02/2015 22:40, Rob wrote: >> I am experimenting with chrony 1.31 as an alternative on some PPS >> synchronized servers. It appears to run OK, it is tracking very nicely: > [] > > For me, there are two show-stoppers with Chrony: > > - no support for standard NTP monitoring commands. Indeed that is a pity. I am monitoring the server performance using a nagios plugin, and I had to write a new one that uses chronyc tracking to retrieve the values. Chrony should at least implement the peer and readvar commands from ntpd/ntpq, in the port-123 protocol. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On Sun, Feb 15, 2015 at 10:40:11PM +, Rob wrote: > However, it does not reply to NTP requests from other systems with ntpd. > (I can confirm that in a network trace) > Is there a magic command that has to be in the config to make it work > as a server? No, your configuration looks good. Any chance there is a forgotten firewall rule blocking NTP or that clients are actually using IPv6? Is chronyd listening on the port? # netstat -a -n -p | grep 123 udp0 0 0.0.0.0:123 0.0.0.0:* 29615/chronyd udp6 0 0 :::123 :::* 29615/chronyd > Configuration: > > driftfile /var/lib/ntp/ntp.drift > logdir /var/log/ntpstats > log statistics measurements tracking tempcomp > local stratum 10 > makestep10 3 > refclockPPS /dev/pps0 > server 192.168.42.1 iburst > server 192.168.42.60iburst > server 192.168.42.61iburst > allow 0/0 > cmdallow192.168.42.0/24 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 15/02/2015 22:40, Rob wrote: I am experimenting with chrony 1.31 as an alternative on some PPS synchronized servers. It appears to run OK, it is tracking very nicely: [] For me, there are two show-stoppers with Chrony: - no support for standard NTP monitoring commands. - no support for ref-clocks on Windows. Like many others, I have built up a considerable monitoring architecture based on using ntpq, in particular the ntpq -crv, and ntpq -pn commands. Any replacement whether it be Chrony or ntimed would need to address this. Remote monitoring is an essential requirement, and compatibility with the installed base would be a huge advantage. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
On 16/02/2015 07:59, William Unruh wrote: [] ?? There are chonyc which is its own monitoring. chrony is not ntpd, so why would you expect ntpc monitoring commands to work? [] As I already said, compatibility with the installed base would greatly increase the acceptance on different software. Let's hope that ntimed is usable with Windows, otherwise it too will be out of the window. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
