[ntp:questions] leapseconds.list updates and ntpd
Either I have missed it, or it is not there. My question is 'does ntpd have to be restarted after a new leapseconds.list file has been downloaded?' Thanks, Walter ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] when change ntp servers, log print localhost: timed out, nothing received
When I change ntp servers by toish setobject cfg.ntp.servers 192.168.1.101 in linux, ntp server print logs localhost: timed out, nothing received, the ntp server change fails. Why is that ? Appreciate so much for your help. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leapseconds.list updates and ntpd
The doc http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14. says you have to, but it is describing a particular case where the config file is updated. If the file path directive is already there, would be a no brainer to add a check on the file now and again to see if it had changed. It seems an unnecessary constraint to have to restart ntpd in that case. I had a look at the source but see no indication that it can be dynamically updated. Le 10 févr. 2015 à 16:48, walter.preunin...@gmail.com a écrit : Either I have missed it, or it is not there. My question is 'does ntpd have to be restarted after a new leapseconds.list file has been downloaded?' Thanks, Walter ___ 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] NTP offset doesn't change.
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: However, when I wait for several minutes, the time can be adjusted to the right time. I couldn't see the gradual changes of offset. Is that normal? Assuming that you're using a minimalistic configuration: Yes. ntpd would take almost three months to *gradually* eliminate (slew) one hour of offset, so as soon as the offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it gave up all hope for the universe and just set the clock hard (step). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leapseconds.list updates and ntpd
walter.preunin...@gmail.com writes: Either I have missed it, or it is not there. My question is 'does ntpd have to be restarted after a new leapseconds.list file has been downloaded?' No. The code looks for an updated file (daily, I think, more often as we get closer to an expiration). See check_leap_file() in ntpd/ntp_util.c . H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leapseconds.list updates and ntpd
On 10/02/15 18:19, Harlan Stenn wrote: walter.preunin...@gmail.com writes: Either I have missed it, or it is not there. My question is 'does ntpd have to be restarted after a new leapseconds.list file has been downloaded?' No. The code looks for an updated file (daily, I think, more often as we get closer to an expiration). See check_leap_file() in ntpd/ntp_util.c . I've also experimented with using an ntpq :config command to force the daemon to re-read the leapseconds file, and that also seems to work. That is: strace shows that the daemon does indeed read the file upon receiving the :config command from ntpq, but I haven't verified anything beyond that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote: Hi, I'm using the ntpd to sync time. When I change the current date for exampe to 0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10 03:02, then I run ntpq -p for several times, the offset doesn't change at all. ntpd is not designed to handle deliberate tampering with the local time. Apparently many companies write acceptance test scenarios like setup ntp, then put a different time in the clock and see how ntp corrects it but this just isn't going to work. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 10/02/15 05:15, catherine.wei1...@gmail.com wrote: Hi, I'm using the ntpd to sync time. When I change the current date for exampe to 0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10 03:02, then I run ntpq -p for several times, the offset doesn't change at all. Garbage In Garbage Out. ntpd is intended in environments where time behaves like time. It should actually abort in the case you describe, as something has clearly broken so badly that it is no longer safer to try and discipline the clock. People often try this as a test, but it is not a valid test. Basically, up to a lower limit (default 128ms, but significantly increased by -x) ntpd will slew to correct. Above that limit, up to a second limit (which I seem to remember to be 10 minutes) it will wait about 15 minutes to confirm that it really is seeing a step change, then restart the initial synchronisation and step. Above the second limits, it should abort, except if you enable an option to allow one such step and it is the first one. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 2015-02-10 13:26, William Unruh wrote: However if this is the first time this running of ntpd has encountered this, eg at startup, if you use -x option it will jump the time even if the -g (panicGate) offset is 1000 sec. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
William Unruh wrote: On 2015-02-10, Jochen Bern jochen.b...@linworks.de wrote: On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: However, when I wait for several minutes, the time can be adjusted to the right time. I couldn't see the gradual changes of offset. Is that normal? Assuming that you're using a minimalistic configuration: Yes. ntpd would take almost three months to *gradually* eliminate (slew) one hour of offset, so as soon as the offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it gave up all hope for the universe and just set the clock hard (step). No. It only does that for offsets from Hades. The Ones from Hell, ntpd abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is 1000 sec) Ie, for 128ms, ntp will try to slew the clock ( at a max of 500PPM- as far as I can see a completely arbitrary limit Mills decided on decades The 500 ppm limit is not at all arbitrary! In fact, it was originally just 100 ppm, but when too many systems turned up with a system clock which was a bit too far out, Prof Mills redid the control loop to allow a 500 ppm range. It could have been a lot more, but the ultimate stability of the control loop is supposed to be better this way. My own control theory math was back around 1980, so I have forgotten most of it. :-( Terje ago). If 128ms but 1000s it will, after being sure that that is not just some measurement error, jump the time (ie infinite PPM) If 1000 it assumes something is very very very badly wrong, and aborts. However if this is the first time this running of ntpd has encountered this, eg at startup, if you use -x option it will jump the time even if the offset is 1000 sec. Regards, J. Bern -- - Terje.Mathisen at tmsw.no 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] leapseconds.list updates and ntpd
On 10/02/15 21:01, Brian Inglis wrote: Use ntpq -c rv to check the leap second file has been updated and a pending leap second recognized: $ ntpq -crv associd=0 status=0419 leap_none, sync_uhf_radio, 1 event, leap_armed, version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2), processor=x86, system=Windows, leap=00, stratum=1, precision=-21, rootdelay=0.000, rootdisp=0.455, refid=GPS, reftime=d884e05f.b1f7560d Tue, Feb 10 2015 19:54:07.695, clock=d884e06a.5c64e486 Tue, Feb 10 2015 19:54:18.360, peer=14134, tc=4, mintc=3, offset=0.033, frequency=0.900, sys_jitter=0.037, clk_jitter=0.019, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 I confirm that the ntpq method works. So impatient types who can't wait for the (reportedly daily) check mentioned by Harlan can use that to activate the new leapseconds file immediately and without restarting the daemon. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 2015-02-10, Jochen Bern jochen.b...@linworks.de wrote: On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: However, when I wait for several minutes, the time can be adjusted to the right time. I couldn't see the gradual changes of offset. Is that normal? Assuming that you're using a minimalistic configuration: Yes. ntpd would take almost three months to *gradually* eliminate (slew) one hour of offset, so as soon as the offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it gave up all hope for the universe and just set the clock hard (step). No. It only does that for offsets from Hades. The Ones from Hell, ntpd abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is 1000 sec) Ie, for 128ms, ntp will try to slew the clock ( at a max of 500PPM- as far as I can see a completely arbitrary limit Mills decided on decades ago). If 128ms but 1000s it will, after being sure that that is not just some measurement error, jump the time (ie infinite PPM) If 1000 it assumes something is very very very badly wrong, and aborts. However if this is the first time this running of ntpd has encountered this, eg at startup, if you use -x option it will jump the time even if the offset is 1000 sec. Regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leapseconds.list updates and ntpd
On 2015-02-10 10:51, Jan Ceuleers wrote: On 10/02/15 18:19, Harlan Stenn wrote: walter.preunin...@gmail.com writes: Either I have missed it, or it is not there. My question is 'does ntpd have to be restarted after a new leapseconds.list file has been downloaded?' No. The code looks for an updated file (daily, I think, more often as we get closer to an expiration). See check_leap_file() in ntpd/ntp_util.c . I've also experimented with using an ntpq :config command to force the daemon to re-read the leapseconds file, and that also seems to work. That is: strace shows that the daemon does indeed read the file upon receiving the :config command from ntpq, but I haven't verified anything beyond that. Use ntpq -c rv to check the leap second file has been updated and a pending leap second recognized: $ ntpq -crv associd=0 status=0419 leap_none, sync_uhf_radio, 1 event, leap_armed, version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2), processor=x86, system=Windows, leap=00, stratum=1, precision=-21, rootdelay=0.000, rootdisp=0.455, refid=GPS, reftime=d884e05f.b1f7560d Tue, Feb 10 2015 19:54:07.695, clock=d884e06a.5c64e486 Tue, Feb 10 2015 19:54:18.360, peer=14134, tc=4, mintc=3, offset=0.033, frequency=0.900, sys_jitter=0.037, clk_jitter=0.019, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 This is from previous Meinberg stable as new release does not recognize PPS. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Does ntpq have an equivalent to ntpdc's fudge command?
On Wednesday, February 11, 2015 at 2:57:28 PM UTC+8, catherin...@gmail.com wrote: On Monday, October 6, 2014 at 4:39:35 AM UTC+8, Rich Wales wrote: Does the ntpq program have an equivalent to ntpdc's fudge command? I know ntpdc is deprecated, and I understand ntpq is supposed to be able to do everything that ntpdc can do, but I simply can't find any way to set a reference clock's flags in ntpq. I want to be able to set flag1 in an ACTS refclock (in order to schedule an immediate dialup attempt). I know how to do this with ntpdc, but I haven't been able to find the corresponding command in ntpq. Rich Wales ri...@richw.org Hi, I also have a similar problem. In the newest ntp version 4.2.8p1, the ntpdc is deprecated, what can I do if I still want to use it? Since in our system, many ntpdc commands have been used. Can I resolve it by adding some configuration? Thank you. By the way, I'm using the 4.2.8p1, and when I use the command ntpdc -l. It prints out localhost time out, nothing received. Is this due to the depreciating of ntpdc? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Does ntpq have an equivalent to ntpdc's fudge command?
On Monday, October 6, 2014 at 4:39:35 AM UTC+8, Rich Wales wrote: Does the ntpq program have an equivalent to ntpdc's fudge command? I know ntpdc is deprecated, and I understand ntpq is supposed to be able to do everything that ntpdc can do, but I simply can't find any way to set a reference clock's flags in ntpq. I want to be able to set flag1 in an ACTS refclock (in order to schedule an immediate dialup attempt). I know how to do this with ntpdc, but I haven't been able to find the corresponding command in ntpq. Rich Wales ri...@richw.org Hi, I also have a similar problem. In the newest ntp version 4.2.8p1, the ntpdc is deprecated, what can I do if I still want to use it? Since in our system, many ntpdc commands have been used. Can I resolve it by adding some configuration? Thank you. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Does ntpq have an equivalent to ntpdc's fudge command?
On 11/02/15 07:57, catherine.wei1...@gmail.com wrote: Hi, I also have a similar problem. In the newest ntp version 4.2.8p1, the ntpdc is deprecated, what can I do if I still want to use it? Since in our system, many ntpdc commands have been used. Can I resolve it by adding some configuration? Thank you. The replacement is to use ntpq. Within ntpq you can issue :config commands. Pretty much anything that you can specify in the ntp.conf file can be specified this way. So for example: the experiment I did yesterday (discussed in another thread) was to use ntpq to force re-reading the leapseconds file. This was done by issuing the following within ntpq: :config leapfile /var/lib/ntp/leap-seconds.list Of course, as was the case with ntpdc, you will first have to specify a keyid and corresponding passwd. Note that ntpq uses the controlkey. Also, for the benefit of others who might be setting up keys for the first time, note that the permissions of the keys file are important; 600 works for me. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] when change ntp servers, log print localhost: timed out, nothing received
catherine.wei1...@gmail.com writes: When I change ntp servers by toish setobject cfg.ntp.servers 192.168.1.101 in linux, ntp server print logs localhost: timed out, nothing received, the ntp server change fails. Why is that ? Appreciate so much for your help. What sort of 'restrict' lines do you have in your ntp.conf file? I have no idea what toish ... does. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leapseconds.list updates and ntpd
Paul writes: On Tue, Feb 10, 2015 at 12:19 PM, Harlan Stenn st...@ntp.org wrote: No. The code looks for an updated file (daily, I think, more often as we get closer to an expiration). It checks every SECSPERDAY after start. I didn't notice any adjustments to the interval (leapf_timer) and the comment says daily. OK. SECSPREDAY is certainly daily. And we also check the leap file hourly if the leapfile will expire in less than a month. See check_leap_expiration() and the places that call it - its first argument is 1 if it's a daily check, 0 otherwise (an hourly check). -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
William Unruh writes: On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote: William Unruh wrote: No. It only does that for offsets from Hades. The Ones from Hell, ntpd abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is 1000 sec) Ie, for 128ms, ntp will try to slew the clock ( at a max of 500PPM- as far as I can see a completely arbitrary limit Mills decided on decades The 500 ppm limit is not at all arbitrary! In fact, it was originally just 100 ppm, but when too many systems turned up with a system clock which was a bit too far out, Prof Mills redid the control loop to allow a 500 ppm range. It could have been a lot more, but the ultimate stability of the control loop is supposed to be better this way. My own control theory math was back around 1980, so I have forgotten most of it. :-( As you state, it is arbitrary. Is not! Is so! ... If it can be changed from 100 to 500 after complaints, it indicates that the number was not picked to optimise anything. I'm not sure that logically follows... And as far as I can see, 500 or 5000 makes little difference to the control loop. Yes, it is harder for other systems to follow one with a large drift, but it is even harder to follow one that jumps, which is what we get now. So what's the difference between following a jump and following a system that applies changes faster than the 500ppm that NTP is designed for? And given that reality bites, what are the tradeoffs between re-synching after a step and slowly dealing with a know offset error? We're talking about choices, and the different effects of these choices. It's one thing if a system rarely steps. It's a bit different if those steps happen more frequently. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leapseconds.list updates and ntpd
On Tue, Feb 10, 2015 at 12:19 PM, Harlan Stenn st...@ntp.org wrote: No. The code looks for an updated file (daily, I think, more often as we get closer to an expiration). It checks every SECSPERDAY after start. I didn't notice any adjustments to the interval (leapf_timer) and the comment says daily. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 2015-02-10, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2015-02-10 13:26, William Unruh wrote: However if this is the first time this running of ntpd has encountered this, eg at startup, if you use -x option it will jump the time even if the -g (panicGate) Oops, you are perfectly correct. -x changes the threshold of how long it waits with an offset greater than 128ms befor jumping. offset is 1000 sec. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote: William Unruh wrote: On 2015-02-10, Jochen Bern jochen.b...@linworks.de wrote: On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: However, when I wait for several minutes, the time can be adjusted to the right time. I couldn't see the gradual changes of offset. Is that normal? Assuming that you're using a minimalistic configuration: Yes. ntpd would take almost three months to *gradually* eliminate (slew) one hour of offset, so as soon as the offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it gave up all hope for the universe and just set the clock hard (step). No. It only does that for offsets from Hades. The Ones from Hell, ntpd abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is 1000 sec) Ie, for 128ms, ntp will try to slew the clock ( at a max of 500PPM- as far as I can see a completely arbitrary limit Mills decided on decades The 500 ppm limit is not at all arbitrary! In fact, it was originally just 100 ppm, but when too many systems turned up with a system clock which was a bit too far out, Prof Mills redid the control loop to allow a 500 ppm range. It could have been a lot more, but the ultimate stability of the control loop is supposed to be better this way. My own control theory math was back around 1980, so I have forgotten most of it. :-( As you state, it is arbitrary. If it can be changed from 100 to 500 after complaints, it indicates that the number was not picked to optimise anything. And as far as I can see, 500 or 5000 makes little difference to the control loop. Yes, it is harder for other systems to follow one with a large drift, but it is even harder to follow one that jumps, which is what we get now. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
