Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit
On 13/08/2013 23:03, Charles Swiger wrote: Hi-- [] I wonder how many of the Windows users do anything with ntpd which needs crypto? ntpd by itself (ie, ./configure --without-crypto) has a fairly clean security history compared to something like OpenSSL's ASN.1 parser: http://www.openssl.org/news/vulnerabilities.html Regards, I've never had any need for crypto here, but I'm not running a critical, enterprise-wide installation. In my previous job, I was running a network where Windows NT were the prime servers (taking their NTP from enterprise-wide UNIX servers), so crypto may eventually have been used there. Most Windows users would not, I suspect, need crypto, and they have client-only functionality. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit
On 13/08/2013 22:41, Harlan Stenn wrote: David Taylor writes: On 13/08/2013 21:23, Danny Mayer wrote: [] All binaries need to be built together with the same versions. You should not be mixing binaries. Danny Thanks, Danny. Perhaps,ideally, but in that case, why are the SSL sources not in the distributed NTP source files? Originally, ITAR concerns. It also increases our workload for limited benefit. If you are building NTP on windows you should have the knowledge to get and install OpenSSL. H Thanks, Harlan. I have already included the necessary information on my Web page. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Malone wrote: It seems my ancient GPSclock 200 has recently slipped back to December 1993 too. Resetting it hasn't helped and I doubt I will be able to do a firmware update, so I've made a hack to refclock_nmea.c (version ntp-4.2.6p5), by replacing: reftime.l_ui += caltontp(date); with reftime.l_ui += caltontp(date); while (reftime.l_i + 512*7*86400 rd_timestamp.l_i) reftime.l_i += 1024*7*86400; Nice! You've replaced the 1024-week epoch with a +/- 512-week window around the current time. :-) I'm trying to adjust the timestamp given by NMEA might be slow by some multiple of 1024 weeks, and so tries to adjust it so that it is reasonably close to the system time associated with the read of the NMEA data. I'm not sure if I've got the code exactly bang-on, but it has got ntp running with the unit again. Looks good. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
Terje Mathisen terje.mathisen at tmsw.no writes: Nice! You've replaced the 1024-week epoch with a +/- 512-week window around the current time. :-) Indeed - ntp already sort of has to do a similar, because the timestamps are mod 2^32 seconds from 1900, so using a trick like this is only marginally distasteful ;-) I'm trying to adjust the timestamp given by NMEA might be slow by some multiple of 1024 weeks, and so tries to adjust it so that it is reasonably close to the system time associated with the read of the NMEA data. I'm not sure if I've got the code exactly bang-on, but it has got ntp running with the unit again. Looks good. On Harlan's recommendation, I've opened a feature request with the patch. If anyone notices any issues, I can log them there. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 2013-08-14, Mark C. Stephens ma...@non-stop.com.au wrote: Good on you David and welcome back to 2013. I do hope that some official changes are made to refclock_nmea to catch this receiver bug and process it accordingly. There are a lot of folks stranded in 1993. --marki -Original Message- From: questions-bounces+marks=non-stop.com...@lists.ntp.org [mailto:questions-bounces+marks=non-stop.com...@lists.ntp.org] On Behalf Of David Malone Sent: Wednesday, 14 August 2013 5:30 AM To: questions@lists.ntp.org Subject: Re: Start of new GPS 1024 week epoch Magnus Danielson mag...@rubidium.dyndns.org writes: Remember that any Sunday, it is likely that a GPS reciever have slipped a multiple of 1024 weeks. NTP drivers should be able to recognice it and compensate for it, as it is a re-occuring bug in many recievers. This issue have been discussed over and over again at time-nuts. Surely if the receiver is delivering the wrong date, it is the receiver manufacturer that needs to make the changes, not ntp, including sending you a new receiver if necessary. Warrenty limits notwithstanding, this fails that fitness for purpose test, and you could hardly have detected it when you bought it. It seems my ancient GPSclock 200 has recently slipped back to December 1993 too. Resetting it hasn't helped and I doubt I will be able to do a firmware update, so I've made a hack to refclock_nmea.c (version ntp-4.2.6p5), by replacing: reftime.l_ui += caltontp(date); with reftime.l_ui += caltontp(date); while (reftime.l_i + 512*7*86400 rd_timestamp.l_i) reftime.l_i += 1024*7*86400; I'm trying to adjust the timestamp given by NMEA might be slow by some multiple of 1024 weeks, and so tries to adjust it so that it is reasonably close to the system time associated with the read of the NMEA data. I'm not sure if I've got the code exactly bang-on, but it has got ntp running with the unit again. Except of course if the rd_timestamp.l_i is way out (that is why one would want to use a gps clock to fix it-- eg on bootup with the Raspberry Pi say), David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
Um Let's see, Datum was bought by Austron, who was bought by ... etc. For collectors such as myself, having this 'mature' equipment still working is great. Looking at Mr Malone's code, he added 2 lines which enabled NTPD compatibility with GPS receivers that would have long ago have been sent to the TIP as waste. It is shame as a society we are being trained to consume. New model phone, got to have it so they queue up outside the shop 2 days before its released. Never mind they have a fully functional working phone already! Just got to have the latest. We need to start reducing our waste product, These manufacturers that design equipment to die a month after the warranty finishes should be put on the wall of shame for a start. But, I digress off subject for this newsgroup... I have heard of people in desperation trying to patch the firmware of the receiver. But along came David with his patch for NTPD and put a lot of us at rest. Thanks David :) --marki -Original Message- From: questions-bounces+marks=non-stop.com...@lists.ntp.org [mailto:questions-bounces+marks=non-stop.com...@lists.ntp.org] On Behalf Of unruh Sent: Wednesday, 14 August 2013 9:55 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Start of new GPS 1024 week epoch On 2013-08-14, Mark C. Stephens ma...@non-stop.com.au wrote: Good on you David and welcome back to 2013. I do hope that some official changes are made to refclock_nmea to catch this receiver bug and process it accordingly. There are a lot of folks stranded in 1993. --marki -Original Message- From: questions-bounces+marks=non-stop.com...@lists.ntp.org [mailto:questions-bounces+marks=non-stop.com...@lists.ntp.org] On Behalf Of David Malone Sent: Wednesday, 14 August 2013 5:30 AM To: questions@lists.ntp.org Subject: Re: Start of new GPS 1024 week epoch Magnus Danielson mag...@rubidium.dyndns.org writes: Remember that any Sunday, it is likely that a GPS reciever have slipped a multiple of 1024 weeks. NTP drivers should be able to recognice it and compensate for it, as it is a re-occuring bug in many recievers. This issue have been discussed over and over again at time-nuts. Surely if the receiver is delivering the wrong date, it is the receiver manufacturer that needs to make the changes, not ntp, including sending you a new receiver if necessary. Warrenty limits notwithstanding, this fails that fitness for purpose test, and you could hardly have detected it when you bought it. It seems my ancient GPSclock 200 has recently slipped back to December 1993 too. Resetting it hasn't helped and I doubt I will be able to do a firmware update, so I've made a hack to refclock_nmea.c (version ntp-4.2.6p5), by replacing: reftime.l_ui += caltontp(date); with reftime.l_ui += caltontp(date); while (reftime.l_i + 512*7*86400 rd_timestamp.l_i) reftime.l_i += 1024*7*86400; I'm trying to adjust the timestamp given by NMEA might be slow by some multiple of 1024 weeks, and so tries to adjust it so that it is reasonably close to the system time associated with the read of the NMEA data. I'm not sure if I've got the code exactly bang-on, but it has got ntp running with the unit again. Except of course if the rd_timestamp.l_i is way out (that is why one would want to use a gps clock to fix it-- eg on bootup with the Raspberry Pi say), David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Order of servers in ntp.conf
For ntpd 4.2.4p6 running on Linux, is there any significance to the order of servers in the ntp.conf file? Will ntpd synchronize with the first available/good time server in the list? Thanks, Nils Brubaker ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 2013-08-13, Nils Brubaker n...@us.ibm.com wrote: For ntpd 4.2.4p6 running on Linux, is there any significance to the order of servers in the ntp.conf file? Will ntpd synchronize with the first available/good time server in the list? No, no. ntp gets the data from all the servers. It then looks at the times it gets from each server, and groups them into classes according to its estimate of the max time error from the server-- ie whether the error intervals overlap or not. It then looks for the largest group of servers all of whose error intervals overlap and uses the average of those times as the time to send on the the ntp engine. The others are false tickers. It estimates the error by looking at the round trip time and the other machine's estimate of its own max error. Thanks, Nils Brubaker ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
Mark C. Stephens ma...@non-stop.com.au wrote: Um Let's see, Datum was bought by Austron, who was bought by ... etc. For collectors such as myself, having this 'mature' equipment still working is great. Looking at Mr Malone's code, he added 2 lines which enabled NTPD compatibility with GPS receivers that would have long ago have been sent to the TIP as waste. It is shame as a society we are being trained to consume. New model phone, got to have it so they queue up outside the shop 2 days before its released. Never mind they have a fully functional working phone already! Just got to have the latest. We need to start reducing our waste product, In itself this is true, but be careful. It may be that your old receiver consumes so much energy and has so much valuable material in it that it would actually be better to get a new one and recycle this old one. I have old GPS receivers and they are quite power-hungry, insensitive, and have a small number of active satellites. New receivers are much better, except maybe in the PPS department. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
Thank you, un...@invalid.ca, for your response to my question. Couple follow-up questions. My ntp.conf running on Linux has 4 servers defined: server 0.rhel.pool.ntp.org server 1.rhel.pool.ntp.org server 2.rhel.pool.ntp.org These are public servers from the NTP pool project. In my /var/log/diag-log file, I see messages indicating that my ntpd is synching with individual servers, for example: Aug 7 09:53:58 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 10:04:52 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 10:39:05 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 11:28:17 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 12:47:06 yellowstone ntpd[3272]: synchronized to 128.10.19.24, stratum 1 ... Aug 8 11:37:43 yellowstone ntpd[3254]: synchronized to 50.116.55.65, stratum 2 Aug 8 12:18:46 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 13:01:27 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 Aug 8 15:01:00 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 16:09:20 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 These log messages suggest that ntpd is synchronizing with one and only one NTP server. Is that the correct interpretation? Is this single server selected for synchronization only after performing all the calculations described below? Also, I see long time periods in the diag-log where there is no synchronization message. What does that signify? No agreement between the servers on the correct time? No need to adjust system clock because it is already in sync? Thanks, Nils Brubaker On 2013-08-13, Nils Brubaker ncb at us.ibm.com wrote: For ntpd 4.2.4p6 running on Linux, is there any significance to the order of servers in the ntp.conf file? Will ntpd synchronize with the first available/good time server in the list? No, no. ntp gets the data from all the servers. It then looks at the times it gets from each server, and groups them into classes according to its estimate of the max time error from the server-- ie whether the error intervals overlap or not. It then looks for the largest group of servers all of whose error intervals overlap and uses the average of those times as the time to send on the the ntp engine. The others are false tickers. It estimates the error by looking at the round trip time and the other machine's estimate of its own max error. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 13/08/2013 20:52, Nils Brubaker wrote: For ntpd 4.2.4p6 running on Linux, is there any significance to the order of servers in the ntp.conf file? Will ntpd synchronize with the first available/good time server in the list? Thanks, Nils Brubaker The order you list likely determines the order shown in an ntpq -p results billboard. That's the command you should use to check the sync status. See the section Tally Codes in: http://doc.ntp.org/4.2.4/ntpq.html Why run such an old version? The synchronized to messages relate to a switch of servers. If the servers are all of a similar quality, this is sometimes referred to as clock hopping, but otherwise it may indicate that the data from server A is now worse than that from server B (perhaps because of Internet loading), so NTP switches from A to B. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
I don't understand how you get the idea that your system is synchronizing with only one server when the messages you posted show it synchronizing with 6 servers. Do you mean that it is synchronizing with one server at a time? That is what it is supposed to do. There is a combining step in the algorithms that can adjust the actual offset used by combining with offsets from others in a selected group, but there is always a single primary sync source. On 8/14/2013 11:03 AM, Nils Brubaker wrote: Thank you, un...@invalid.ca, for your response to my question. Couple follow-up questions. My ntp.conf running on Linux has 4 servers defined: server 0.rhel.pool.ntp.org server 1.rhel.pool.ntp.org server 2.rhel.pool.ntp.org These are public servers from the NTP pool project. In my /var/log/diag-log file, I see messages indicating that my ntpd is synching with individual servers, for example: Aug 7 09:53:58 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 10:04:52 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 10:39:05 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 11:28:17 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 12:47:06 yellowstone ntpd[3272]: synchronized to 128.10.19.24, stratum 1 ... Aug 8 11:37:43 yellowstone ntpd[3254]: synchronized to 50.116.55.65, stratum 2 Aug 8 12:18:46 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 13:01:27 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 Aug 8 15:01:00 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 16:09:20 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 These log messages suggest that ntpd is synchronizing with one and only one NTP server. Is that the correct interpretation? Is this single server selected for synchronization only after performing all the calculations described below? Also, I see long time periods in the diag-log where there is no synchronization message. What does that signify? No agreement between the servers on the correct time? No need to adjust system clock because it is already in sync? Thanks, Nils Brubaker On 2013-08-13, Nils Brubaker ncb at us.ibm.com wrote: For ntpd 4.2.4p6 running on Linux, is there any significance to the order of servers in the ntp.conf file? Will ntpd synchronize with the first available/good time server in the list? No, no. ntp gets the data from all the servers. It then looks at the times it gets from each server, and groups them into classes according to its estimate of the max time error from the server-- ie whether the error intervals overlap or not. It then looks for the largest group of servers all of whose error intervals overlap and uses the average of those times as the time to send on the the ntp engine. The others are false tickers. It estimates the error by looking at the round trip time and the other machine's estimate of its own max error. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 14/08/2013 12:54, unruh wrote: [] Except of course if the rd_timestamp.l_i is way out (that is why one would want to use a gps clock to fix it-- eg on bootup with the Raspberry Pi say), [] Could you not use something like the timestamp of some file (e.g. the drift file) or other system file to get the approximate year? I haven't studied the code (I find C not easy to read or navigate) so perhaps it already does this. Then you would only need to set the real time once? As it happens, all of my RPi pack will have an Internet source as well, and they all have recent GPS receivers which (I hope) don't have this issue -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Taylor david-tay...@blueyonder.co.uk.invalid writes: Could you not use something like the timestamp of some file (e.g. the drift file) or other system file to get the approximate year? I haven't studied the code (I find C not easy to read or navigate) so perhaps it already does this. Then you would only need to set the real time once? Possibly - this was a handy timestamp to use, but there may be a better choice. It's also possible that this should be an optional flag to the driver, so that people with perfectly good GPS units won't ever trip over the code ;-) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 14/08/2013 17:14, David Malone wrote: [] Possibly - this was a handy timestamp to use, but there may be a better choice. It's also possible that this should be an optional flag to the driver, so that people with perfectly good GPS units won't ever trip over the code ;-) David. Yes, I would prefer to see a flag which enables this, with the default being off. All being well, the number of NTP installations with good receivers should be increasing over the number with problem receivers. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 17:14, David Malone wrote: [] Possibly - this was a handy timestamp to use, but there may be a better choice. It's also possible that this should be an optional flag to the driver, so that people with perfectly good GPS units won't ever trip over the code ;-) David. Yes, I would prefer to see a flag which enables this, with the default being off. All being well, the number of NTP installations with good receivers should be increasing over the number with problem receivers. How does a good receiver know the correct time? Does it rely on local (backed-up) storage, or is there some way of receiving it via the almanac? Or are good receivers hardwired as well, only with a different valid span? I would not be surprised when good receivers turn out to have just a different moment or mode of failure. I think the firmware authors have just coded in arbitrary boundaries where weeknumbers above that boundary are considered to be in the previous week span, and numbers below the boundary are in the current span. This particular firmware just happened to be one of the first in which this effect was noticed. It is like the solution often chosen to convert 2-digit to 4-digit years: all years above (say) 80 are handled as 19xx, below 80 is 20xx. So in 2080 there suddenly is a problem. The difference is that the span is one century in that case, while with GPS it is only 20 years. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 2013-08-14, Nils Brubaker n...@us.ibm.com wrote: Thank you, un...@invalid.ca, for your response to my question. Couple follow-up questions. My ntp.conf running on Linux has 4 servers defined: server 0.rhel.pool.ntp.org server 1.rhel.pool.ntp.org server 2.rhel.pool.ntp.org These are public servers from the NTP pool project. In my /var/log/diag-log file, I see messages indicating that my ntpd is synching with individual servers, for example: Aug 7 09:53:58 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 10:04:52 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 10:39:05 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 11:28:17 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 12:47:06 yellowstone ntpd[3272]: synchronized to 128.10.19.24, stratum 1 ... Aug 8 11:37:43 yellowstone ntpd[3254]: synchronized to 50.116.55.65, stratum 2 Aug 8 12:18:46 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 13:01:27 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 Aug 8 15:01:00 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 16:09:20 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 These log messages suggest that ntpd is synchronizing with one and only one NTP server. Is that the correct interpretation? Is this single server selected for synchronization only after performing all the calculations described below? As I understand it, once it has done all of the calculations, it picks one of the servers in the accepted bunch of servers and uses it as a proxy for all of them. Ie, the above is shorthand for synchronized to a pool of servers which includes 38.101.77.21 Also, I see long time periods in the diag-log where there is no synchronization message. What does that signify? No agreement between No change. the servers on the correct time? No need to adjust system clock because it is already in sync? Neither. You can look at the loopstats file to see what is actually happening. Remember also that once ntpd drops to poll interval 10, that means 1024 seconds between polls (that is about 20 min) and it then chooses 1 of about 8 of those polls to actually use. So, the time between effective polls is about 3 hours. Nothing changes in that three hours since there is no new data. I am sure that someone will correct me if I have some of the details of the selection algorithm wrong. Thanks, Nils Brubaker On 2013-08-13, Nils Brubaker ncb at us.ibm.com wrote: For ntpd 4.2.4p6 running on Linux, is there any significance to the order of servers in the ntp.conf file? Will ntpd synchronize with the first available/good time server in the list? No, no. ntp gets the data from all the servers. It then looks at the times it gets from each server, and groups them into classes according to its estimate of the max time error from the server-- ie whether the error intervals overlap or not. It then looks for the largest group of servers all of whose error intervals overlap and uses the average of those times as the time to send on the the ntp engine. The others are false tickers. It estimates the error by looking at the round trip time and the other machine's estimate of its own max error. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
On 2013-08-14, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 12:54, unruh wrote: [] Except of course if the rd_timestamp.l_i is way out (that is why one would want to use a gps clock to fix it-- eg on bootup with the Raspberry Pi say), [] Could you not use something like the timestamp of some file (e.g. the drift file) or other system file to get the approximate year? I haven't studied the code (I find C not easy to read or navigate) so perhaps it already does this. Then you would only need to set the real time once? Sure, you can kludge your way around the problem if you know there is a problem. But ntpd code does not have any such routine in it, so you have to do it by hand. Knowing it needs to be done, it can be done, but of course most people have no idea it needs to be done. As it happens, all of my RPi pack will have an Internet source as well, and they all have recent GPS receivers which (I hope) don't have this issue Many people have their RPi in some remote location with no internet connection, collecting data, or whatever. GPS is the only source of time. One would like an install and go solution without having to worry about things like whether the time is in the right epoch, whatever. (power goes out on that buoy out on the antlantic for a day, and the thing reboots finally when the sun comes out again. You do not want to have to swim out to it to reset the clock.) I agree that this is a problem only under the perfect storm situation-- old broken gps receiver, computer with no RTC, no internet connection, etc. so the set of affected people could well be of size much much less than 1. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 14/08/2013 12:54, unruh wrote: [] Except of course if the rd_timestamp.l_i is way out (that is why one would want to use a gps clock to fix it-- eg on bootup with the Raspberry Pi say), [] Could you not use something like the timestamp of some file (e.g. the drift file) or other system file to get the approximate year? I haven't studied the code (I find C not easy to read or navigate) so perhaps it already does this. Then you would only need to set the real time once? As it happens, all of my RPi pack will have an Internet source as well, and they all have recent GPS receivers which (I hope) don't have this issue The raspberry pi already does that. It regularly (and on shutdown) saves the date/time in a file and loads that on boot. No need to handle this in ntpd. it is done in the /etc/init.d scripts. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Malone writes: Indeed - you need to have a timestamp within about ten years of correct before you start up, otherwise the problem will be worse. Ntp has the same problem in figuring out the ntp epoch, though we've yet to see an ntp timestamp wrap around. ntp-dev has a fix for this problem - while the original solution was make sure the clock is correct to within ~65 years' time the new code uses a date of compile value, and needs the system time to be either 10 years' before that date or up to 128 years' after that date. See http://bugs.ntp.org/show_bug.cgi?id=1995 for more information (thanks, Juergen!). H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
On 2013-08-14, unruh un...@invalid.ca wrote: On 2013-08-14, Nils Brubaker n...@us.ibm.com wrote: Aug 8 15:01:00 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 16:09:20 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 These log messages suggest that ntpd is synchronizing with one and only one NTP server. Is that the correct interpretation? Is this single server selected for synchronization only after performing all the calculations described below? As I understand it, once it has done all of the calculations, it picks one of the servers in the accepted bunch of servers and uses it as a proxy for all of them. Ie, the above is shorthand for synchronized to a pool of servers which includes 38.101.77.21 The time server specified in each of those lines is the one which is currently selected as the sys_peer. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit
Charles Swiger wrote: I wonder how many of the Windows users do anything with ntpd which needs crypto? (Shrug) http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html#mcst I use ntpd with MD5 symmetric keys for manycast on all clients / servers. ... keys /etc/ntp.keys # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY , ... trustedkey 123 321 tos cohort 1 orphan 10 restrict source nomodify manycastserver 224.0.1.1 manycastclient 224.0.1.1 key 123 preempt ... As you can see, its trivial to setup, and I find it makes adding and removing clients / servers trivial on the LAN. No matter what other refclocks any given client / server may or may not have; they end up picking the best of what is available. If LAN and internet based Stratum One /or Two Servers become unavailable, they follow each other around, until better sources are available again; they they automatically switch back to following the S1 /or S2 servers again. Add GPS RefClock to any NTP Client / Server, anywhere on the LAN, it will be discovered and used, no configuration changes needed in all the other NTP Clients / Servers on the LAN. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
Harlan Stenn wrote: ntp-dev has a fix for this problem - while the original solution was make sure the clock is correct to within ~65 years' time the new code uses a date of compile value, and needs the system time to be either 10 years' before that date or up to 128 years' after that date. See http://bugs.ntp.org/show_bug.cgi?id=1995 for more information (thanks, Juergen!). I'll bet the people using older versions of ntp on embedded systems without a RTC will like that too, as they have been doing about the same thing themselves before starting ntpd. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Acutime Gold
Mark C. Stephens wrote: remote refid st t when poll reach delay offset jitter === oPPS(0) .PPS. 0 l- 16 377 0.000 -0.001 0.004 *GPS_PALISADE(0) .GPS. 0 l 16 16 377 0.000 0.018 0.008 I was thinking about that, but how do I correlate 0.017 to time1 ? BlackList Wrote: Why can't you fix the offset with time 1 in for Driver 29? fudge 127.127.29.0 time1 0.017 -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
Hi, On 08/14/2013 03:54 PM, unruh wrote: On 2013-08-14, Mark C. Stephens ma...@non-stop.com.au wrote: Um Let's see, Datum was bought by Austron, who was bought by ... etc. For collectors such as myself, having this 'mature' equipment still working is great. Looking at Mr Malone's code, he added 2 lines which enabled NTPD compatibility with GPS receivers that would have long ago have been sent to the TIP as waste. It is however fragile code. Ie, all kinds of situations could arise in which it would give the wrong time. Now, you may say that there are situations in which it will give the right time when, without the kludge, it would give the wrong time. This addresses a known feature of the GPS system, common over a large range of receivers. The differences between them lies in which GPS week they flip over (GPS week 500, 512 and 729 from the top of my head). The failure they have is not in their operation, but in their production of a human readable date. This is what I have proposed elsewhere (on time-nuts) and it is a sound solution considering the situation we have where the ICD-GPS-200 through it's many revisions have not provided additional bits for the L1 C/A code signal. For the L2C (and I assume also L1C, but I haven't checked yet) signal additional bits exists, but very few recievers have that support. I recommend reading the time-nuts backlog on this issue. Among the alternatives you have, it's ditching an otherwise perfectly operating GPS receiver or use the fact that the 1024 week wrap-around is bound to happen, is predictable as a systematic effect from how the GPS C/A data is structured and re-occurs over the fleet of GPS receivers. Do note that the GPS receivers does compute leap-second info correctly regardless of this 1024 offset hickup, as that information is structured modulu 1024 weeks. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
