Re: [ntp:questions] create charts
Hi there On 23/08/2020 14:10, Uwe Klein wrote: Anybody else getting "request received" from TheFork and a bunch of "undeliverable" from uscc.net for each posting to comp.protocols.time.ntp ? I got some canned replies from various help desks, including the fork's, claiming that I contacted them. On topic, something like this perhaps? http://www.sput.nl/ntpstats/ Uses bash, grep, awk and rrdtool. Regards, Rob ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Local Time NTP Server
Hi there On 24/08/2020 16:07, William Unruh wrote: It was renamed because UTC has nothing to do with Greenwich. For historical reasons, the time at Greenwich is the same as UTC. They are not perfectly identical. The difference is however less then one second; GMT is mean solar time. UTC is TAI (atomic time) + leap seconds. Regards, Rob ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Could some one help in pointing out the error here
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote: On Monday, March 2, 2015 at 5:27:12 PM UTC+8, Rob wrote: Harlan Stenn st...@ntp.org wrote: catherine.wei1...@gmail.com writes: When I start the ntpd process and disabled ntpd authentication using command: ntpd -a -g -n -c /etc/ntp.conf -l /tmp/ntp.log and then execute the command (eg): ntpq -c :config server 10.172.161.16 minpoll 3 maxpoll 4 burst it still asks for keyid and md5 password. Do you have a need to use that command? I have never used that. You can put the server in /etc/ntp.conf and use it. Hi Rob, I need to use the following commands in my system: :config server :config restrict ... :config unconfig ... Actually, the users of our system may use these through our platform, so we wrap these commands in the code. Thank you. Best Regards. Ok. Well, I have never seen a use for dynamic configuration so I cannot help you. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Could some one help in pointing out the error here
Harlan Stenn st...@ntp.org wrote: catherine.wei1...@gmail.com writes: When I start the ntpd process and disabled ntpd authentication using command: ntpd -a -g -n -c /etc/ntp.conf -l /tmp/ntp.log and then execute the command (eg): ntpq -c :config server 10.172.161.16 minpoll 3 maxpoll 4 burst it still asks for keyid and md5 password. Do you have a need to use that command? I have never used that. You can put the server in /etc/ntp.conf and use it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh un...@invalid.ca wrote: On 2015-02-19, Rob nom...@example.com wrote: Miroslav Lichvar mlich...@redhat.com 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] Pool server gone wild
Roger invalid@invalid.invalid wrote: On 20 Feb 2015 19:29:44 GMT, Rob nom...@example.com wrote: Why not just: pool pool.ntp.org That should be enough. I did have just one line pool uk.pool.ntp.org but the rogue Did I write pool uk.pool.ntp.org? I don't think so... No, you didn't. Did I say that you did? It is what I had in my ntp.conf. That is why I suggested you change that. The region-specific codes are a leftover from the early days. Later, a geo-aware DNS was added and this is no longer required. server didn't get dropped even after 27 hours. I included the uk to try to make sure that the servers were as local as possible. Without that they could be anywhere in Europe. No, the pool.ntp.org name selects the closests servers. Close enough when you consider the pool good enough. Experience tells me that IP addresses are selected on a regional basis, not a country basis. Sometimes they are all in the UK, but not always. For example, earlier today one of the servers that was offered using pool.ntp.org was in Hungary. Putting the country code in makes it more likely that the IP addresses are local. But why do you worry? It does not matter if they are in the UK or Hungary. It would matter if they are in Brazil or in Australia, but that is not what is happening. It looks like you have created your own problem. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh un...@invalid.ca wrote: On 2015-02-19, Rob nom...@example.com wrote: Miroslav Lichvar mlich...@redhat.com 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] Pool server gone wild
Roger invalid@invalid.invalid wrote: On 21 Feb 2015 07:54:50 GMT, Rob nom...@example.com wrote: It looks like you have created your own problem. What problem are you talking about? Your problem to get enough good servers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pool server gone wild
Roger invalid@invalid.invalid wrote: On 21 Feb 2015 10:52:40 GMT, Rob nom...@example.com wrote: Roger invalid@invalid.invalid wrote: On 21 Feb 2015 07:54:50 GMT, Rob nom...@example.com wrote: It looks like you have created your own problem. What problem are you talking about? Your problem to get enough good servers. When did I say that? I observed ntpd continuing to poll a server which was off by 100s of milliseconds. Are you saying that ntpd didn't drop the server because of not enough good servers? A quick eyeball of the relevant peerstats shows that ntpd was using at least six good servers plus the one that went wild. Methinks you've come to an opinion based on too little information. You started adding pool commands to add more and more servers, apparently because you believed there would be not enough to prune your bad server. I am amazed that you are using the NTP pool, while at the same time worrying about a bad server that is off by 100s of milliseconds, and then still not trust ntpd to reject it. The NTP pool is for people who want to sync there servers reasonably well, so the clock widget displays the right time when a human watches it. When you want guarantees, the NTP pool is not for you. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2015-02-21 01:00, Rob wrote:
William Unruh un...@invalid.ca wrote:
On 2015-02-19, Rob nom...@example.com wrote:
Miroslav Lichvar mlich...@redhat.com 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
William Unruh un...@invalid.ca 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] Pool server gone wild
Roger invalid@invalid.invalid wrote: http://www.pool.ntp.org/scores/90.155.73.34 How does one alert an operator that their server is sick? Checking back through my peerstats I see that last entry which was okay was 2015-02-16 15:08:56. There is no need. The pool system has sent a mail to the operator and when he apparently does not react it is not a problem because the server will have been removed from the pool anyway. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pool server gone wild
Roger invalid@invalid.invalid wrote: On Fri, 20 Feb 2015 12:45:54 +, Roger invalid@invalid.invalid wrote: After about 11 minutes it has dropped one, leaving 6 servers. I'll continue to monitor and report back. Just to recap, I now have this in my ntp.conf: pool 0.uk.pool.ntp.org pool 1.uk.pool.ntp.org pool 2.uk.pool.ntp.org pool 3.uk.pool.ntp.org Why not just: pool pool.ntp.org That should be enough. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] chrony as a server
William Unruh un...@invalid.ca 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
Miroslav Lichvar mlich...@redhat.com 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
Miroslav Lichvar mlich...@redhat.com 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
Miroslav Lichvar mlich...@redhat.com 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
Miroslav Lichvar mlich...@redhat.com 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
William Unruh un...@invalid.ca 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
David Woolley david@ex.djwhome.demon.invalid 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 mlich...@redhat.com 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
Miroslav Lichvar mlich...@redhat.com wrote: On Mon, Feb 16, 2015 at 03:30:52PM +, Rob wrote: Miroslav Lichvar mlich...@redhat.com 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
Miroslav Lichvar mlich...@redhat.com 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 mlich...@redhat.com 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
William Unruh un...@invalid.ca wrote: On 2015-02-15, Rob nom...@example.com 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 david-tay...@blueyonder.co.uk.invalid 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
Miroslav Lichvar mlich...@redhat.com 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
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
[ntp:questions] chrony as a server
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 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? 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] NTP offset doesn't change.
Terje Mathisen terje.mathi...@tmsw.no wrote: Charles Swiger wrote: On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote: However, what I observe is that the plots of the offset show the derivative of the environment temperature, which unfortunately cannot be controlled any better. I am considering to locate the crystal that is responsible for the timing and see if it could be ovenized or replaced by a more I've considered packing some insulation around the crystal, this would tend to stabilize (while also increasing) the temperature, but this would also be likely to reduce its lifetime, and the motherboard would probably conduct heat too well. That will only slow down the rate of change, and probably not much. We tend to have temperature cycles over 24h and this will not help. temperature-stable oscillator. However, one can argue that it could be fixed in software as well. ntpd could sense a changing drift and extrapolate it, if necessary helped by input from a temperature sensor. You're describing a TCXO; using a temperature sensor to compensate for thermal drift would gain perhaps a factor of 5 accuracy. It should be noted that this experiment has been tried out in real life a few times: It has always helped! Depending upon the (temperature) offset between the selected sensor and the crystal, you can see an order of magnitude improvement. We don't have any code like that in the ntpd reference code base, simply because it would be _very_ unportable. :-( I see in chrony there is a command to add temperature compensation, and it has a couple of parameters like the pseudo-file to read and the offset and gain. When just reading a file it is not very unportable, it may be that some systems do not provide that functionality but it will still compile. A more portable solution could extend this with the option of reading data from an external program or script. Linux provides access to onboard temperature sensors via files in /sys or /proc that can just be read by any file access function. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
William Unruh un...@invalid.ca wrote: No, that is a hardware solution. There are software solutions-- a termistor to meaure the temperature of the crystal ( or somethign nearby) which feeds that measurement to the OS. the revised ntp then reads the temperature, and corrects the drift rate as a function of that temperature. This means that the change in the ntpd drift rate does not only depend on the offset meaured but also on that temperature. Since it takes a while for a temperature to be reflected in the offset, this makes ntpd track the correct rate of the clock much more closely. Yes, factors of 5 are easy. Actually, I suspect that oneof the reasons that chrony does so much better than ntpd does in disciplining the clock ( 2-20 times better) is because it reacts to such temperature changes much more rapidly. It can do so because it keeps a memory of the drifts and offsets and can see changes much more quickly. It also does not throw away 85% of the measurements to correct round trip errors, so can also react faster because of that. After reading that chrony can now handle local PPS clocks, I viewed the recent chrony manual and I see that it has support for temperature compensation as well. Unfortunately it is not automatic so it will have to be calibrated and put in the configuration file. As described by others it would be possible to make it auto-calibrating and only save the results of the calibration like the drift that is also saved. Measuring the temperature is no problem, those systems have a couple of different temperature sensors (for ambient, board and CPU temperature) that can be used as an approximation. Maybe I try chrony. First I need to test it on my own system and see if it can be monitored similar to ntpd (readvar). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
David Lord sn...@lordynet.org wrote: Rob wrote: Terje Mathisen terje.mathi...@tmsw.no wrote: Charles Swiger wrote: On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote: However, what I observe is that the plots of the offset show the derivative of the environment temperature, which unfortunately cannot be controlled any better. I am considering to locate the crystal that is responsible for the timing and see if it could be ovenized or replaced by a more I've considered packing some insulation around the crystal, this would tend to stabilize (while also increasing) the temperature, but this would also be likely to reduce its lifetime, and the motherboard would probably conduct heat too well. That will only slow down the rate of change, and probably not much. We tend to have temperature cycles over 24h and this will not help. At least in my case on occasions the rate of change seems to be faster than the control loop can handle and offsets of my various pcs rather than being 300u rise to 10ms. Only a small reduction in rate of change would be required to avoid this. Thermostatic temperature control at the crystal or a stable external clock source would be better but more difficult to implement. It is not certain that this problem is caused by temperature, unless maybe you are running at 1024 second poll interval. When you want close tracking of the offset the first thing to do is set the maxpoll to 6. Otherwise the interval over which the excursions happen is much too large, and overshoots of both the original offset and the compensation happen. With maxpoll 6 and local ethernet reference I have no trouble keeping within 50us. With maxpoll 10 this is impossible. The systems with local PPS (which is configured with maxpoll 4 although this seems to be handled differently in recent versions) normally remain within 10us, temperature changes result in wobbles of 4-6 us. When temperature is constant, it is more like 1-2 us. So it should be possible to get better results when temperature changes are taken into account. ___ 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: Yes,I just tested it and found that the synchronization of NTP is really slow. That is because ntpd is not designed to correct arbitrary errors that you have applied externally. It is designed to lock to the correct time and stay locked to that (within a few milliseconds when you use the network, or within a few microseconds when you have a local reference). The typical acceptance test scenario of let's set the clock one hour wrong while the system is running and see that ntpd corrects it just is not going to work. Drop that test, it should not be on the test list for ntpd. When you need that test, use another product. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
Charles Swiger cswi...@mac.com wrote: On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote: But I see it has also been explained elsewhere in the thread: ntpd has a maximum on the momentary drift of 500ppm, no matter if it is static or dynamic or the sum of two. I think that is not warranted. Do you believe that a clock which loses or gains over a minute per day should be assumed to be trustworthy? Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz waves from the AC line will do better than that. While the power grid frequency fluctuates in the short term due to load with similar magnitude of error, the utilities make an effort to correct the time during non-peak hours with slew rates of 200 - 333 ppm so that AC synchronous clocks see 86400 seconds per day. That cannot be compared at all! The grid is locked to atomic clocks, a clock running on AC will on the average keep very good time. A computer clock is driven by a crystal and is not locked to anything until you use something like ntpd to lock it. The actual frequency of the crystal has some tolerance, and with today's race to the bottom in prices and quality one really cannot depend on the accuracy. For example, when I recently compared some soundcards (similar issue), a 100ppm error appears to be the norm, even though a crystal oscillator with some care should be within 10-20ppm. However, the just isn't any care anymore. I personally don't experience problems due to the 500ppm limit right now, but I would not preclude that it would happen to others, or to me in the future. There are also other problems with dealing with a variable drift. I know from observations that ntpd does not attempt to handle a changing drift, it only tries to lock in to the momentary drift and when that is changing, it keeps chasing the drift (resulting in an offset). chrony supposedly chases the short-term offset more aggressively than ntpd does, if that's what you prefer. Yes I would prefer that, but chrony does not support local references so it is useless to me. In practice a changing drift is often caused by changing temperature, and it would be better to take the first derivative into account as well. Certainly it is true that changing temperature will cause a change in crystal frequency, on the order of ppm's to tens of ppm's per 10 C temperature change. But if you're willing to tolerate over 500ppm systemic error, why worry about a second-order effect in the 10s of ppm's? Those two things are not related. I have some systems that I need to keep within a few microseconds (with PPS) and those do not have that 500ppm error (none of my systems do), they usually within about 30ppm. However, what I observe is that the plots of the offset show the derivative of the environment temperature, which unfortunately cannot be controlled any better. I am considering to locate the crystal that is responsible for the timing and see if it could be ovenized or replaced by a more temperature-stable oscillator. However, one can argue that it could be fixed in software as well. ntpd could sense a changing drift and extrapolate it, if necessary helped by input from a temperature sensor. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 12/02/2015 17:00, William Unruh wrote: [] This means that if you are using say a PPS source, which gives microsecond long term offset, it can take many hours to get there, even if you or I looking at the offsets could see that it is off by ms after the first few poll intervals. [] Almost all of my NTP servers were restarted today after downloading and compiling NTP 4.3.0. From the graphs plotting offset versus time: http://www.satsignal.eu/mrtg/performance_ntp.php it seems to me that for the PPS-drived devices, 10 microseconds offset was reached within a few minutes, and full stability within an hour (say within a couple of microseconds). Yes, it's not immediate, but it's not many hours that I see here. That is what I see here as well with 4.2.7/4.2.8 versions. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
Charles Swiger cswi...@mac.com wrote: However, what I observe is that the plots of the offset show the derivative of the environment temperature, which unfortunately cannot be controlled any better. I am considering to locate the crystal that is responsible for the timing and see if it could be ovenized or replaced by a more temperature-stable oscillator. However, one can argue that it could be fixed in software as well. ntpd could sense a changing drift and extrapolate it, if necessary helped by input from a temperature sensor. You're describing a TCXO; using a temperature sensor to compensate for thermal drift would gain perhaps a factor of 5 accuracy. A TCXO could be better than what is fixed as standard (these are HP Proliant and Dell servers), but note that when talking about microsecond accuracy it will be quite difficult to get a freerunning oscillator that does not gain a few microseconds per 5 minutes or so. So there will always be a need for compensation. (I would add a graph showing the offset when it would be possible on usenet) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2015-02-12 03:00, Rob wrote: catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote: Yes,I just tested it and found that the synchronization of NTP is really slow. That is because ntpd is not designed to correct arbitrary errors that you have applied externally. It is designed to lock to the correct time and stay locked to that (within a few milliseconds when you use the network, or within a few microseconds when you have a local reference). The typical acceptance test scenario of let's set the clock one hour wrong while the system is running and see that ntpd corrects it just is not going to work. Drop that test, it should not be on the test list for ntpd. When you need that test, use another product. The test should be: set the clock one hour wrong; start ntpd -g; measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC; Yes, that would work. But that was obviously not how it was tested and I have seen this kind of posting here many times. It is apparently a common (wrong) way of testing. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
William Unruh un...@invalid.ca wrote: On 2015-02-12, Rob nom...@example.com wrote: Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2015-02-12 03:00, Rob wrote: catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote: Yes,I just tested it and found that the synchronization of NTP is really slow. That is because ntpd is not designed to correct arbitrary errors that you have applied externally. It is designed to lock to the correct time and stay locked to that (within a few milliseconds when you use the network, or within a few microseconds when you have a local reference). The typical acceptance test scenario of let's set the clock one hour wrong while the system is running and see that ntpd corrects it just is not going to work. Drop that test, it should not be on the test list for ntpd. When you need that test, use another product. The test should be: set the clock one hour wrong; start ntpd -g; measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC; Yes, that would work. But that was obviously not how it was tested and I have seen this kind of posting here many times. It is apparently a common (wrong) way of testing. She never said how she tested it, so making assumptions and then blaming her on the basis of those assumptions is hardly fair. She did. It was written in the first post that the time on the system clock was manually changed by one hour and then the offset was monitored. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
Jochen Bern jochen.b...@linworks.de wrote: However, I've also seen hardware occasionally flip-flopping from -900 to +1100 and back, complete with the developers of the firmware blaming a bug in ntpd for failure to discipline *that*. Ok that is different, it is not a static drift. But I see it has also been explained elsewhere in the thread: ntpd has a maximum on the momentary drift of 500ppm, no matter if it is static or dynamic or the sum of two. I think that is not warranted. There are also other problems with dealing with a variable drift. I know from observations that ntpd does not attempt to handle a changing drift, it only tries to lock in to the momentary drift and when that is changing, it keeps chasing the drift (resulting in an offset). In practice a changing drift is often caused by changing temperature, and it would be better to take the first derivative into account as well. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
Terje Mathisen terje.mathi...@tmsw.no wrote: 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. I think it is hogwash. The static drift cannot have any influence on the stability of the control loop. A static drift is just a frequency error that is determined once and can then be forgotten about. What is important is the short-time changes in the drift, the unstability of the frequency. THAT can influence the control loopt. But that is not at all what NTP restricts. I can fully understand that ntpd cannot control a clock that is -500ppm now and +500ppm the next hour, but it should not have any problem controlling a clock that has a +5000ppm error that stays the same all the time. In fact, it is mostly the job of the kernel to do that. I remember that in the past sometimes a specific adjtime command was used to pre-configure a static error so that ntpd would not see it. No idea if this still works. Note that that carefully designed control loop does not even handle the derivative of the drift. When everything is stable the offset neatly wobbles around zero, but when there is a linear change in temperature that results in a linear change in drift, the control loop maintains a constant error (determined by the gain of the loop), it does not realize that it is handling a changing drift and pre-compensate for it. ___ 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] Shared PPS source/Multiple PPS sources
William Unruh un...@invalid.ca wrote: On 2015-02-07, Rob nom...@example.com wrote: walter.preunin...@gmail.com walter.preunin...@gmail.com wrote: Ok, so these questions might be off the wall. Is there any reason why I could not share the PPS output of say, my u-blox 7 GPS module on multiple computers? Would it be good or bad to peer these 2 systems with each other? We do that in our project to synchronize several systems to the same GPSDO accurately. We use surplus video distribution amplifiers because they neatly fit into this (BNC In/Out, correct levels). There also exist dedicated devices for this. Actually the biggest problem with this is that it takes time to service a gps interrupt. Thus the first pps to come in, or be serviced delays the servicing of the second interrupt. Thus the accuracy of the two GPS is very ( 10-20usec) different. (I call that very because a gps pps is capable of 1usec accuracy, so a factor of 10 worse is alot) No, the single PPS is fed to multiple systems that each service the interrupt at the same time. I presume you meant this followup to the multi PPS sources to a single system and then it is not true either, of course our systems have at least 4 cores and they can service multiple interrupts at the same time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Shared PPS source/Multiple PPS sources
walter.preunin...@gmail.com walter.preunin...@gmail.com wrote: Ok, so these questions might be off the wall. Is there any reason why I could not share the PPS output of say, my u-blox 7 GPS module on multiple computers? Would it be good or bad to peer these 2 systems with each other? We do that in our project to synchronize several systems to the same GPSDO accurately. We use surplus video distribution amplifiers because they neatly fit into this (BNC In/Out, correct levels). There also exist dedicated devices for this. On the opposite end of the spectrum, would it be reasonable to have a PPS output from said module on a computer, with a second PPS (from another GPS module) on that same computer? I have that here at home, but mainly for evaluation of the results of PPS. (comparing kernel-PPS to usermode-PPS etc) I'm not sure if that would bring much, aside of redundancy. The Chronodot/DS323X chips have 1 Hz sqaure wave output and they have +/- 2ppm. It seems that the ATOM clock driver could be used, but would it be better to write a driver specifically for this chip? A special driver is not required for PPS, but it may be that you need to write software to read the serial data when it is not supported by any of the drivers. I wrote one it a Datum GPSDO, and I just made an external daemon that writes the time info into SHM to be read by ntpd using the SHM driver, so I don't need to try to get my software merged with ntpd. And a side question: Is it the GPS module that calculates when the PPS goes active? Is this signal compensated for the time it takes the signal from the sats in the module, or on the SV? Yes, the module calculates the position and time fix from the signals of at least 4 SVs, and then outputs the PPS related to the calculated time. This is automatically compensated for the delay between the SV and the calculated position. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Shared PPS source/Multiple PPS sources
William Unruh un...@invalid.ca wrote: On 2015-02-07, David Woolley david@ex.djwhome.demon.invalid wrote: On 07/02/15 08:24, Rob wrote: And a side question: Is it the GPS module that calculates when the PPS goes active? Is this signal compensated for the time it takes the signal from the sats in the module, or on the SV? Yes, the module calculates the position and time fix from the signals of at least 4 SVs, and then outputs the PPS related to the calculated time. Which is the key to how GPS does the P. GPS receivers need to know where the satellites were when the signal was launched, and the orbits are specified in terms of the satellite times. It then has to work out, from the relative delay times, from at least four satellites, the current time and three spatial coordinates (four unknowns). I'm not sure it actually needs the time part of the solution (it probably does for detailed corrections) but that is going to drop out of solving for the spatial position. Some receivers allow you to feed in the current location, and then the receiver can use only one sattelite to determine the time That is actually just because they are single-channel receivers. I do have a GPSDO like that. It initially determines the position using 4 SV mode and after half an hour or so it switches down to 1 SV mode for just time and frequency. However, it does that because it has one of those ancient receiver modules that have only one physical receiver that is multiplexed over at most 8 SV. Modern receivers do not need to restrict themselves to 1 SV because they can receive multiple SV in parallel. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Only Garbage from Raw DCF
Andreas Mattheiss please.post@publicly.invalid wrote: Hi, Am Fri, 30 Jan 2015 21:01:43 + schrieb Rob: Note than an RS232 port usually works fine with just the 0 and +3..5v levels so you can directly connect the output to the RS232 line without MAX232. Nice try, but in my case it didn't work, the voltage was a bit too anemic, both from the DCF module and the DCF alarm clock. Actually - I've got it working now! I realized that the MAX232 has two CMOS-to-RS-232 channels, both inverting - I just connected the output of the first channel to the input of the second one, so that the signal just gets inverted. I threw a two-resistor voltage divider in between, since the RS-232 level would be a bit too high for the CMOS input. I now Note that the CMOS input also doesn't like negative voltages. It is a good idea to put a diode in the circuit as well, to clamp the negative voltage. get the right polarity, and after throwing a (surprisingly high) time1 fudge of 0.21 in I get a nice sync: This is normal. The second is defined by the leading edge of the pulse, and the interrupt from the UART comes in after the entire character has been received at 50 baud, which takes 10 bits or 10/50 second. The receiver circuit may introduce some delay as well. In my system the fudge is 0.222 highscreen [19:57] [~] # 8 ntpq -pn remote refid st t when poll reach delay offset jitter == 127.127.1.0 .LOCL. 5 l 1148 6400.0000.000 0.000 -178.209.53.202 196.80.165.212 3 u 98 128 377 69.804 -0.024 113.184 -157.161.57.2212.51.144.442 u 97 128 377 67.917 11.403 30.932 *82.197.188.130 162.23.41.10 2 u 94 128 377 68.9591.265 2.198 -130.60.204.10 130.60.205.7 4 u 101 128 377 50.7957.875 2.321 -127.127.8.0 .DCFa. 0 l 55 64 3770.000 -3.433 498.390 -217.147.223.78 194.242.34.149 2 u4 128 377 113.500 -20.066 3.497 +5.148.175.134 131.188.3.2222 u1 128 377 69.642 -0.008 0.728 +94.23.99.15494.23.99.153 3 u 96 128 377 60.134 11.205 2.849 -94.23.99.15594.23.99.153 3 u 97 128 377 59.191 12.619 1.441 All other references are from the ntp pools. Only remaining thing that bugs me is that the testdcf tool still won't give me a correct time code: highscreen [19:58] [/nonraid/build/ntp-4.2.8/parseutil] # 19 testdcf /dev/refclock-0 DCF77 monitor 4.10 - Copyright (C) 1993-2005, Frank Kardel RADMLSMinPHour..PMDay..DayMonthYearP RADMLS1248124P124812P1248121241248112481248P - #... *** INCOMPLETE / *** BAD FORMAT (invalid/parity) Maybe a matter of bitrot? It looks like you still have some missing pulses, probably due to local interference. This is a problem here as well, as you saw from my logfile posting. You also need to tweak the fudge a bit more so the DCF time is within a millisecond and is considered a candidate. Of course then you first need to find some really accurate references to tune it to. When doing that, please make sure you don't restart the ntp server more than once or twice a day, and let it stabilize. Otherwise you will end up hunting pending corrections and the time offsets will drift in all directions. I have a DCF-77 receiver and two different GPS receivers, that both output serial messages and PPS pulses. The result: remote refid st t when poll reach delay offset jitter == +GENERIC(0) .DCFa. 0 l 54 64 3770.000 -0.042 0.276 oPPS(0) .PPS.0 l6 16 3770.000 -0.001 0.002 xSHM(0) .GPS.0 l5 16 3770.0009.342 0.212 *SHM(1) .PPS.0 l4 16 3770.0000.003 0.001 xSHM(2) .DATM. 0 l3 16 3770.000 -2.483 1.646 (I also have a couple of network NTP sources that are not relevant to this topic) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Only Garbage from Raw DCF
Andreas Mattheiss please.post@publicly.invalid wrote: Hello, Am Fri, 30 Jan 2015 19:24:05 + schrieb Rob: No, it is the wrong way around. Your signal should be -3 most of the time, and pulse to +3 during the 100/200ms pulses. aaah - thanks for this. I'll see if i have a transistor lying around somewhere that i can press into service as an inverter. I'll report. Regards Andreas Note than an RS232 port usually works fine with just the 0 and +3..5v levels so you can directly connect the output to the RS232 line without MAX232. Those drivers are a good idea when you have a long wire, but are not really required when it is short. Also note that the DCF77 signal is very sensitive to noise from power supplies, CRT monitors, and sometimes TL lamps. Keep the receiver in a clean location. It is quite usual to have errors in the logfile: 30 Jan 21:37:00 ntpd[3410]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 13 bits 30 Jan 21:37:53 ntpd[3410]: parse: convert_rawdcf: parity check FAILED for ---#-##--#---#-Rs-2--1--p-2-81-P1---811-48P_? 30 Jan 21:38:14 ntpd[3410]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 13 bits 30 Jan 21:39:00 ntpd[3410]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 45 bits 30 Jan 21:46:15 ntpd[3410]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 28 bits 30 Jan 21:46:28 ntpd[3410]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 13 bits 30 Jan 22:00:34 ntpd[3410]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 34 bits ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Only Garbage from Raw DCF
Andreas Mattheiss please.post@publicly.invalid wrote: Hi, ok, let's go all technical ;-) I wanted to play around a bit, building a reference clock from a cheap DCF77 module (similar, but not identical to the infameous Conrad module). It basically churns out 100/200ms pulses. I was planning on using flavour 5 of the Type 8 module. I feed the signal from the module into a level converter, based on the MAX232. This has been done many times before, if I peruse success stories on the net. Alas, it won't work for me. I seem to get something out of pin 2 of my plug; I can stick a LED in and get a long on signal with 100/200ms gaps when connecting the LED one way, short 100/200ms bursts when swapping anode and cathode. This I think is correct, since logic-0 is +3V in RS-232 and logic-1 is -3V (the MAX232 already does inverting for me). No, it is the wrong way around. Your signal should be -3 most of the time, and pulse to +3 during the 100/200ms pulses. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM
Harlan Stenn st...@ntp.org wrote: Rob writes: Sander Smeenk ssme...@freshdot.net wrote: What is actually wrong with running ntpdate to initially sync a clock? Why is the ntpdate.exe binary provided when 'we' shouldnt use it? Keep in mind that i 'just want to get to seconds accuracy' before i start ntpd. The problem is that you give the clock an initial kick that ntpd does not know about, and it tends to have problems correcting that. This sometimes results in the problems you are seeing. This sounds like total BS to me. ntpd has no way of knowing what went on before it was started, and I'm not aware of anything on either Windows or Unix that would cause any applied immediate adjustment to have *any* residual affect on ntp. But perhaps you know something I don't - please say more. The problem is that ntpd believes that corrections it is applying are because of frequency errors in the clock, while in this case they are because of resets done externally. During the startup phase, bad things happen anyway (like touching the carefully determined and saved drift value), doing a couple of successive restarts makes it worse because adjtime effects accumulate in the kernel without knowledge of ntpd. Applying a fixed offset outside of ntpd makes it worse. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM
Sander Smeenk ssme...@freshdot.net wrote: Quoting Terje Mathisen (terje.mathi...@tmsw.no): a) You should not run ntpdate, instead you use the -q option to ntpd to handle any initial time steps. What is actually wrong with running ntpdate to initially sync a clock? Why is the ntpdate.exe binary provided when 'we' shouldnt use it? Keep in mind that i 'just want to get to seconds accuracy' before i start ntpd. The problem is that you give the clock an initial kick that ntpd does not know about, and it tends to have problems correcting that. This sometimes results in the problems you are seeing. b) All the delay/offset/jitter times are measured in ms, not seconds! I actually knew that. I made that mistake on this list before. However it is also not relevant to the issues i am experiencing. Wether it's microseconds or seconds, the jumps in offset/jitter are abnormal nonetheless. Well, 60ms is not that bad for a Windows system, and 60s would be very bad. So this actually makes a lot of difference. c) It seems that you have an ntp.drift file which contains 500! Indeed i did. That file was probably written by ntpd after the first run going completely haywire. I removed it from the configuration. No change to the issues i'm experiencing. Did you stop ntpd, then remove the file, then start ntpd again? Can you run ntpd on the host machine and simply setup the client OS to be timesynced to the host? I guess not. Linux VMs dont essentially need to run ntp to keep their time synced if they use the correct clock source (kvm_clock) and the host is properly configured, but i would have no clue if Windows is able to do such stuff, let alone how. :( Maybe it is already doing that, and the interference between the corrections by ntpd and by the VM host is the cause of the problem you are seeing. I know on VMware it works OK, but for Windows that OK is never nearly as good as for Linux. A Linux system will remain within a few ms, for Windows 60ms is not bad at all. Also not that on Linux, the more you poke it the more it starts to misbehave. I think ntpd feeds correction data into the kernel that it remembers in memory, but the kernel remembers it between boots. So when you kill and restart ntpd a few times, the pictures of ntpd and the kernel are very different, and ntpd starts to lose control of the correction loop. Maybe it can happen in Windows as well. So, don't restart ntpd more than once an hour or so when you are debugging. By using ntpdate, you are aggrevating this problem. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===2288611982837908707== Content-Type: multipart/signed; boundary===_Exmh_1421754685_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421754685_7720P Content-Type: text/plain; charset=us-ascii ... Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? It is not the resolution of the time tag that matters, but the accuracy at which it can be received by an asynchronous serial port. You will probably require fudge configuration to calibrate it to an existing known-good source to get within 1ms of true time. With PPS it should be easy to get within 10us without calibration. I don't know what your requirements are, so it is difficult to judge if what you have now is good enough. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
William Unruh un...@invalid.ca wrote: On 2015-01-20, George Ross g...@inf.ed.ac.uk wrote: --===2288611982837908707== Content-Type: multipart/signed; boundary===_Exmh_1421754685_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421754685_7720P Content-Type: text/plain; charset=us-ascii ... Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? ??? The question is not what the resolution of the time tag is. The question is how accurately you can get that time into your computer. It turns out that the device has a mode where you can SEND a pulse at a moment you decide and then the device RETURNS the timestamp of that pulse you sent in a serial message. Presumably you can take a nanosecond timestamp and change the output line as closest together as possible, then read the returned timestamp and compare the two. That is equivalent in precision to receiving a PPS pulse, maybe even better. (because you don't have interrupt latency issues, the only issue is how close the pulse moment can be to the reading of the system time) The Datum we use has that option too, but I never tried it. Maybe soon. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===6692172896629376392== Content-Type: multipart/signed; boundary===_Exmh_1421765608_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421765608_7720P Content-Type: text/plain; charset=us-ascii It is not the resolution of the time tag that matters, but the accuracy at which it can be received by an asynchronous serial port. Ah, no, the timeousness of reading the timestamp isn't relevant, provided only that the driver doesn't hammer on the clock unit too hard (which it doesn't; once a second would be absolutely fine, and polling is less frequent than that). All that matters is that the kernel can toggle the leading edge of the timestamp-request data line reliably enough, and that the driver's timestamps taken before and after the ioctl() don't have much jitter. We regularly see our unit's jitter around 0.001, and the offsets to other timeservers in the low numbers of microseconds. Ah, you send a line toggle to the unit to be timestamped and the result to be sent back. That can be very accurate, yes. I know this option is present in some Datum GPSDO units that I use. My experience with other Trimble models that use the TSIP protocol is that one requests a time packet and the result reflects the current time and is valid at some defined point in the message (e.g. the leading edge of the start bit, I remember the exact detail). In such a protocol it is difficult to get it entirely right without tweaking with fixed offsets. (because there is some delay between the start bit edge and the moment the UART issues an interrupt) In itself, PPS interfacing is not that difficult. Usually it is sufficient to connect the PPS output BNC directly to the DCD input of the serial port. The kernel can then lock directly to the PPS, and the serial messages are only used for date/time and status information. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===2115662771273679884== Content-Type: multipart/signed; boundary===_Exmh_1421661606_7734P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421661606_7734P Content-Type: text/plain; charset=us-ascii Shouldn't it show a 'o' rather than a '*' when it is locked to PPS in kernel mode? Ah, but it's not doing PPS. The driver waggles one of the control lines and the device transmits a timestamp in response. Ok... the Trimble Thunderbolt outputs PPS as well, so I thought one would use that. It will be much more accurate, but you probably don't require that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===8412338610136231777== Content-Type: multipart/signed; boundary===_Exmh_1421654265_8133P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421654265_8133P Content-Type: text/plain; charset=us-ascii Is there anyone with the prior experience in getting these older Trimble units to work? We've had a Trimble Acutime 2000 running since 2005, at two separate sites. As I recall we just plugged it in, ran the (Windows) configuration tool that came on the CD with it to check that it had a lock and that it was running in time sync mode, then connected up a Linux box, configured in the driver, and off it went. remote refid st t when poll reach delay offset jitter == *GPS_PALISADE(0) .GPS.0 l6 32 3770.0000.012 0.001 Shouldn't it show a 'o' rather than a '*' when it is locked to PPS in kernel mode? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote: William Unruh un...@invalid.ca wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. You are constantly confusing the officially defined UTC time with the implementation in computer operating systems seconds since 1-1-1970 UTC. That implementation neglects the presence of leap seconds. Therefore it has to introduce discontinuity. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
Oceanos Admin sysad...@cellmail.com wrote: Is there anyone with the prior experience in getting these older Trimble units to work? Most of the information dates back to the early 2000's or so. Our desire is to get away from using an external Internet based public NTP site to limit possible security issues. I think it will work with gpsd. At least try to experiment with that, as it provides much more debugging info and you can see what is working and what is not. Once you have a bit more experience with accessing the unit you can always decide if you want to stick with gpsd (in combination with ntpd) or again try to configure ntpd to directly access the Trimble. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!
Paul tik-...@bodosom.net wrote: On Thu, Jan 15, 2015 at 4:40 PM, Terje Mathisen terje.mathi...@tmsw.no wrote: Not in my msg, but in the subject of the entire thread. :-) I'm so used to nomail@example being wrong I had a knee-jerk reaction. My bad. You just can't stand being pointed at errors. When I point at an error, you are already in the I presume he is wrong mode and do are no longer able to think rationally. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!
Paul tik-...@bodosom.net wrote: By the way, you can't send mail to nom...@example.com. I'm sure being somewhat anonymous enables statements like Harlan has decided to keep us in the dark and feed us shit.. That was VERY TRUE on that topic!! He did not tell us what was wrong and he grossly overstated the impact and the measures to be taken. That was a very bad move. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!
Terje Mathisen terje.mathi...@tmsw.no wrote: http://linuxgizmos.com/tiny-fanless-mini-pc-runs-linux-on-quad-core-amd-soc/ This little guy starts at $129 and includes a serial port which should make it trivial to attach a Sure GPS board. With a dual or quad 64-bit CPU, both SATA and SD storage connectors and versions that support multiple Gbit/s Ethernet ports, it would seem to be a nice NTPD startum 1 server. First I would verify if it really runs to microsecond accuracy, at least when you require that. My experience with small computers running NTP synced to PPS that they have a tendency to be 1-3 magnitudes worse at timing stability, probably because of the lack of a sufficiently fast and accurate timing counter. Of course, it could still be good enough when you want to use it as a network time server. It wasn't good enough for my co-channeling software that requires the clock to be accurate within a few microseconds. Intel CPU driven 64-bit PC systems have no problem with that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!
Paul tik-...@bodosom.net wrote: On Thu, Jan 15, 2015 at 12:03 PM, Rob nom...@example.com wrote: Terje Mathisen terje.mathi...@tmsw.no wrote: it would seem to be a nice NTPD startum 1 server. Of course, it could still be good enough when you want to use it as a network time server. Which is what was suggested. After all this is an NTP list not a high resolution timing list. It was suggested as a high-perf NTP server and it could turn out that it does not perform at maximum performance for NTP. I achieve much better sync between Intel systems over ethernet than I have seen on some of those new tiny Linux boards. But it has to be evaluated. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Nice fanless high-perf NTP server: Fitlet!
Paul tik-...@bodosom.net wrote: On Thu, Jan 15, 2015 at 1:16 PM, Rob nom...@example.com wrote: It was suggested as a high-perf NTP server That string is not in the message. It's not a quote despite your quotation marks. It's in the subject, idiot! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: That is a translation from seconds to ymdhms. The problem is not there. it is in the UTC seconds. In UTC one second disappears after the leap second, but not before or during. Thus UTC seconds numbering is simply disconinuous (jumps back) . And it is that which is the problem, not the common name Thus one has 1435733999 then a second later 1435734000 then .9 seconds later 1435734000.9 and .1 seconds later 1435734000.0 It is that discontinuity in the utc seconds that causes the trouble. No, it is the inadvertent decision to use UTC as a monotonic clock that causes the trouble. When you look at the translation from UTC to local time there is a similar issue, twice a year at the start and end of DST. However, it does not cause real trouble because the UTC time ticks continuously and only the offset used in the translation changes. Similarly, when the internal computer clock would use TAI and that is then first translated to UTC using a leap second table and then to local time using a timezone/DST table, there would be no issue. Software that needs a mononotonic time would use the raw TAI clock, software that needs UTC would use the TAI-UTC translated clock, and end-user software would use the TAI-UTC-localtime translated clock. It is justifyable that UTC was used, given that there would be much too much overhead in the conversions using the above method at the time this decision was made, and the whole leap seconds thing was quite new then anyway. Also, a computer clock was not as accurate and not as critical a resource back then. But still it was this decision that now causes the problems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Mike S mi...@flatsurface.com wrote: On 1/11/2015 7:16 PM, William Unruh wrote: If that public source is responsible it will pass on to your system the fact that there is a leapsecond, and your system will stop for a second at the last second of June. A system which properly implements leap seconds will do no such thing. It will properly account for a minute with 61 seconds, and will tick from 23:59:59 to 23:59:60 then to 00:00:00. There is no stopping, or any other discontinuity. Last time a lot of systems stopped (crashed) at that time... It can be discussed whether that was a proper implementation. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
brian utterback brian.utterb...@oracle.com wrote: On 1/11/2015 4:56 PM, Rob wrote: Michael Moroney moro...@world.std.spaamtrap.com wrote: If I have a system synchronized with a public NTP source, which is synchronized with an atomic clock that provides leap second info, and I am watching carefully, what will happen when the leap second hits? Will my system suddenly find its clock off by 1 second and slowly drift to the accurate time provided by the NTP server? That depends on what kind of system it is. Carefully designed systems will do the right thing. Define the right thing. To eloaborate, there is no right thing. There are a whole bunch of things that are right for some people and not for others. That is the very reason that there isn't a right thing, because if there was one right thing all the vendors would have fixed their operating systems to do it. the right thing is to jump over this leap second by inserting a 60'th second in the minute at midnight UTC. Of course there are several problems caused by inadvertent decisions in the past (e.g. to let the Unix clock tick UTC seconds instead of TAI seconds), but it is for the OS designers to decide how to work around that problem and communicate it to their application and subsystem designers so they can live with it. However, I don't believe in an urge of operating systems vendors to do things right. Operating systems do what makes them money, even when the resulting functionality is sub-optimal. Keeping accurate and consistent time certainly is not high on their list of priorities. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Michael Moroney moro...@world.std.spaamtrap.com wrote: Rob nom...@example.com writes: Michael Moroney moro...@world.std.spaamtrap.com wrote: If I have a system synchronized with a public NTP source, which is synchronized with an atomic clock that provides leap second info, and I am watching carefully, what will happen when the leap second hits? Will my system suddenly find its clock off by 1 second and slowly drift to the accurate time provided by the NTP server? That depends on what kind of system it is. Carefully designed systems will do the right thing. I was wondering if there was a predefined right thing used by ntpd for dealing with leap seconds. The system I am thinking about (OpenVMS) is probably unfamiliar with others here. It uses Unix code (ntp 4.2.something) as a base for its NTP server. Internally, its clock is based on the number of nanoseconds since a base date. It is impossible for it to represent an internal time of 23:59:60. Conversion of such a time from ascii to the internal format will result in an error. This is typical for computer systems. The designers did not take leap seconds into account, and the only ways for it to deal with them are to change the base date or to fuzz with the real time counter. The reprsentation isssue is normally not that important, because it only occurs during one second. However, the way it handles the concealment of that extra second may be important to programs that expect a contiguous time scale. Consult your reference manuals to see how it is done. It is not done by NTP but by the OS kernel. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Martin Burnicki martin.burni...@meinberg.de wrote: Rob schrieb: Mike S mi...@flatsurface.com wrote: On 1/11/2015 7:16 PM, William Unruh wrote: If that public source is responsible it will pass on to your system the fact that there is a leapsecond, and your system will stop for a second at the last second of June. A system which properly implements leap seconds will do no such thing. It will properly account for a minute with 61 seconds, and will tick from 23:59:59 to 23:59:60 then to 00:00:00. There is no stopping, or any other discontinuity. Last time a lot of systems stopped (crashed) at that time... It can be discussed whether that was a proper implementation. You can't compare bugs in an implementation with implementations which work as designed, even if the design goals may differ and different goals may meet different expectations. Of course... it was meant to be a wink. In fact, none of my systems have ever crashed because of this, but it happened to others. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: So, there are a bunch of proposals. stop the clock a la Mills (delivering times that always increase but very very slowly during that second). double the rate of the clock during the two seconds around the leap. Have the clock run in TAI and put the leapsecond handling into the conversion code. Make the clock run faster, but not twice as fast, during a period around the leap second. Are any of these the right thing? No, the right thing is to let the clock tick in TAI and not to touch it, and have the conversion routines handle the changing offset just like they handle UTC to local time conversion right now. The conversion code uses a table that gets a new entry every couple of years, that defines a TAI #seconds where the conversion to human readable time inserts an extra second. Just like at certain points in time it inserts or deletes 3600 seconds to achieve proper local DST. When the code is suitably advanced, at that leap second moment it can display a time like 23:59:60. But that is not really important, it can display 23:59:59 or 00:00:00 for 2 seconds when that is easier. What is important is that the leap second is hidden in the conversion, while the TAI time (in nanoseconds in the case of VMS) just increases monotonically. So any applications using it for timestamping and sequencing don't experience hickups. Alas, the above design was not chosen in systems like Unix and VMS, and now the correct behaviour has to be achieved using kludges. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP 4.2.8 for Windows, not branded
William Unruh un...@invalid.ca wrote: On 2015-01-10, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2015-01-09, trackeroft...@gmail.com trackeroft...@gmail.com wrote: What do you mean It is branded? And why is that a problem? Hello William, 1. The installer is branded: http://www.satsignal.eu/ntp/setup.html I still have no idea what you are talking about. Meinberg, a company, makes available for free a version of ntp compiled to run on Windows. What is branded about that? branded means that the name and/or logo of that company/brand appears on the screen during the installation phase and maybe later is left in some files on the system. And this is a problem why? Not for me to determine. The OP posted this as a problem. You asked what it is branded means, and I explained. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Michael Moroney moro...@world.std.spaamtrap.com wrote: If I have a system synchronized with a public NTP source, which is synchronized with an atomic clock that provides leap second info, and I am watching carefully, what will happen when the leap second hits? Will my system suddenly find its clock off by 1 second and slowly drift to the accurate time provided by the NTP server? That depends on what kind of system it is. Carefully designed systems will do the right thing. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP 4.2.8 for Windows, not branded
William Unruh un...@invalid.ca wrote: On 2015-01-09, trackeroft...@gmail.com trackeroft...@gmail.com wrote: What do you mean It is branded? And why is that a problem? Hello William, 1. The installer is branded: http://www.satsignal.eu/ntp/setup.html I still have no idea what you are talking about. Meinberg, a company, makes available for free a version of ntp compiled to run on Windows. What is branded about that? branded means that the name and/or logo of that company/brand appears on the screen during the installation phase and maybe later is left in some files on the system. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
Harlan Stenn st...@ntp.org wrote: Martin Burnicki writes: Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: And of course, the information flow was really bad here, so that it is very hard to figure out which systems are affected. Indeed. Only after 3 days there was a statement on the pool mailing list that the problem only affected servers that can be queried. Well, that had better be stated in the original release, so that 99.9% of the users of ntpd could immediately move it to not for me and not be worried. Yes. I agree that this information should have been available immediately with the first alert. This would have avoided much trouble. And if we had realized all of this at first alert we would have. The announcement came out 3 days' later than I wanted. I'd been working on this for 2 solid weeks by then. Yes, I agree it would be very convenient when you had insight in programming so you could work out things like that more efficiently. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Restrict statements and the pool directive
David Woolley david@ex.djwhome.demon.invalid wrote: On 21/12/14 20:10, Rob wrote: What I got from the documentation is that without nopeer a server could setup a peer association. I don't like that. No. Without nopeer, a *client* can't set up a peer session. If you are using a system as a server, it cannot cause you more disruption than if it peered itself with you. The problem here is that the exact significance of being a peer isn't well documented. Exactly. The description in the documentation is unreadable. There is no plain language paragraph after the initial definition that must be in terminology explained elswhere, but has no pointer to there. Until it is, I appears to be better to not use the functionality. After 3 days of finding out how to install updates and where to get updated source, Harlan finally stated on the Pool list: If you have been following BCP and only allow 'query' from trusted hosts you are protected from these attacks. Was it really that hard to write that in the initial publication??? After all, it turned out to be completely unnecessary to update. And with that, everyone would have avoided to run into an issue like this and the matter could have been studied beforehand. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
Martin Burnicki martin.burni...@meinberg.de wrote: Rob schrieb: David Woolley david@ex.djwhome.demon.invalid wrote: On 21/12/14 10:48, Rob wrote: People say disable crypto but there is no clear direction in the docs on how to do that. There is no crypto off or disable crypto config directive at first glance. So how is this done? I would assume by not enabling it. Ok, but in that case why the worry about the millions of vulnerable servers on the internet, I think most users who just want to get and serve time don't spend the week of time needed to get the crypto working and to coordinate with other servers doing the same. I think this is because they just didn't understand in which cases these vulnerabilities can be exploited. And of course, the information flow was really bad here, so that it is very hard to figure out which systems are affected. Indeed. Only after 3 days there was a statement on the pool mailing list that the problem only affected servers that can be queried. Well, that had better be stated in the original release, so that 99.9% of the users of ntpd could immediately move it to not for me and not be worried. So for now I presume it is on by default... also because of what I saw in the OpenSUSE example config. (or would the keys config directive be the magic enable crypto directive?) Unfortunately openSUSE has (symmetric keys) crypto enabled to be able to change ntpd's configuration at runtime via ntpq and/or ntpdc commands. E.g. if the dhcp client receives a DHCP option with the IP of an an NTP server it configures ntpd dynamically to use this server. Ok, I always immediately cut out such behaviour after installing a system. I don't want DHCP to modify my NTP settings, or to restart ntpd. (of course the neat thing about the above solution is that it is not required to restart ntpd. in Debian, for example, ntpd is restarted when a DHCP lease with changed ntp option is received) I was amazed to see that when updating ntpd from the OpenSUSE update, the last part of ntp.conf which I commented-out was appended again by the update script. So I removed it again. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
Martin Burnicki martin.burni...@meinberg.de wrote: I don't want DHCP to modify my NTP settings, or to restart ntpd. (of course the neat thing about the above solution is that it is not required to restart ntpd. in Debian, for example, ntpd is restarted when a DHCP lease with changed ntp option is received) For standard deployments on a huge number of clients the DHCP way very much simplifies installation since you only have to configure the DHCP server. On the other hand, it would be good if there was a simple (easy-to-find) switch where you could disable such automatics. Of course DHCP in itself is great, and I like it when devices (and maybe workstations) automatically obtain the local timeserver address. But what I DON'T like is when my carefully configured NTP server with local refclock and configured secondary servers is turned into a client of itself or another local system. I agree that the enable/disable of this feature is often absent or very hard to find. Often you have to edit /etc/dhclient.conf or just remove some script from /etc/dhclient.d but it is dangerous because it may re-appear after a security update. A simple NTP_USE_DHCP=yes that you can set to no when desired in /etc/sysconfig/ntp or /etc/default/ntp would be so much better... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
David Woolley david@ex.djwhome.demon.invalid wrote: On 20/12/14 22:01, Rob wrote: David Woolley david@ex.djwhome.demon.invalid wrote: On 20/12/14 19:58, William Unruh wrote: Is it an ntp packet (ie a time exchange packet)? is it a control packet (eg ntpq type packet?) or what? Ie, unless you use crypto, these two look like they might be dangerous. Both routines only process NTP type 6 packets, i.e. nptq. But is that before or after those packets are filtered by restrict? ctl_putdata is sending the response (my guess is the attack is monlist based), so it is definitely after the filter. configure is a fairly complex command processing option, so, although I didn't check the code in detail, I would be most surprised if it wasn't after the filter. Looking in the packet trace I see monlist attempts all the time, but they are probably for the previous NTP issue. I have restricted those, but I feel unsure if I am vulnerable to the current problem. People say disable crypto but there is no clear direction in the docs on how to do that. There is no crypto off or disable crypto config directive at first glance. So how is this done? Again, the users are left in the dark. There no default config file, so all distributions make their own. My OpenSUSE system includes: # # Authentication stuff # keys /etc/ntp.keys # path for keys file trustedkey 1# define trusted keys requestkey 1# key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables I have commented those all. But there is no such thing in the Debian config file. Is crypto off by default? I don't think so, because there is no crypto statement in the OpenSUSE config file, yet it refers to crypto-related settings. How much simplere would it be when there was a news release telling us what we need to config in our /etc/ntp.conf or what we need to trap in the firewall. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Restrict statements and the pool directive
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: I just added some experimental restrict statements to one on my servers: restrict default notrap nomodify nopeer noquery restrict default notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 restrict 192.168.0.0 mask 255.255.255.0 peer and it now seems that the pool directive is not finding any pool servers even after a few minutes running. Is this related? If so, how might I fix the problem? Yes, that is related. I encountered this when I tried the pool command. You need to lift restrict on the pool servers, but I forgot how to do that exactly, I just removed the pool command. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
David Woolley david@ex.djwhome.demon.invalid wrote: On 21/12/14 10:48, Rob wrote: People say disable crypto but there is no clear direction in the docs on how to do that. There is no crypto off or disable crypto config directive at first glance. So how is this done? I would assume by not enabling it. Ok, but in that case why the worry about the millions of vulnerable servers on the internet, I think most users who just want to get and serve time don't spend the week of time needed to get the crypto working and to coordinate with other servers doing the same. So for now I presume it is on by default... also because of what I saw in the OpenSUSE example config. (or would the keys config directive be the magic enable crypto directive?) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Restrict statements and the pool directive
Terje Mathisen terje.mathi...@tmsw.no wrote: Rob wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: I just added some experimental restrict statements to one on my servers: restrict default notrap nomodify nopeer noquery restrict default notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 restrict 192.168.0.0 mask 255.255.255.0 peer and it now seems that the pool directive is not finding any pool servers even after a few minutes running. Is this related? If so, how might I fix the problem? Yes, that is related. I encountered this when I tried the pool command. You need to lift restrict on the pool servers, but I forgot how to do that exactly, I just removed the pool command. 'restrict source' is the proper way to do it, as long as you have a version which supports that command. Terje Ok, I remember now (a quick google did not find it, indicative of the state the documentation is in... many many sites copied old documentation to their pages, so googling quickly sends you nowhere). Anyway, I consider it a bug. I don't want to lift restrictions to arbitrary systems selected from a pool. So, out went the pool command. Fortunately, server pool.ntp.org still works. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Restrict statements and the pool directive
David Woolley david@ex.djwhome.demon.invalid wrote: On 21/12/14 11:24, Rob wrote: Anyway, I consider it a bug. I don't want to lift restrictions to arbitrary systems selected from a pool. So, out went the pool command. Why do you want to specify pool servers if you want to restrict their use so that you cannot use them? When people say lift restrictions here, they mean lift those which prevent the use as a server, not lift all restrictions. Unless you hare using a blunderbuss approach to restrictions, or using ignore you should not be blocking the access needed to act as a client. No, I want to have restrictions for everyone outside like this: restrict default notrap nomodify nopeer noquery That means I don't accept that anyone outside does something that may modify my server (including setting up a peer relationship). That does not preclude the use of an outside server, or the outside use of my server as a reference. Now, when using the pool command, those outside servers that are working perfectly fine with the server command suddenly don't work, as the original poster already described. But why? There is nothing different between using a server via server or via pool, so why would there be differences in required restrictions? It appears to be because of use of existing code that happens to check the restrict. I.e., it is a bug. I think the original question on this thread is much more likely to be due to a DNS problem than one in using restrict, as I cannot see anything in those restrictions which would prevent client access to the pool. Yes, that is the problem! You cannot see anything there, the problem is in the code. And it worked ok in older versions, so people are surprised when they (forcibly...) upgrade their ntpd and are suddenly faced with this problem. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
David Woolley david@ex.djwhome.demon.invalid wrote: Paranoia? Security alerts are generally not that explicit (and this one is actually unusually explicit) because they provide information to the hackers. That is usually obtained anyway be reverse-engineering the fix. In this case that is more difficult because an entire new release was pushed out as a fix. There are only two places where crypto_recv is called. One is definitely only active if autokey has been explicitly configured. The other is only active for broadcast clients and the comments imply that it is only used for autokey, but it does seem possible that it is the remote side that decides this (I didn't follow the code any deeper); it is in the initial broadcast client handshake. Ok that should make servers on internet less vulnerable. Maybe an attack can be done on a local network but I am not worried about that. I'm using 4.2.7p333, rather than the latest 4.2.7 source code. Most interesting is of course the situation in 4.2.6p5 In 4.2.7 there are already changes that may have partly fixed this. Carefully crafted in alerts generally means that the data has to look like the address of some instructions and those instructions, with the exact memory layout under which that instance is running. It also normally assumes that the machine doesn't have stack execution permission disabled for ntpd. Of course I run ntpd as a dedicated user ntp and in a chroot. That should also limit the impact. This is default on OpenSUSE. I think in Debian the separate user is default but the chroot isn't. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Restrict statements and the pool directive
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 21/12/2014 11:17, Terje Mathisen wrote: [] 'restrict source' is the proper way to do it, as long as you have a version which supports that command. Terje Thanks, Rob Terje, that did the job. Almost! The except was that if you have a local node defined as a server, and you want that node to be able to issue ntpq commands, it seems that the configuration I suggested blocks this, even adding query to the 192.168.0.0 line: restrict default notrap nomodify nopeer noquery restrict 192.168.0.0 mask 255.255.255.0 peer query so I needed to make it: restrict default notrap nomodify nopeer query restrict 192.168.0.0 mask 255.255.255.0 peer Perhaps I did something wrong? Yes, when you want to allow things to the local system you need to add: restrict 127.0.0.1 restrict ::1 These systems are unlikely to be connected as Internet-facing servers, so it more a learning exercise for me, but I need to know what to recommend to others. At least do not recommend others to set default to anything else than restrict default notrap nomodify nopeer noquery Allowing query on an external system was common practice until the undesired folks on the internet found how they could abuse this to attack others. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
Jochen Bern jochen.b...@linworks.de wrote: As far as I'm concerned, 0.66 * -9295 is enough for me to grab the backports from the repos for our outward-serving ntpds right now ... Yes, for most systems I did the same, but I have the development version of ntpd running on a couple of systems, and I have to either wait for them to update the debian package on the ntp.org development server (which may never happen) or to get and compile a raw tarball myself. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Restrict statements and the pool directive
Paul tik-...@bodosom.net wrote: On Sun, Dec 21, 2014 at 7:04 AM, Rob nom...@example.com wrote: That means I don't accept that anyone outside does something that may modify my server (including setting up a peer relationship). If you actually think the software is so badly designed that it would allow this you should stop using it. Or you could read the documentation. The documentation is very difficult to read. I better spend my time on other things. Or even ask: will using 'restrict source noquery notrap nomodify' allow pool servers to modify my server? What I got from the documentation is that without nopeer a server could setup a peer association. I don't like that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
A C agcarver+...@acarver.net wrote: I saw the advisory about the potential issues in ntpd before 4.2.8 but I don't quite understand whether it affects a pure client (not serving time to the outside) or not. If the issue does affect client-only operation, what can be done for systems that can't be upgraded? Harlan has decided to keep us in the dark and feed us shit. On the pool list someone asks what can be done to temporarily work around the problem, and he does not even understand the question. Is babbling about needing money again, too. Arghhh. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
David Woolley david@ex.djwhome.demon.invalid wrote: On 20/12/14 19:58, William Unruh wrote: Is it an ntp packet (ie a time exchange packet)? is it a control packet (eg ntpq type packet?) or what? Ie, unless you use crypto, these two look like they might be dangerous. Both routines only process NTP type 6 packets, i.e. nptq. But is that before or after those packets are filtered by restrict? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP PPS, part 2 ;)
Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Paul writes: On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki martin.burni...@meinberg.de wrote: OK, but what is the problem in using these IOCTLs directly from withi n ntpd, via wrapper functions or directly? Several refclock drivers do so. You'll have to ask Harlan. Useful discussion and patches would be nice. The code does not have to be patched because it already works, you only need to move the timepps.h file into the distributed source. It provides the wrapper functions between the existing refclocks and the IOCTLs. Since you don't see my POV and I've looked at yours several times and always see how doing what you suggest will cause horrible headaches and problem, something else will have to shift. When you really think that doing the above will cause headaches, then the direct use of IOCTLs will do even more so. With my solution you can at least update the timepps.h file in the case there would be a change in the IOCTLs, when you access those directly you will have to solve the problem yourself. Please post a copy of this timepps.h file that will work for all versions of all OSes that are running NTP. Harlan, I suggest that you drown yourself in your releng pool and stop thinking about coding or improving ntpd. You clearly are incapable of doing any productive work on coding. Small wonder that you are always after money to hire people. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP PPS, part 2 ;)
Martin Burnicki martin.burni...@meinberg.de wrote: Without having looked at the code base, I'm sure there are already predefined macros available for the current build target/architecture. So it should not be a problem to include something like #if defined( SOLARIS ) #include timepps_solaris.h #elif defined ( SCO ) #include timepps_sco.h #elif defined ( LINUX ) || defined( FREEBSD ) #include timepps.h #endif If this piece of code is required more than once it should be put into a common header file which is included in all places where this is required. No duplicate code. Martin The above is already there in the code, Martin. The only point is that these timepps-SunOS.h, timepps-SCO.h and timepps-Solaris.h files are included but the Linux version is not. But we better stop discussing with Harlan. He is a manager type that knows zilch about the code yet always is commenting on the proposed changes. He wants money to hire people, of course because he cannot get volunteers to work under his management. Pity that the ntp project has a character like that involved. We better lose him. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: The main problem is that the underlying system time (often POSIX, which just counts seconds since an epoch) has the *same* time stamp art the beginning and end of the leap second. In order to do the conversion correctly you need to know if the current second is the leap second, or not, i.e. you need some status flag in addition to the raw (e.g. POSIX) timestamp. This is basically similar to what you have at the end of DST, where (in local time) a whole hour is passed twice. You need to know the DST status to determine unambiguously if it's the first or the second turn. Yes, but in situations where you care about that you store just the system time, and the conversion to local time can be repeated later. Thanks to the powerful conversion routines in glibc this can be done even way in the past (because it remembers DST rules from previous years). Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. A main reason for the problems with leap seconds is that POSIX has just ignored them when they defined their standards on timekeeping. That is the problem. And probably also the decision in Unix to count UTC seconds since Jan 1st, 1970 (instead of TAI seconds). Back then it did not matter that much in a timesharing system. The system clock was mainly a convenience feature, not critical to anything. (it usually had to be set on every boot and this was done by typing the time seen on the operator's wristwatch, hence the term wristwatch time) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: Imagine you set up an event for April 2015 today, but you just don't know if DST will be in effect at that time, or not, just because the politicians haven't made the decision today. How will you handle this? It may not be helpful if you get updated DST rules the day *after* the scheduled event. On the other hand, when the event time approaches and you have the chance to get a DST rule update before the event time everything may be fine, if a decision is taken either to keep the UTC time *or* the local time for this event. Since UTC is actually used in most computers to keep the system time and schedule events based on an accurate UTC time it may not be helpful to do this with post-processing. It depends on what kind of event it is. When it is a human event like a meeting, it is customary to plan these events in local time. So they should be stored in local time with a specified timezone. What UTC time this is will depend on the local time rules at the actual event time. It will still be tricky when you plan a meeting at 02:30 on the sunday of the DST change from summer-winter time. You cannot add a DST flag with the event because you cannot know if there will be a DST change at that time. Of course that is why the DST change is done at a moment where such problems are unlikely, and not for example at 12:00 on the first day of the month. Some calendering software gets this wrong, yes. E.g. by converting the specified local time to UTC time and storing that. This has caused problems in the past for well-known calendering software, I don't know if that has been fixed. For technical events it may be different, and storing them at the UTC time could be better. But scheduling software (Windows Scheduler, Unix cron) usually uses local time as well. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: Unfortunately, the same mechanism isn't used for leap seconds. There would be no problem at all when the system time ticked in TAI and the addition of the leap seconds is done via some rule table similar to the local time rules. ntpd would not even be involved in the problem. Also agreed. However, actually ntpd expects UTC, not TAI. Of course it is a hypothetical situation. When the Unix developers would have had the foresight to define their clock in TAI rather than UTC, the NTP designer probably would have used TAI as well, and instead of the leap second handling there maybe would have been some field to broadcast the current UTC-TAI offset. GPS actually does it that way. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: IMO the GPS system designers have made quite a number of wise decisions, e.g. letting the GPS time simply increase monotonically, which is, from a technical/usage point of view, similar to TAI. That decision was wise. The decision to express date in weeks and put it in a 10-bit field was not so wise. Oh well. AFAIK the GLONASS satellites use UTC instead, which causes an interruption in the sequence of data frames whenever a leap second occurs. I think GLONASS uses Moscow local time. I read that Galileo also has its own time scale (GST) synchronized to TAI and it broadcasts the time offset to GPS time expressed in nanoseconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP PPS, part 2 ;)
Harlan Stenn st...@ntp.org wrote: Paul writes: On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki martin.burni...@meinberg.de wrote: OK, but what is the problem in using these IOCTLs directly from within ntpd, via wrapper functions or directly? Several refclock drivers do so. You'll have to ask Harlan. Useful discussion and patches would be nice. The code does not have to be patched because it already works, you only need to move the timepps.h file into the distributed source. It provides the wrapper functions between the existing refclocks and the IOCTLs. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP PPS, part 2 ;)
Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Paul writes: On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki martin.burni...@meinberg.de wrote: OK, but what is the problem in using these IOCTLs directly from within ntpd, via wrapper functions or directly? Several refclock drivers do so. You'll have to ask Harlan. Useful discussion and patches would be nice. The code does not have to be patched because it already works, you only need to move the timepps.h file into the distributed source. It provides the wrapper functions between the existing refclocks and the IOCTLs. Since you don't see my POV and I've looked at yours several times and always see how doing what you suggest will cause horrible headaches and problem, something else will have to shift. When you really think that doing the above will cause headaches, then the direct use of IOCTLs will do even more so. With my solution you can at least update the timepps.h file in the case there would be a change in the IOCTLs, when you access those directly you will have to solve the problem yourself. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Martin Burnicki martin.burni...@meinberg.de wrote: Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: IMO the GPS system designers have made quite a number of wise decisions, e.g. letting the GPS time simply increase monotonically, which is, from a technical/usage point of view, similar to TAI. That decision was wise. The decision to express date in weeks and put it in a 10-bit field was not so wise. Oh well. Only the 10 bit field wasn't. However, for a pure navigation system this doesn't matter at all. Only if you need the current legal date and time the epoch matters. Sure, but when your require the system only for navigation and not to provide time there is no reason whatsoever to sync it with any known time standard or even to tick in units of a second. Apparently the application of providing UTC time was considered in the design phase, but it was never thought the system would be deployed and would remain operational and be widely universally used for more than 19 years. In this regard, it is similar to the Internet. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] pool.ntp.org and authentication
Miroslav Lichvar mlich...@redhat.com wrote: On Tue, Dec 16, 2014 at 05:43:59AM +, Harlan Stenn wrote: d_anderson writes: Thanks! I quickly skimmed through the document, and I think I am asking the wrong questions.. I've been trying to think of good reasons to authenticate pool servers and I haven't come up with any good ones yet. Protection against MITM attacks? Of course, with a public pool like pool.ntp.org an attacker could join it with a number of his NTP servers, get their certificates signed and serve whatever he wants, no need for a MITM. Even if DNS was secure and all clients were configured to use four pool servers, the pool DNS server would not likely be able to prevent some clients getting three bad servers outvoting the fourth server. But I think it would still be a significant improvement in security. The NTS draft says the scheme is not applicable to pools. I'm wondering what would be needed to make it applicable. Just like a certificate on a website tells absolutely nothing about the quality of the content of the website, so does a certificate on an NTP server. It tells you who applied for the certificate, not what quality they are serving. In the NTP pool the servers are only put in the DNS when the monitoring system considers the time returned from that server sufficiently reliable. But the server can easily separate the queries from the monitoring system from the queries by the clients they want to mislead, so it is trivial to keep the servers in the pool while returning wrong time to others. Authentication does absolutely nothing to solve that. It could be alleviated by cloud monitoring of the servers. E.g. code could be added in ntpd so each NTP pool server using that code version also monitors some other servers in the pool (possibly a rotating set), and reports its findings to the pool control server. That still would not prevent targeted attacks to clients of which the IP address is fixed and known to the attackers, and known to be not in the NTP pool. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP PPS, part 2 ;)
Harlan Stenn st...@ntp.org wrote: Rob writes: Paul tik-...@bodosom.net wrote: On Sat, Dec 13, 2014 at 3:16 PM, Rob nom...@example.com wrote: You know what? On the ntp-dev package for Debian THE BUILD DEPENDENCIES ARE INCORRECT AS WELL!! This is an example of what NTF doesn't want to deal with. My instance of Wheezy doesn't have ntp-dev. No, I am talking about the ntp-dev package from the NTP developers themselves. Even in the provided Debian package the build dependencies are not OK. We no longer have an active maintainer for the debian package. One solution to this is for a qualified person/group to take over the maintenance of that package. The other is for us to delete it on our end, and let some outside party handle it as they see fit. I suggest that you append , pps-tools to the line starting with Build-Depends: in the .dsc file for the package. But I guess I am not qualified for that task since I do no know what releng is and did not read chapter 13 of some book. So you will need to find a qualified person to do that, and probably pay him. (no wonder that you cannot get active contributors! sheeesh...) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trying to compile ntp-dev-4.2.7p485-RC
William Unruh un...@invalid.ca wrote: Mageia 3 capability.h is also in /usr/include/linux and timepps.h does not exist. (not does a ppstools package) The package is named pps-tools not ppstools. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trying to compile ntp-dev-4.2.7p485-RC
William Unruh un...@invalid.ca wrote: On 2014-12-15, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: Mageia 3 capability.h is also in /usr/include/linux and timepps.h does not exist. (not does a ppstools package) The package is named pps-tools not ppstools. It also does not have a pps-tools package. Ok but of course it is a playskool kit, not something designed for serious use. We experimented a bit with it for our project but quickly dumped it in favour of Debian Wheezy. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP PPS, part 2 ;)
Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Paul writes: --001a11c12566ef4fbd050a04ed7c Content-Type: text/plain; charset=ISO-8859-1 On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote: It's an OS-specific file that should be provided by the OS if the underlying API exists. To repeat what I reminded you of last time. Linux *doesn't* have the API. The macros in timepps provide the RFC compliant API. The NTP developers should stop depending on the pps-tools maintainer to provide the macros and rewrite the module to use the native ioctl interface or ask the downstream maintainers to take on that task. Who wants to do this work? NTF will take it on after it gets funding for developers. I'd love to see that happen sooner rather than later. Oh come on... this is just a matter of copying one file of a few KB into the include directory of the ntp package and you are done. You have clearly never done releng work. I don't even know what you mean! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP PPS, part 2 ;)
Paul tik-...@bodosom.net wrote: On Sat, Dec 13, 2014 at 3:16 PM, Rob nom...@example.com wrote: You know what? On the ntp-dev package for Debian THE BUILD DEPENDENCIES ARE INCORRECT AS WELL!! This is an example of what NTF doesn't want to deal with. My instance of Wheezy doesn't have ntp-dev. No, I am talking about the ntp-dev package from the NTP developers themselves. Even in the provided Debian package the build dependencies are not OK. Fortunately there is gpsd. You do realize gpsd pps support requires timepps which isn't in the 3.9 or 3.11 tarballs (those are the ones I have at hand). gpsd can use pps without any kernel support and without any additional files. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
