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
[ntp:questions] Al madinah international university opening apply for university colleges (September season)
MR/ MiSS * al madinah international university which win dependence Malaysian Ministry of Higher Education Malaysia (MOHE) and also winning the adoption of all academic programs and courses, the university that are approved by the Malaysian funds and private academy, which deals with quality control and efficiency Academy, known for short as [MQA ] to congratulate you on the occasion of the new academic September year - 2014 . Its pleasure to tell you that the university opening apply for university colleges. The flowing colleges : * faculty of Islamic Sciences * faculty of languages *faculty of computer Science . *faculty of education . * Faculty of Science, Finance and Administration . *Language center *.faculty of engineering ( soon) The university offer : * Bachelor degree * Master degree * PH degree Both online and on campus learning for more information you can visit http://www.mediu.edu.my/ar/admissions/requirments for more information about Bachelor degree http://www.mediu.edu.my/ar/admissions/undergraduateprograms for more information about master degree http://www.mediu.edu.my/ar/admissions/postgraduateprograms Best Regard international city university //www.mediu.edu.my/ar/ ___ 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 Pool Server Costs me $40/mo in Bandwidth--is
"Jason Rabel" writes: > No client should be querying more than once every second (or maybe > it's every 2 seconds), that is the speed iburst does. Regular query > intervals would be much longer. Yes, and remember we live in a world of NAT. While there is much to be said for running "your" NTP servers that talk to outside NTP servers and having all of your other NTP clients talk to your NTP servers, some folks don't do this, and that means their clients can send a lot of queries to external servers and these requests will be coming from (different ports from) a single IP address (due to NAT). Then again, there are also broken implementations out there that will badly misbehave. It would be useful to see if there was any way to identify what's going on with the culprit IPs. H ___ 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 Pool Server Costs me $40/mo in Bandwidth--is
Brian, A few things you did not mention in your post or your article... What bandwidth setting (Net Speed) did you specify on the NTP Pool website for your server? What Zone(s) is it listed in? Also, can you provide a link to your NTP Pool server's page? The URL would look something as follows (this is my server): http://www.pool.ntp.org/scores/216.230.228.242 I have my net speed set to 10Mbit and my server averages about 20 NTP packets per second and can peak up to 70/sec under normal traffic. I could bump it higher, my colo'ed server includes 10TB of bandwidth a month (and I'm nowhere near that), but I prefer to incrementally bump it up and see how traffic is affected. What does your NTP configuration look like? Specifically any 'restrict' and 'discard' lines would be most helpful. As someone else already posted, you should have some minimal settings configured to prevent someone 'pounding' your server, please check the following page: http://www.eecis.udel.edu/~mills/ntp/html/accopt.html There seems to be a lot of discussion about whether to use the KoD setting or not (for various reasons). I personally fall into the group that prefers / recommends NOT to use that variable and instead use various rate limiting methods to prevent abuse (whether intentional or accidental). If you are running Linux you can do rate limiting with iptables rather easy too. No client should be querying more than once every second (or maybe it's every 2 seconds), that is the speed iburst does. Regular query intervals would be much longer. ___ 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?
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 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 Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
On 2014-06-14 12:59, brian.cun...@gmail.com wrote: Is there a suggested way to rate-limit queries by broken clients? Running an NTP Pool Server costs me $40/month in Amazon AWS Outbound Bandwidth (if you want the full scoop, read here: http://pivotallabs.com/ntp-server-costing-500year/ ). I suspect that broken NTP clients are part of the problem (for example, 2 IP addresses in Puerto Rico query my server on the average 11.5 times per second--eliminating just those 2 would save me almost $1/month). Are there any other techniques people have found to be helpful? I like running a server for the NTP Pool, I just don't want to spend a lot of money doing it. p.s. No, my server isn't being used in a reflection attack: monlist is disabled, and the NTP traffic load is symmetric. Everyone should have "restrict default kod limited"... but often this is boneheaded configuration or bad rookie software, that does not respect the KOD packets or RATE codes, as others have found, so other than asking AWS to block those abusers, you can only take down that name and address (many bozos prefer using IP addresses, for many bozo reasons; as opposed to engineers using IP addresses for engineering reasons), and set up another or elsewhere. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
On 2014-06-14 12:59, brian.cun...@gmail.com wrote: Is there a suggested way to rate-limit queries by broken clients? Running an NTP Pool Server costs me $40/month in Amazon AWS Outbound Bandwidth (if you want the full scoop, read here: http://pivotallabs.com/ntp-server-costing-500year/ ). I suspect that broken NTP clients are part of the problem (for example, 2 IP addresses in Puerto Rico query my server on the average 11.5 times per second--eliminating just those 2 would save me almost $1/month). Are there any other techniques people have found to be helpful? I like running a server for the NTP Pool, I just don't want to spend a lot of money doing it. p.s. No, my server isn't being used in a reflection attack: monlist is disabled, and the NTP traffic load is symmetric. Everyone should have "restrict default kod limited"... but often this is boneheaded configuration or bad rookie software, that does not respect the KOD packets or RATE codes, as others have found, so other than asking AWS to block those abusers, you can only take down that name and address (many bozos prefer using IP addresses, for many bozo reasons; as opposed to engineers using IP addresses for engineering reasons), and set up another or elsewhere. -- 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 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?
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 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
[ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
Hi All, Is there a suggested way to rate-limit queries by broken clients? Running an NTP Pool Server costs me $40/month in Amazon AWS Outbound Bandwidth (if you want the full scoop, read here: http://pivotallabs.com/ntp-server-costing-500year/ ). I suspect that broken NTP clients are part of the problem (for example, 2 IP addresses in Puerto Rico query my server on the average 11.5 times per second--eliminating just those 2 would save me almost $1/month). Are there any other techniques people have found to be helpful? I like running a server for the NTP Pool, I just don't want to spend a lot of money doing it. Thanks, --Brian p.s. No, my server isn't being used in a reflection attack: monlist is disabled, and the NTP traffic load is symmetric. ___ 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?
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?
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?
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?
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?
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?
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?
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 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?
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?
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
