[ntp:questions] ntp-dev: PPS is a falseticker?
I installed the ntp-dev package for Debian as recommended here to get better resolution for the offset and jitter values. The service was started with a local PPS clock (ATOM) and a couple of low-stratum external servers. The PPS was not available when ntpd started, but was connected about 12 hours later. The poll intervals of the external servers were at 1024 already at that time. Now, 4 hours after connecting the PPS, it is (still) classified as a falseticker. It is less than 200us off the local clock! remote refid st t when poll reach delay offset jitter == x127.127.22.0.PPS.0 l 11 16 3770.000 -0.191 0.001 +xx.xxx..xxx .PPS.1 u 810 1024 377 18.5320.111 0.248 -xx.xxx.xx.x 192.87.36.4 2 u 924 1024 3776.124 -1.808 0.486 +xxx.xxx.x.xxx .PPS.1 u 639 1024 3773.9280.376 6.329 *xxx.xx.xxx.xx .PPS.1 u 247 1024 3774.402 -0.445 0.321 -xxx.xxx.xxx.xxx 192.168.2.2 2 u 964 1024 3777.7720.314 0.646 ind assid status conf reach auth condition last_event cnt === 1 26409 9134 yes yes none falsetick reachable 3 2 26410 941a yes yes none candidatesys_peer 1 3 26411 9324 yes yes none outlyer reachable 2 4 26412 941a yes yes none candidatesys_peer 1 5 26413 961a yes yes none sys.peersys_peer 1 6 26414 933a yes yes none outlyersys_peer 3 associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event, version="ntpd 4.2.7p444@1.2483-o Wed Jun 11 20:31:24 UTC 2014 (1)", processor="x86_64", system="Linux/3.2.0-4-amd64", leap=00, stratum=2, precision=-23, rootdelay=4.402, rootdisp=36.051, refid=193.79.237.14, reftime=d7459b9c.70fe6483 Fri, Jun 13 2014 17:47:40.441, clock=d745a09d.0cde151e Fri, Jun 13 2014 18:09:01.050, peer=26413, tc=10, mintc=3, offset=-0.260141, frequency=-17.339, sys_jitter=0.831137, clk_jitter=0.194, clk_wander=0.001 Why is it so picky? O also observer that for the past 10 hour or so it has hovered about at offsets between -200 and -400us all the time, never returning to zero. Shouldn't it try to steer the offset towards zero all the time? When it would, it would see that the PPS source is correct, wouldn't it? The regulation proceeds very slowly at 1024 second polls, and it looks like it has become worse by my upgrade from 4.2.6p5 to 4.2.7p444. I know I can resolve such behaviour (often) by restarting ntpd, but I would like to know why it can't figure it out itself. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Fri, Jun 13, 2014 at 12:17 PM, Rob wrote: > > Why is it so picky? > Why is your jitter so high? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Paul wrote: > On Fri, Jun 13, 2014 at 12:17 PM, Rob wrote: > >> >> Why is it so picky? >> > > > Why is your jitter so high? High? 0.001 is 1us. That is not high, isn't it? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On 2014-06-13 10:17, Rob wrote: I installed the ntp-dev package for Debian as recommended here to get better resolution for the offset and jitter values. The service was started with a local PPS clock (ATOM) and a couple of low-stratum external servers. The PPS was not available when ntpd started, but was connected about 12 hours later. The poll intervals of the external servers were at 1024 already at that time. Now, 4 hours after connecting the PPS, it is (still) classified as a falseticker. It is less than 200us off the local clock! remote refid st t when poll reach delay offset jitter == x127.127.22.0.PPS.0 l 11 16 3770.000 -0.191 0.001 +xx.xxx..xxx .PPS.1 u 810 1024 377 18.5320.111 0.248 -xx.xxx.xx.x 192.87.36.4 2 u 924 1024 3776.124 -1.808 0.486 +xxx.xxx.x.xxx .PPS.1 u 639 1024 3773.9280.376 6.329 *xxx.xx.xxx.xx .PPS.1 u 247 1024 3774.402 -0.445 0.321 -xxx.xxx.xxx.xxx 192.168.2.2 2 u 964 1024 3777.7720.314 0.646 ind assid status conf reach auth condition last_event cnt === 1 26409 9134 yes yes none falsetick reachable 3 2 26410 941a yes yes none candidatesys_peer 1 3 26411 9324 yes yes none outlyer reachable 2 4 26412 941a yes yes none candidatesys_peer 1 5 26413 961a yes yes none sys.peersys_peer 1 6 26414 933a yes yes none outlyersys_peer 3 associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event, version="ntpd 4.2.7p444@1.2483-o Wed Jun 11 20:31:24 UTC 2014 (1)", processor="x86_64", system="Linux/3.2.0-4-amd64", leap=00, stratum=2, precision=-23, rootdelay=4.402, rootdisp=36.051, refid=193.79.237.14, reftime=d7459b9c.70fe6483 Fri, Jun 13 2014 17:47:40.441, clock=d745a09d.0cde151e Fri, Jun 13 2014 18:09:01.050, peer=26413, tc=10, mintc=3, offset=-0.260141, frequency=-17.339, sys_jitter=0.831137, clk_jitter=0.194, clk_wander=0.001 Why is it so picky? O also observer that for the past 10 hour or so it has hovered about at offsets between -200 and -400us all the time, never returning to zero. Shouldn't it try to steer the offset towards zero all the time? When it would, it would see that the PPS source is correct, wouldn't it? The regulation proceeds very slowly at 1024 second polls, and it looks like it has become worse by my upgrade from 4.2.6p5 to 4.2.7p444. I know I can resolve such behaviour (often) by restarting ntpd, but I would like to know why it can't figure it out itself. You have not told us much about your hardware and configuration. Check your log to see if your PPS driver is being recognized as such. You also need a local (NMEA 127.127.20.0/Motorola 127.127.30.0/?) ref clock driver prefer peer (GPS?) time source to number the seconds from whatever is providing your PPS. You could set your best source as your prefer peer to get your PPS source taken into consideration. You may need to run your ref clock drivers as noselect for a few hours to days to get decent estimates of any fudge delay times required to calibrate your references, and restart the daemon after any adjustments. Local sources will tend to cluster together as will good network sources, and enough should intersect to give you the required three truechimers (mintc=3) from the selction algorithm. Bear in mind that the number of falsetickers must always be less than half the number of your total sources, otherwise you will never get the majority of candidates as survivors required for Byzantine agreement, and no system peer will be selected, as the selection algorithm will normally bail if the number of falsetickers exceeds the truechimers. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Brian Inglis wrote: > On 2014-06-13 10:17, Rob wrote: >> I installed the ntp-dev package for Debian as recommended here to get >> better resolution for the offset and jitter values. >> >> The service was started with a local PPS clock (ATOM) and a couple of >> low-stratum external servers. The PPS was not available when ntpd >> started, but was connected about 12 hours later. The poll intervals >> of the external servers were at 1024 already at that time. >> >> Now, 4 hours after connecting the PPS, it is (still) classified as >> a falseticker. It is less than 200us off the local clock! >> >> remote refid st t when poll reach delay offset >> jitter >> == >> x127.127.22.0.PPS.0 l 11 16 3770.000 -0.191 >> 0.001 >> +xx.xxx..xxx .PPS.1 u 810 1024 377 18.5320.111 >> 0.248 >> -xx.xxx.xx.x 192.87.36.4 2 u 924 1024 3776.124 -1.808 >> 0.486 >> +xxx.xxx.x.xxx .PPS.1 u 639 1024 3773.9280.376 >> 6.329 >> *xxx.xx.xxx.xx .PPS.1 u 247 1024 3774.402 -0.445 >> 0.321 >> -xxx.xxx.xxx.xxx 192.168.2.2 2 u 964 1024 3777.7720.314 >> 0.646 >> >> ind assid status conf reach auth condition last_event cnt >> === >>1 26409 9134 yes yes none falsetick reachable 3 >>2 26410 941a yes yes none candidatesys_peer 1 >>3 26411 9324 yes yes none outlyer reachable 2 >>4 26412 941a yes yes none candidatesys_peer 1 >>5 26413 961a yes yes none sys.peersys_peer 1 >>6 26414 933a yes yes none outlyersys_peer 3 >> associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event, >> version="ntpd 4.2.7p444@1.2483-o Wed Jun 11 20:31:24 UTC 2014 (1)", >> processor="x86_64", system="Linux/3.2.0-4-amd64", leap=00, stratum=2, >> precision=-23, rootdelay=4.402, rootdisp=36.051, refid=193.79.237.14, >> reftime=d7459b9c.70fe6483 Fri, Jun 13 2014 17:47:40.441, >> clock=d745a09d.0cde151e Fri, Jun 13 2014 18:09:01.050, peer=26413, >> tc=10, mintc=3, offset=-0.260141, frequency=-17.339, sys_jitter=0.831137, >> clk_jitter=0.194, clk_wander=0.001 >> >> Why is it so picky? >> O also observer that for the past 10 hour or so it has hovered about >> at offsets between -200 and -400us all the time, never returning to >> zero. Shouldn't it try to steer the offset towards zero all the time? >> When it would, it would see that the PPS source is correct, wouldn't it? >> The regulation proceeds very slowly at 1024 second polls, and it looks >> like it has become worse by my upgrade from 4.2.6p5 to 4.2.7p444. >> >> I know I can resolve such behaviour (often) by restarting ntpd, but I >> would like to know why it can't figure it out itself. > > You have not told us much about your hardware and configuration. > > Check your log to see if your PPS driver is being recognized as such. Well, see the above output. There is an entry for the ATOM driver (127.127.22.0) which works OK but is marked a falseticker. There also are 5 network time sources that work fine. The sampling interval has gone up to 1024. > You also need a local (NMEA 127.127.20.0/Motorola 127.127.30.0/?) > ref clock driver prefer peer (GPS?) time source to number the seconds > from whatever is providing your PPS. The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on a serial port, but no date information (it does provide time, but that is not very useful without date). So I choose not to use the time info and use external (network) sources are used for that. This has worked before using 4.2.6p5. > You could set your best source as your prefer peer to get your > PPS source taken into consideration. That actually helps! But why? I don't like to mark a source as prefer, certainly not another source than the PPS. Why is there a difference? Is this a workaround for a bug, or is this a feature and if so, what is the rationale behind it? And what is going to happen when the prefer peer happens to be unreachable? will it again go haywire then? If so, what is the point of having multiple sources for redundancy? Now the status is like this: remote refid st t when poll reach delay offset jitter == o127.127.22.0.PPS.0 l4 16 3770.0000.000 0.000 *xx.xxx.xxx.xxx .PPS.1 u 45 64 377 17.898 -0.057 0.196 +xxx.xxx.x.xxx .PPS.1 u 138 256 3773.1060.155 3.493 +xxx.xx.xxx.xx .PPS.1 u 149 256 3774.772 -0.350 0.499 -xx.xxx.xx.x 192.87.36.4 2 u 59 64 3776.107 -1.303 1.632 -xxx.xxx..xx 192.87.36.4 2 u 213 256 3777.0580.478 0.709 ind assid status conf reach auth condit
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Le 14 juin 2014 à 10:27, Rob a écrit : > The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on > a serial port, but no date information (it does provide time, but that > is not very useful without date). > So I choose not to use the time info and use external (network) sources > are used for that. This has worked before using 4.2.6p5. I doubt it. I have the same issue with both 4.2.6p5 and 4.2.7p444. No prefer peer, no dice. This is FreeBSD 8.2 $ ntpd --version ntpd 4.2.6p5 ntpd 4.2.6p5@1.2349-o Mon Jul 2 04:47:51 UTC 2012 (1) Sat Jun 14 12:35:25 CEST 2014 remote refid st t when poll reach delay offset jitter = x127.127.22.1.PPS1. 0 l5 16 3770.0000.030 0.008 > >> You could set your best source as your prefer peer to get your >> PPS source taken into consideration. > > That actually helps! > But why? I don't like to mark a source as prefer, certainly not another > source than the PPS. > Why is there a difference? Is this a workaround for a bug, or is this > a feature and if so, what is the rationale behind it? > And what is going to happen when the prefer peer happens to be unreachable? > will it again go haywire then? If so, what is the point of having multiple > sources for redundancy? The same happens when the prefer peer is not available at start time. Sat Jun 14 12:42:35 CEST 2014 remote refid st t when poll reach delay offset jitter x127.127.22.1.PPS1. 0 l5 16 3770.0000.065 0.014 If the prefer peer becomes unavailable : Sat Jun 14 12:52:12 CEST 2014 remote refid st t when poll reach delay offset jitter o127.127.22.1.PPS1. 0 l 15 16 3770.0000.072 0.008 *192.168.1.4 .PPS1. 1 u 107 16 3400.9230.108 0.025 Sat Jun 14 12:53:21 CEST 2014 remote refid st t when poll reach delay offset jitter *127.127.22.1.PPS1. 0 l4 16 3770.0000.094 0.020 192.168.1.4 .PPS1. 1 u 175 1600.9320.117 0.008 and the offset starts to spiral out *127.127.22.1.PPS1. 0 l9 16 3770.0000.168 0.072 *127.127.22.1.PPS1. 0 l7 16 3770.0000.287 0.087 *127.127.22.1.PPS1. 0 l 16 16 3770.0000.351 0.074 *127.127.22.1.PPS1. 0 l5 16 3770.0000.444 0.082 *127.127.22.1.PPS1. 0 l 10 16 3770.0000.509 0.075 *127.127.22.1.PPS1. 0 l 15 16 3770.0000.532 0.035 I left it running in that state and although the offset gets back to normal values Sat Jun 14 13:12:10 CEST 2014 remote refid st t when poll reach delay offset jitter = *127.127.22.1.PPS1. 0 l 14 16 3770.0000.008 0.042 192.168.1.4 .PPS1. 1 u 1305 1600.9320.117 0.000 As soon as NP selects another server as peer, the PPS source drops to falseticker state. Sat Jun 14 13:16:45 CEST 2014 remote refid st t when poll reach delay offset jitter == x127.127.22.1.PPS1. 0 l- 16 3770.000 -0.040 0.008 192.168.1.4 .PPS1. 1 u 1580 1600.9320.117 0.000 145.238.203.14 .INIT. 16 u- 6400.0000.000 0.000 *139.143.5.30139.143.45.112 u 67 64 377 13.171 -0.660 2.875 I suspect that this may be a feature rather than a bug, as the doc says that the atom driver must have a prefer peer. However it is not ideal. I suppose that you could use the local clock 127.127.1.x as prefer peer to prevent that ,using ntpdate in startup scripts to get within a second, but NTP would not switch to a better source if one became available. This issue was noticed as far back as 2012. Maybe earlier. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
mike cook wrote: > > Le 14 juin 2014 à 10:27, Rob a écrit : > >> The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on >> a serial port, but no date information (it does provide time, but that >> is not very useful without date). >> So I choose not to use the time info and use external (network) sources >> are used for that. This has worked before using 4.2.6p5. > > I doubt it. I have the same issue with both 4.2.6p5 and 4.2.7p444. No prefer > peer, no dice. > This is FreeBSD 8.2 > $ ntpd --version > ntpd 4.2.6p5 > ntpd 4.2.6p5@1.2349-o Mon Jul 2 04:47:51 UTC 2012 (1) > Sat Jun 14 12:35:25 CEST 2014 > remote refid st t when poll reach delay offset jitter > = > x127.127.22.1.PPS1. 0 l5 16 3770.0000.030 0.008 Ok, I checked it again and now I find that on the 4.2.6p5 I had a prefer peer as well. But I did not realize that this was crucial. I would "prefer" not to have it :-) (the test with 4.2.6p5 was done on another system, same hardware and same PPS but of course not the same config, and it is not accessible at the moment so I had to look in a backup) > I suspect that this may be a feature rather than a bug, as the doc says that > the atom driver must have a prefer peer. > However it is not ideal. It is a strange feature. Maybe it has to to with the lack of gating on the PPS clock, one really needs to have a control to tell ntpd that the signal on PPS is valid or not, which can be performed by a driver that reads the serial status. It looks like drivers now always return time, and this hardware cannot do that. It can provide PPS valid/notvalid info however. Unfortunately it always sends the PPS pulses even when they are not valid. Most such devices do that. Maybe the "prefer" peer has the special handling deep inside ntpd to enable/disable the use of the PPS? > I suppose that you could use the local clock 127.127.1.x as prefer peer to > prevent that ,using ntpdate in startup scripts to get within a second, but > NTP would not switch to a better source if one became available. I am always looking for solutions that are stable by themselves, without constant attention and trickery. Unfortunately ntpd has disappointed me many times, e.g. by just bailing out when it temporarily does not know how to handle the situation, by locking into undesirable states, or by performing short-time actions that are completely illogical. (e.g. the steering AWAY from correct time that you also noticed, or hovering at a more or less constant offset with no sign of steering towards zero) > This issue was noticed as far back as 2012. Maybe earlier. Thanks. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 8:15 AM, Rob wrote: > It is a strange feature. > You must have some method of numbering the PPS delimited seconds. > I am always looking for solutions that are stable by themselves, without > constant attention and trickery. NTP is stable. There are two perspectives: 1) The NTP software used as documented is stable without constant attention and trickery. 2) An instance of NTP can be stable if well configured. By the way, you can have more than one server marked prefer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
mike cook wrote: Le 14 juin 2014 à 10:27, Rob a écrit : The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on a serial port, but no date information (it does provide time, but that is not very useful without date). So I choose not to use the time info and use external (network) sources are used for that. This has worked before using 4.2.6p5. I doubt it. I have the same issue with both 4.2.6p5 and 4.2.7p444. No prefer peer, no dice. This is FreeBSD 8.2 $ ntpd --version ntpd 4.2.6p5 ntpd 4.2.6p5@1.2349-o Mon Jul 2 04:47:51 UTC 2012 (1) Sat Jun 14 12:35:25 CEST 2014 remote refid st t when poll reach delay offset jitter = x127.127.22.1.PPS1. 0 l5 16 3770.0000.030 0.008 You could set your best source as your prefer peer to get your PPS source taken into consideration. That actually helps! But why? I don't like to mark a source as prefer, certainly not another source than the PPS. Why is there a difference? Is this a workaround for a bug, or is this a feature and if so, what is the rationale behind it? And what is going to happen when the prefer peer happens to be unreachable? will it again go haywire then? If so, what is the point of having multiple sources for redundancy? The same happens when the prefer peer is not available at start time. Hi Now on NetBSD-6/i386 ntpd-4.2.7p444 NetBSD seems to require a reboot to get PPS working. Once up it stays synced until GPS signal is lost which happens here several times a year. /etc/ntp.conf # Sure GPS server 127.127.20.2 mode 18 prefer fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb server 127.127.22.2 minpoll 4 maxpoll 4 fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb The stratum 7 seems to prevent ntp from selecting GPS time if pps signal is lost, I tried with stratum 4 in March 2013 then a few months later set stratum 7. Mostly offset from loop_summary is about 4 us but that includes spikes of 35-40us caused by daily and weekly cron jobs. I intend to try an OCXO derived system clock when I have a spare m/b. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
David Lord wrote: > NetBSD seems to require a reboot to get PPS working. Once up > it stays synced until GPS signal is lost which happens here > several times a year. > > /etc/ntp.conf > # Sure GPS > server 127.127.20.2 mode 18 prefer > fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb > server 127.127.22.2 minpoll 4 maxpoll 4 > fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb > > The stratum 7 seems to prevent ntp from selecting GPS time > if pps signal is lost, I tried with stratum 4 in March 2013 > then a few months later set stratum 7. > > Mostly offset from loop_summary is about 4 us but that > includes spikes of 35-40us caused by daily and weekly cron > jobs. I intend to try an OCXO derived system clock when I > have a spare m/b. I can keep the offset within a microsecond on a standard Linux system once PPS locks on, but the trickery is to make it lock. This is not a standard GPS receiver (with NMEA and/or binary readout of time and status), but a dedicated GPSDO (GPS disciplined oscillator) device with PPS and 10 MHz outputs and an LCD frontpanel and LEDs that tell you the status. It has a serial port where that same info can be polled, but it does not include the date, only happens to include the time. There is no way to read things like almanac, satellite azimuth and elevation, and the like. So what I need to do is query some external servers on the internet to get within a second, and then lock on to the PPS with a clock 22 similar to what you have. But there is no "natural because it is local" server to prefer, I just need to get a majority vote from external servers, of which I have configred 5. I see no problem, really no problem, in this configuration and I wonder why the software makers do see a problem in it and want me to make a configuration decision that introduces yet more problems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Paul wrote: > On Sat, Jun 14, 2014 at 8:15 AM, Rob wrote: > >> It is a strange feature. >> > > You must have some method of numbering the PPS delimited seconds. Why can't 5 agreeing network servers be that method? >> I am always looking for solutions that are stable by themselves, without >> constant attention and trickery. > > > NTP is stable. There are two perspectives: > 1) The NTP software used as documented is stable without constant attention > and trickery. > 2) An instance of NTP can be stable if well configured. Can be, yes. But is not guaranteed to be. There are many conditions that can make it fail, but would not need to. > By the way, you can have more than one server marked prefer. So the solution is to mark everything but the PPS server marked prefer? What is the value of that? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On 2014-06-14 09:05, Rob wrote: David Lord wrote: NetBSD seems to require a reboot to get PPS working. Once up it stays synced until GPS signal is lost which happens here several times a year. /etc/ntp.conf # Sure GPS server 127.127.20.2 mode 18 prefer fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb server 127.127.22.2 minpoll 4 maxpoll 4 fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb The stratum 7 seems to prevent ntp from selecting GPS time if pps signal is lost, I tried with stratum 4 in March 2013 then a few months later set stratum 7. Mostly offset from loop_summary is about 4 us but that includes spikes of 35-40us caused by daily and weekly cron jobs. I intend to try an OCXO derived system clock when I have a spare m/b. I can keep the offset within a microsecond on a standard Linux system once PPS locks on, but the trickery is to make it lock. This is not a standard GPS receiver (with NMEA and/or binary readout of time and status), but a dedicated GPSDO (GPS disciplined oscillator) device with PPS and 10 MHz outputs and an LCD frontpanel and LEDs that tell you the status. It has a serial port where that same info can be polled, but it does not include the date, only happens to include the time. There is no way to read things like almanac, satellite azimuth and elevation, and the like. So what I need to do is query some external servers on the internet to get within a second, and then lock on to the PPS with a clock 22 similar to what you have. But there is no "natural because it is local" server to prefer, I just need to get a majority vote from external servers, of which I have configred 5. I see no problem, really no problem, in this configuration and I wonder why the software makers do see a problem in it and want me to make a configuration decision that introduces yet more problems. There may be no problem with time only messages: the NMEA driver page, http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html shows support of GLL and GGA which provide only time. Other drivers may allow similarly limited information. At startup the daemon determines time first within an NTP era, then the date, then the time of day, so it can decide if system time is within the panic gate, before it mobilizes associations to discipline time (roughly - I think - from what I have seen). Could you not put a Y or T from your DO GPS message output to your system serial port, with the PPS on the DCD pin, providing a standard PPS+GPS serial interface? This is really a product where you have to RTFM! Check the dev doc sitemap page http://www.eecis.udel.edu/~mills/ntp/html/sitemap.html for Mitigation Rules and the prefer Keyword at http://www.eecis.udel.edu/~mills/ntp/html/prefer.html (appears twice under Special Topics section) and the Ref Clock Drivers http://www.eecis.udel.edu/~mills/ntp/html/refclock.html http://www.eecis.udel.edu/~mills/ntp/html/refclock.html#list esp. http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html also read all the pages about PPS and Kernel model. The reference implementation is produced by an EE/CE research group as an accurate time control system, and is developed and supported by volunteers, some of whom may have orgs paying for some of their time. It supports everything from telephone and radio modems and extremely variable Internet sources, to commercial and national standard atomic clocks, and supports global dissemination of accurate time. How often have we all seen waves or wobbles of inaccurate time bouncing around the globe between all these different globally interconnected servers each doing their own thing? Never? There is a reason everyone uses (and bitches about) the free reference implementation, but no one has yet produced a nice user friendly product to do the same (allowing VARs to provide support contracts ;^>) And define, implement, improve, and extend a ubiquitous global standard that is effectively mandated for some purposes (what else can provide globally accurate timestamps for atomic events and high frequency trades?) Deal, eh? -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Rob wrote: David Lord wrote: NetBSD seems to require a reboot to get PPS working. Once up it stays synced until GPS signal is lost which happens here several times a year. /etc/ntp.conf # Sure GPS server 127.127.20.2 mode 18 prefer fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb server 127.127.22.2 minpoll 4 maxpoll 4 fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb The stratum 7 seems to prevent ntp from selecting GPS time if pps signal is lost, I tried with stratum 4 in March 2013 then a few months later set stratum 7. Mostly offset from loop_summary is about 4 us but that includes spikes of 35-40us caused by daily and weekly cron jobs. I intend to try an OCXO derived system clock when I have a spare m/b. I can keep the offset within a microsecond on a standard Linux system once PPS locks on, but the trickery is to make it lock. This is not a standard GPS receiver (with NMEA and/or binary readout of time and status), but a dedicated GPSDO (GPS disciplined oscillator) device with PPS and 10 MHz outputs and an LCD frontpanel and LEDs that tell you the status. It has a serial port where that same info can be polled, but it does not include the date, only happens to include the time. There is no way to read things like almanac, satellite azimuth and elevation, and the like. So what I need to do is query some external servers on the internet to get within a second, and then lock on to the PPS with a clock 22 similar to what you have. But there is no "natural because it is local" server to prefer, I just need to get a majority vote from external servers, of which I have configred 5. With almost same config as now but prefer being my most reliable local server, I setup a xtal oscillator/divider with pps output as source for type 22 driver and had no problem with ntpd. Tempco of the oscillator was too high so drift was too variable for it to be of use. David I see no problem, really no problem, in this configuration and I wonder why the software makers do see a problem in it and want me to make a configuration decision that introduces yet more problems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Le 14 juin 2014 à 16:56, Rob a écrit : > >> By the way, you can have more than one server marked prefer. > > So the solution is to mark everything but the PPS server marked prefer? > What is the value of that? The documentation, although a bit long in the tooth, does not recommend multiple preferred peers:- "While the rules do not forbid it, it does not seem useful to designate more than one peer as preferred, since the additional complexities to mitigate among them do not seem justified from on-air experience." Let's see what happens:- # muon stratum1 gps ref server 192.168.1.4 iburst minpoll 4 maxpoll 4 prefer # laurelineA GPS sync'd NTP server server 192.168.1.23 iburst minpoll 4 maxpoll 6 prefer # raspberry pi net sync'd NTP server server 192.168.1.15 iburst minpoll 4 maxpoll 6 prefer restart ntpd and let the dust settle: Sat Jun 14 18:30:56 CEST 2014 remote refid st t when poll reach delay offset jitter = o127.127.22.1.PPS1. 0 l 14 16 3770.000 -0.004 0.008 +192.168.1.4 .PPS1. 1 u 11 16 3770.8740.047 0.010 +192.168.1.23.GPS.1 u 10 16 3770.5490.054 0.051 *192.168.1.15192.168.1.23 2 u9 16 3770.9180.498 0.056 now pull 192.168.1.15. Sat Jun 14 18:36:37 CEST 2014 remote refid st t when poll reach delay offset jitter = o127.127.22.1.PPS1. 0 l2 16 3770.000 -0.006 0.008 *192.168.1.4 .PPS1. 1 u 15 16 3770.8810.044 0.017 +192.168.1.23.GPS.1 u 15 16 3770.5520.053 0.008 192.168.1.15192.168.1.23 2 u 158 1600.9140.422 0.052 192.168.1.4 gets selected and we still have PPS. So while not being categoric about it, it looks like assigning multiple prefer peers may have some merit. Mike > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
mike cook wrote: > > Le 14 juin 2014 à 16:56, Rob a écrit : >> >>> By the way, you can have more than one server marked prefer. >> >> So the solution is to mark everything but the PPS server marked prefer? >> What is the value of that? > > The documentation, although a bit long in the tooth, does not recommend > multiple preferred peers:- > "While the rules do not forbid it, it does not seem useful to designate more > than one peer as preferred, since the additional complexities to mitigate > among them do not seem justified from on-air experience." I only need a setup that remains working when one or two of the external servers quit. I do not need any "prefer" at all, but it seems the PPS driver does. For whatever reason. > So while not being categoric about it, it looks like assigning multiple > prefer peers may have some merit. Yes, I think this is what I will do. But I call it a workaround for a bug. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Brian Inglis wrote: >> I see no problem, really no problem, in this configuration and I wonder >> why the software makers do see a problem in it and want me to make a >> configuration decision that introduces yet more problems. > > There may be no problem with time only messages: the NMEA driver page, > http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html > shows support of GLL and GGA which provide only time. > Other drivers may allow similarly limited information. There is NO NMEA in or near my system! Everyone seems to think that GPS equates NMEA. Wrong. > Could you not put a Y or T from your DO GPS message output to your system > serial port, with the PPS on the DCD pin, providing a standard PPS+GPS > serial interface? The serial output of the device does not provide the date. Only the time. It is not NMEA. > This is really a product where you have to RTFM! > > Check the dev doc sitemap page > http://www.eecis.udel.edu/~mills/ntp/html/sitemap.html > for Mitigation Rules and the prefer Keyword at > http://www.eecis.udel.edu/~mills/ntp/html/prefer.html > (appears twice under Special Topics section) > and the Ref Clock Drivers > http://www.eecis.udel.edu/~mills/ntp/html/refclock.html > http://www.eecis.udel.edu/~mills/ntp/html/refclock.html#list > esp. > http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html > also read all the pages about PPS and Kernel model. Unfortunately the fact that the prefer keyword is required is buried deeply in the doc, and also it is still not clear why this restriction was added. It apparently assumes anyone who has a PPS signal also has a device that provides date and time information, which is wrong. But of course the assumptions of the main author have been wrong before. This is no problem, everyone can sometimes be wrong. But this person is a bit stubborn, as many contributors have experienced. On my other test system I had copied an example config which happens to include the prefer keyword, but it is not at all clear that ntpd will mark a PPS peer as "falseticker" BECAUSE there is no "prefer" keyword on at least one other server. (it DOES output other warnings, like that the "kod" restriction does nothing without the "limited" restriction, but nothing about this) > The reference implementation is produced by an EE/CE research group as > an accurate time control system, and is developed and supported by > volunteers, some of whom may have orgs paying for some of their time. I think the problem is not that it is free or who is going to pay. When other people would supply fixes, they would not be accepted anyway. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On 2014-06-14 01:27, Rob wrote: > Brian Inglis wrote: >> On 2014-06-13 10:17, Rob wrote: >>> I installed the ntp-dev package for Debian as recommended here to get >>> better resolution for the offset and jitter values. >>> >>> The service was started with a local PPS clock (ATOM) and a couple of >>> low-stratum external servers. The PPS was not available when ntpd >>> started, but was connected about 12 hours later. The poll intervals >>> of the external servers were at 1024 already at that time. >>> >>> Now, 4 hours after connecting the PPS, it is (still) classified as >>> a falseticker. It is less than 200us off the local clock! >>> >>> remote refid st t when poll reach delay offset >>> jitter >>> == >>> x127.127.22.0.PPS.0 l 11 16 3770.000 -0.191 >>> 0.001 >>> +xx.xxx..xxx .PPS.1 u 810 1024 377 18.5320.111 >>> 0.248 >>> -xx.xxx.xx.x 192.87.36.4 2 u 924 1024 3776.124 -1.808 >>> 0.486 >>> +xxx.xxx.x.xxx .PPS.1 u 639 1024 3773.9280.376 >>> 6.329 >>> *xxx.xx.xxx.xx .PPS.1 u 247 1024 3774.402 -0.445 >>> 0.321 >>> -xxx.xxx.xxx.xxx 192.168.2.2 2 u 964 1024 3777.7720.314 >>> 0.646 >>> >>> ind assid status conf reach auth condition last_event cnt >>> === >>>1 26409 9134 yes yes none falsetick reachable 3 >>>2 26410 941a yes yes none candidatesys_peer 1 >>>3 26411 9324 yes yes none outlyer reachable 2 >>>4 26412 941a yes yes none candidatesys_peer 1 >>>5 26413 961a yes yes none sys.peersys_peer 1 >>>6 26414 933a yes yes none outlyersys_peer 3 >>> associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event, >>> version="ntpd 4.2.7p444@1.2483-o Wed Jun 11 20:31:24 UTC 2014 (1)", >>> processor="x86_64", system="Linux/3.2.0-4-amd64", leap=00, stratum=2, >>> precision=-23, rootdelay=4.402, rootdisp=36.051, refid=193.79.237.14, >>> reftime=d7459b9c.70fe6483 Fri, Jun 13 2014 17:47:40.441, >>> clock=d745a09d.0cde151e Fri, Jun 13 2014 18:09:01.050, peer=26413, >>> tc=10, mintc=3, offset=-0.260141, frequency=-17.339, sys_jitter=0.831137, >>> clk_jitter=0.194, clk_wander=0.001 >>> >>> Why is it so picky? >>> O also observer that for the past 10 hour or so it has hovered about >>> at offsets between -200 and -400us all the time, never returning to >>> zero. Shouldn't it try to steer the offset towards zero all the time? >>> When it would, it would see that the PPS source is correct, wouldn't it? >>> The regulation proceeds very slowly at 1024 second polls, and it looks >>> like it has become worse by my upgrade from 4.2.6p5 to 4.2.7p444. >>> >>> I know I can resolve such behaviour (often) by restarting ntpd, but I >>> would like to know why it can't figure it out itself. >> >> You have not told us much about your hardware and configuration. >> >> Check your log to see if your PPS driver is being recognized as such. > > Well, see the above output. There is an entry for the ATOM driver > (127.127.22.0) which works OK but is marked a falseticker. There also > are 5 network time sources that work fine. The sampling interval has > gone up to 1024. > >> You also need a local (NMEA 127.127.20.0/Motorola 127.127.30.0/?) >> ref clock driver prefer peer (GPS?) time source to number the seconds >> from whatever is providing your PPS. > > The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on > a serial port, but no date information (it does provide time, but that > is not very useful without date). > So I choose not to use the time info and use external (network) sources > are used for that. This has worked before using 4.2.6p5. > >> You could set your best source as your prefer peer to get your >> PPS source taken into consideration. > > That actually helps! > But why? I don't like to mark a source as prefer, certainly not another > source than the PPS. > Why is there a difference? Is this a workaround for a bug, or is this > a feature and if so, what is the rationale behind it? > And what is going to happen when the prefer peer happens to be unreachable? > will it again go haywire then? If so, what is the point of having multiple > sources for redundancy? I actually disliked having to use a prefer peer for PPS as well. So I modified the source code to remove that requirement. As long as there's a source that is acceptable to the selection algorithm (and marked with the *) then PPS turns on. No perfer peer necessary. I had lots of trouble with preferred peers disappearing and the ATOM driver would never come back even after the preferred peer came back. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
A C wrote: > I actually disliked having to use a prefer peer for PPS as well. So I > modified the source code to remove that requirement. As long as there's > a source that is acceptable to the selection algorithm (and marked with > the *) then PPS turns on. No perfer peer necessary. I had lots of > trouble with preferred peers disappearing and the ATOM driver would > never come back even after the preferred peer came back. That is great! Do you have a patch file for that? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 12:42 PM, Brian Inglis < brian.ing...@systematicsw.ab.ca> wrote: > There may be no problem with time only messages: the NMEA driver page, > shows support of GLL and GGA which provide only time. > Other drivers may allow similarly limited information. > The date has to be provided at some point in some fashion. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On 2014-06-14 12:03, Rob wrote: Brian Inglis wrote: I see no problem, really no problem, in this configuration and I wonder why the software makers do see a problem in it and want me to make a configuration decision that introduces yet more problems. There may be no problem with time only messages: the NMEA driver page, http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html shows support of GLL and GGA which provide only time. Other drivers may allow similarly limited information. There is NO NMEA in or near my system! Everyone seems to think that GPS equates NMEA. Wrong. Could you not put a Y or T from your DO GPS message output to your system serial port, with the PPS on the DCD pin, providing a standard PPS+GPS serial interface? The serial output of the device does not provide the date. Only the time. It is not NMEA. That was just an example that I was aware of. It demonstrates that ntpd doesn't need the date. Check the driver page (and code) for your device. This is really a product where you have to RTFM! Check the dev doc sitemap page http://www.eecis.udel.edu/~mills/ntp/html/sitemap.html for Mitigation Rules and the prefer Keyword at http://www.eecis.udel.edu/~mills/ntp/html/prefer.html (appears twice under Special Topics section) and the Ref Clock Drivers http://www.eecis.udel.edu/~mills/ntp/html/refclock.html http://www.eecis.udel.edu/~mills/ntp/html/refclock.html#list esp. http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html also read all the pages about PPS and Kernel model. Unfortunately the fact that the prefer keyword is required is buried deeply in the doc, and also it is still not clear why this restriction was added. It apparently assumes anyone who has a PPS signal also has a device that provides date and time information, which is wrong. But of course the assumptions of the main author have been wrong before. This is no problem, everyone can sometimes be wrong. But this person is a bit stubborn, as many contributors have experienced. On my other test system I had copied an example config which happens to include the prefer keyword, but it is not at all clear that ntpd will mark a PPS peer as "falseticker" BECAUSE there is no "prefer" keyword on at least one other server. (it DOES output other warnings, like that the "kod" restriction does nothing without the "limited" restriction, but nothing about this) The reference implementation is produced by an EE/CE research group as an accurate time control system, and is developed and supported by volunteers, some of whom may have orgs paying for some of their time. I think the problem is not that it is free or who is going to pay. When other people would supply fixes, they would not be accepted anyway. I have seen platform, driver, and doc patches accepted from many contributors. But not when they would mess with the main discipline control engineering, which may be a matter of direction and hard won experience across hostile environments of many kinds. Sometimes a blunt rejection is easier and may be kinder than a lengthy, rigorous analysis andexplanation of why a simple minded approach or idea is boneheadedly, obviously, stupid to the design engineer. One may have to be prepared to patch the simulator, run all the regression tests, and analyze the results, to prove rigorously that a proposed control change would not adversely affect any possible setup. (My first manager used to be a Control Systems EE/CS prof before he was lured into commercial R&D, and everything from spelling, wording, grammar, code, comments, tests, and docs would get the blue and red pen treatment.) -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On 2014-06-14 12:03, Rob wrote: Brian Inglis wrote: I see no problem, really no problem, in this configuration and I wonder why the software makers do see a problem in it and want me to make a configuration decision that introduces yet more problems. There may be no problem with time only messages: the NMEA driver page, http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html shows support of GLL and GGA which provide only time. Other drivers may allow similarly limited information. There is NO NMEA in or near my system! Everyone seems to think that GPS equates NMEA. Wrong. Could you not put a Y or T from your DO GPS message output to your system serial port, with the PPS on the DCD pin, providing a standard PPS+GPS serial interface? The serial output of the device does not provide the date. Only the time. It is not NMEA. That was just an example that I was aware of. It demonstrates that ntpd doesn't need the date. Check the driver page (and code) for your device. This is really a product where you have to RTFM! Check the dev doc sitemap page http://www.eecis.udel.edu/~mills/ntp/html/sitemap.html for Mitigation Rules and the prefer Keyword at http://www.eecis.udel.edu/~mills/ntp/html/prefer.html (appears twice under Special Topics section) and the Ref Clock Drivers http://www.eecis.udel.edu/~mills/ntp/html/refclock.html http://www.eecis.udel.edu/~mills/ntp/html/refclock.html#list esp. http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html also read all the pages about PPS and Kernel model. Unfortunately the fact that the prefer keyword is required is buried deeply in the doc, and also it is still not clear why this restriction was added. It apparently assumes anyone who has a PPS signal also has a device that provides date and time information, which is wrong. But of course the assumptions of the main author have been wrong before. This is no problem, everyone can sometimes be wrong. But this person is a bit stubborn, as many contributors have experienced. On my other test system I had copied an example config which happens to include the prefer keyword, but it is not at all clear that ntpd will mark a PPS peer as "falseticker" BECAUSE there is no "prefer" keyword on at least one other server. (it DOES output other warnings, like that the "kod" restriction does nothing without the "limited" restriction, but nothing about this) The reference implementation is produced by an EE/CE research group as an accurate time control system, and is developed and supported by volunteers, some of whom may have orgs paying for some of their time. I think the problem is not that it is free or who is going to pay. When other people would supply fixes, they would not be accepted anyway. I have seen platform, driver, and doc patches accepted from many contributors. But not when they would mess with the main discipline control engineering, which may be a matter of direction and hard won experience across hostile environments of many kinds. Sometimes a blunt rejection is easier and may be kinder than a lengthy, rigorous analysis andexplanation of why a simple minded approach or idea is boneheadedly, obviously, stupid to the design engineer. One may have to be prepared to patch the simulator, run all the regression tests, and analyze the results, to prove rigorously that a proposed control change would not adversely affect any possible setup. (My first manager used to be a Control Systems EE/CS prof before he was lured into commercial R&D, and everything from spelling, wording, grammar, code, comments, tests, and docs would get the blue and red pen treatment.) -- Take care. Thanks, Brian Inglis -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 2:03 PM, Rob wrote: > > Everyone seems to think that GPS equates NMEA. Wrong. > ... > It apparently assumes anyone who has a PPS signal also has a > device that provides date and time information, which is wrong. > ... > But of course the assumptions of the main author have been wrong > nom...@example.com thinks you can run NTP as you imagine it should work rather than reading the documentation ... wrong. You have to be able to number the seconds. If you have any source of date/time you can number the seconds. These include: The network. A supported clock type that provides date+time. Your TOD clock. A clock on the wall. Since you're connected to the network your problem is solved. You will need to make some effort to understand how NTP works though. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 10:56 AM, Rob wrote: > What is the value of that? It can solve certain problems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On 14/06/14 14:21, David Lord wrote: Mostly offset from loop_summary is about 4 us but that includes spikes of 35-40us caused by daily and weekly cron jobs. I intend to try an OCXO derived system clock when I have a spare m/b. Offset is from measured time, not from true time. The extra load is probably compromising the measurements, not the accuracy of the clock. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On 2014-06-14 12:57, Rob wrote: > A C wrote: >> I actually disliked having to use a prefer peer for PPS as well. So I >> modified the source code to remove that requirement. As long as there's >> a source that is acceptable to the selection algorithm (and marked with >> the *) then PPS turns on. No perfer peer necessary. I had lots of >> trouble with preferred peers disappearing and the ATOM driver would >> never come back even after the preferred peer came back. > > That is great! Do you have a patch file for that? > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > > No, I don't have it in patch form. I'll need to get the machine back up and running (just moved to a new place) but I can send along the modifications I made (just a few lines) directly to you. It's an older version of 4.2.7 (somewhere around p270) but it probably applies to the later versions, too. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
David Woolley wrote: On 14/06/14 14:21, David Lord wrote: Mostly offset from loop_summary is about 4 us but that includes spikes of 35-40us caused by daily and weekly cron jobs. I intend to try an OCXO derived system clock when I have a spare m/b. Offset is from measured time, not from true time. The extra load is probably compromising the measurements, not the accuracy of the clock. Hi These are double spikes, one +ve followed by a similar -ve spike. There used to be obvious wide +ve/-ve excursions when the case was in full sunlight but that problem was solved by shielding from the sun. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
A C wrote: > On 2014-06-14 12:57, Rob wrote: >> A C wrote: >>> I actually disliked having to use a prefer peer for PPS as well. So I >>> modified the source code to remove that requirement. As long as there's >>> a source that is acceptable to the selection algorithm (and marked with >>> the *) then PPS turns on. No perfer peer necessary. I had lots of >>> trouble with preferred peers disappearing and the ATOM driver would >>> never come back even after the preferred peer came back. >> >> That is great! Do you have a patch file for that? >> >> ___ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions >> >> > > No, I don't have it in patch form. I'll need to get the machine back up > and running (just moved to a new place) but I can send along the > modifications I made (just a few lines) directly to you. It's an older > version of 4.2.7 (somewhere around p270) but it probably applies to the > later versions, too. Ok, don't hesitate to post it here when you have found the time to locate it. Others reading here may be interested as well! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Brian Inglis wrote: > On 2014-06-14 12:03, Rob wrote: >> Brian Inglis wrote: I see no problem, really no problem, in this configuration and I wonder why the software makers do see a problem in it and want me to make a configuration decision that introduces yet more problems. >>> >>> There may be no problem with time only messages: the NMEA driver page, >>> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html >>> shows support of GLL and GGA which provide only time. >>> Other drivers may allow similarly limited information. >> >> There is NO NMEA in or near my system! >> Everyone seems to think that GPS equates NMEA. Wrong. >> >>> Could you not put a Y or T from your DO GPS message output to your system >>> serial port, with the PPS on the DCD pin, providing a standard PPS+GPS >>> serial interface? >> >> The serial output of the device does not provide the date. >> Only the time. It is not NMEA. > > That was just an example that I was aware of. > It demonstrates that ntpd doesn't need the date. > Check the driver page (and code) for your device. There is no driver for this device in ntpd. I have considered writing something that puts the time in SHM, but it will be a kludge as it will have to use the system date. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Paul wrote: > On Sat, Jun 14, 2014 at 2:03 PM, Rob wrote: > >> >> Everyone seems to think that GPS equates NMEA. Wrong. >> ... >> It apparently assumes anyone who has a PPS signal also has a >> device that provides date and time information, which is wrong. >> ... >> But of course the assumptions of the main author have been wrong >> > > nom...@example.com thinks you can run NTP as you imagine it should work > rather than reading the documentation ... wrong. > > You have to be able to number the seconds. If you have any source of > date/time you can number the seconds. > These include: > The network. > A supported clock type that provides date+time. > Your TOD clock. > A clock on the wall. > > Since you're connected to the network your problem is solved. You will > need to make some effort to understand how NTP works though. Maybe you can help me? The following is in the documentation: As the select algorithm scans the associations for selectable candidates, the modem driver and local driver are segregated for later, but only if not designated a prefer peer. If so designated, the driver is included among the candidate population. In addition, if orphan parents are found, the parent with the lowest metric is segregated for later; the others are discarded. For this purpose the metric is defined as the four-octet IPv4 address or the first four octets of the hashed IPv6 address. The resulting candidates, including any prefer peers found, are processed by the select algorithm to produce a possibly empty set of truechimers. As previously noted, the cluster algorithm casts out outliers, leaving the survivor list for later processing. The survivor list is then sorted by increasing root distance and the first entry temporarily designated the system peer. At this point the following contributors to the system clock discipline may be available: (potential) system peer, if there are survivors; orphan parent, if present; local driver, if present; modem driver, if present; prefer peer, if present; PPS driver, if present. The mitigation algorithm proceeds in three steps in turn. 1. If there are no survivors, the modem driver becomes the only survivor if there is one. If not, the local driver becomes the only survivor if there is one. If not, the orphan parent becomes the only survivor if there is one. If the number of survivors at this point is less than the minsane option of the tos command, the algorithm is terminated and the system variables remain unchanged. Note that minsane is by default 1, but can be set at any value including 0. 2. If the prefer peer is among the survivors, it becomes the system peer and its offset and jitter are inherited by the corresponding system variables. Otherwise, the combine algorithm computes these variables from the survivor population. 3. If there is a PPS driver and the system clock offset at this point is less than 0.4 s, and if there is a prefer peer among the survivors or if the PPS peer is designated as a prefer peer, the PPS driver becomes the system peer and its offset and jitter are inherited by the system variables, thus overriding any variables already computed. Note that a PPS driver is present only if PPS signals are actually being received and enabled by the associated driver. If none of the above is the case, the data are disregarded and the system variables remain as they are. After reading this, especially the sentence after 3., 3rd line, I believed I could mark the PPS as the prefer peer and not the other sources, and it would work. But it doesn't. I need to make ALL SIX time sources prefer to make it work. (or at least the five NTP sources) Can you please explain? I don't mind if the situation is complex but that does not mean the documentation has to be written like this. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Paul wrote: > On Sat, Jun 14, 2014 at 12:42 PM, Brian Inglis < > brian.ing...@systematicsw.ab.ca> wrote: > >> There may be no problem with time only messages: the NMEA driver page, >> shows support of GLL and GGA which provide only time. >> Other drivers may allow similarly limited information. >> > > The date has to be provided at some point in some fashion. Yes, I think the only thing I can do is get the time from the device and the existing system date, combine the two and feed it back into ntpd as a valid time. But that will fail when the system date somehow gets reset e.g. because of a failing battery. I thought I could make the system able to independently recover from this situation by only using external NTP sources and let ntpd do its usual thing of determining valid time from about 5 external sources, and once it has done that to within a few hundred milliseconds lock on the PPS signal. But apparently there has been someone who decided that this is a bad idea and I need to "prefer" some external source. Which I rather not do, because the whole setup will dramatically fail when that source is not available, even for a while. A workaround is to "prefer" ALL the sources, but that is just a workaround. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sun, Jun 15, 2014 at 2:29 AM, Rob wrote: > Maybe you can help me? The following is in the documentation: This works using 4.2.7p440. I don't expect it's too version specific. It's the simplest solution. Season start-up to taste. root@bbb2# ntpq -p remote refid st t when poll reach delay offset jitter == oPPS(0) .GPPS. 0 l68 3770.0000.015 0.007 *LOCAL(0).LOCL. 12 l 468 400.0000.000 0.004 root@bbb2# ntpq -p nub remote refid st t when poll reach delay offset jitter == oPPS(0) .GPPS. 0 l68 3770.0000.000 0.002 *ntpa.GPPS. 1 s58 3760.1760.007 0.010 +black .GPPS. 1 s18 3770.167 -0.002 0.003 +rPi1.GPPS. 1 s58 3760.2030.059 0.057 +ntp1.GPS.1 u68 3770.6660.129 0.185 +bbb2.GPPS. 1 u58 3770.390 -0.081 0.008 t3500-6 .GPPS. 1 u 33 64 377 36.0322.172 0.358 Of course the better solution is to get a more capable GPSDO. I recommend a Fury which shows that NMEA can deliver low jitter results and will provide many days of hold-over. root@ntpa# ntpq -p remote refid st t when poll reach delay offset jitter == oPPS(0) .GPPS. 0 l68 3770.0000.001 0.002 *GPS_NMEA(0) .FURY. 0 l68 3770.000 -0.049 0.013 ... Finally you can rethink your (problem,solution). For most folks that want a local stratum 1 I'd suggest getting a Laureline -- [michael.cook at sfr.fr ] (I suspect) reviewed his second generation unit a few days ago. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Paul wrote: > On Sun, Jun 15, 2014 at 2:29 AM, Rob wrote: > >> Maybe you can help me? The following is in the documentation: > > > > This works using 4.2.7p440. I don't expect it's too version specific. > It's the simplest solution. Season start-up to taste. Where is your config? Did you put prefer on the PPS and not on another source? this document seems to claim that is possible, and I would think it is a config that people might use. > Of course the better solution is to get a more capable GPSDO. I recommend > a Fury which shows that NMEA can deliver low jitter results and will > provide many days of hold-over. > > root@ntpa# ntpq -p > remote refid st t when poll reach delay offset > jitter > == > oPPS(0) .GPPS. 0 l68 3770.0000.001 > 0.002 > *GPS_NMEA(0) .FURY. 0 l68 3770.000 -0.049 > 0.013 > ... > > Finally you can rethink your (problem,solution). For most folks that want > a local stratum 1 I'd suggest getting a Laureline -- [michael.cook at sfr.fr > ] (I suspect) reviewed his second generation unit a few days ago. So you suggest that instead of fixing the bug in NTP we should buy new GPSDOs? Why is that preferable? Wouldn't the world be better off when the bug was fixed instead? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sun, Jun 15, 2014 at 12:11 PM, Rob wrote: > > Did you put prefer on the PPS and not on another source? > That was the complete output of ntpq. The local clock is marked prefer; it can reliably number the seconds. This is just a demonstration and I think it unwise to run this way in production. > So you suggest that instead of fixing the bug in NTP we should buy > new GPSDOs? > It's your opinion it's a bug. It doesn't seem like one to me. I think you want a feature enhancement not a bug fix. It could be argued that If you had a "correct" installation you wouldn't have this "problem". ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Paul wrote: > On Sun, Jun 15, 2014 at 12:11 PM, Rob wrote: > >> >> Did you put prefer on the PPS and not on another source? >> > > That was the complete output of ntpq. The local clock is marked prefer; it > can reliably number the seconds. This is just a demonstration and I think > it unwise to run this way in production. Note that we do not have a local clock, only PPS. Also note that the requirement to number the seconds can be satisfied with a number of external NTP servers that ntpd can evaluate and can obtain a majority vote from. I want to use that majority vote, not one particular server. Is that so hard? > >> So you suggest that instead of fixing the bug in NTP we should buy >> new GPSDOs? >> > > It's your opinion it's a bug. It doesn't seem like one to me. I think you > want a feature enhancement not a bug fix. I think it is not a feature enhancement but a feature removal. Probably the "prefer" keyword was overused in this case. There should not have been any relation between "number the seconds" and "prefer". That feature must be removed, and maybe some other feature added, like a "number" keyword, that you can attach to one clock. When it is not used, the "number" would be done by the usual majority vote of servers. > It could be argued that If you had a "correct" installation you wouldn't > have this "problem". The installation is correct, only the program is mistreating it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Mon, Jun 16, 2014 at 3:26 AM, Rob wrote: > Note that we do not have a local clock, only PPS. > I'm starting to wonder if you simply refuse to read the documentation or you're just trolling to cause trouble. I want to use that majority vote, not one particular server. > Is that so hard? > There is no "majority" vote on numbering the seconds. > The installation is correct, only the program is mistreating it. > I'm starting to wonder if you willfully choose to pretend NTP is something other than what it is so you can complain or you're just trolling to cause trouble. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Paul wrote: > On Mon, Jun 16, 2014 at 3:26 AM, Rob wrote: > >> Note that we do not have a local clock, only PPS. >> > > I'm starting to wonder if you simply refuse to read the documentation or > you're just trolling to cause trouble. To avoid further confusion, I have put you on my ignore list. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
Get the fudge time(s) right, prefer the PPS, increase mindist. -- E-Mail Sent to this address will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Wed, Jun 18, 2014 at 4:04 PM, E-Mail Sent to this address will be added to the BlackLists wrote: > prefer the PPS, > The point was that you can't prefer the PPS driver. "While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required, ordinarily a radio clock operated as a primary reference (stratum 1) source; however, another NTP time server can be used as well. For this purpose, the auxiliary source should be specified as the prefer peer" The local clock appears to be suffcient given a correct configuration and time/date bootstrap. Assuming the local clock driver doesn't change (and isn't dropped since it's deprecated). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
