Re: [ntp:questions] LOCL clock reachability not 377?
Paul wrote: On Tue, Aug 26, 2014 at 9:54 AM, Phil W Lee p...@lee-family.me.uk wrote: Paul tik-...@bodosom.net considered Mon, 25 Aug 2014 19:13:45 GMT the perfect time to write: it's just a wrapper (syntactic sugar) around the real API. Thre's not much point in adding that capability without the files to enable it to be used. See above. e.g. from timepps.h: time_pps_fetch (arguments) ...[set-up] ret = ioctl(handle, PPS_FETCH, __fdata); ...[side-effects] return ret; } OK, so in this case maybe - timepps.h should indeed be included in the NTP sources - NTP's configure should not just test the presence of this file to figure out if PPS is supported on the target system, or not - Eventually the NTP binaries PPS support should always be built in and at start up a PPS ioctl could be issued. The result (failed or not) should indicate if PPS is actually supported by the system the software is running on. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Tue, Aug 26, 2014 at 9:54 AM, Phil W Lee p...@lee-family.me.uk wrote: Paul tik-...@bodosom.net considered Mon, 25 Aug 2014 19:13:45 GMT the perfect time to write: it's just a wrapper (syntactic sugar) around the real API. Thre's not much point in adding that capability without the files to enable it to be used. See above. e.g. from timepps.h: time_pps_fetch (arguments) ...[set-up] ret = ioctl(handle, PPS_FETCH, __fdata); ...[side-effects] return ret; } ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html The Debian package is still at p448 but I downloaded the source tarball to have a peek in it, and as far as I understand this change it is not going to solve one of my current issues... (maybe it could have if the fudge time2 could be specified in milliseconds?) All the time variables are fixed-point decimals in seconds - you should be able to say 0.001 to mean a millisecond (or -0.001 if you need to go the other direction). Should. But: if (pp-sloppyclockflag CLK_FLAG1) up-max_delta = 0; else if (pp-fudgetime2 1. || pp-fudgetime2 86400.) up-max_delta = 4*3600; else up-max_delta = (time_t)floor(pp-fudgetime2 + 0.5); ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Brian Inglis brian.ing...@systematicsw.ab.ca wrote: As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd Then that better be corrected! It is hogwash. The SHM driver has existed much longer than gpsd timekeeping. In 2005 or 2006, I added timesyncing to gpsd. Before that, it was only communicating with its clients. It conveyed the current time, but did not sync the system time. I added support in gpsd to sync the system time, and I decided to do that via the existing ntpd and the existing SHM driver. At that time it appeared to be out-of-the-question to add a new driver to ntpd (the way it has been done now). The SHM driver is NOT the ancient way to talk to gpsd. It is a driver that existed, that I used, and maybe the gpsd users outnumber all other uses of the SHM driver. But it is in no way related to gpsd. : fudge time2 may predate the panic gate threshold override in the daemon, or maybe just uses that to control whether the time is believed at startup. How about setting fudge flag1 0 time2 1, and at startup or when unsynced, have your monitoring program set the valid flag, and set all the timestamp values to zero? If you are currently leaving your valid flag clear, setting valid and zeroing the timestamps may make the driver read and ignore your clock until it starts providing good data, and also let the daemon know. Frankly I'm getting a bit tired of trying all those different tricks to make ntpd jump through hoops, and then test it under all different circumstances to see what new undesirable effect I have introduced. This whole idea of using a valid time from a source that cannot provide it, just to declare another time source (the PPS) as valid just sucks. If you have been following the thread (and the other one) you have seen that everything tried sofar at first appeared to be working, but then later made ntpd do undesirable things. The algorithms for clock selection and prefer peer declaration are just too complicated to be used as part of a simple valid/not-valid selection like this. Hopefully Martin's ideas for cleaning this up get implemented. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob writes: Harlan wrote: All the time variables are fixed-point decimals in seconds - you should be able to say 0.001 to mean a millisecond (or -0.001 if you need to go the other direction). Should. But: if (pp-sloppyclockflag CLK_FLAG1) up-max_delta = 0; else if (pp-fudgetime2 1. || pp-fudgetime2 86400.) up-max_delta = 4*3600; else up-max_delta = (time_t)floor(pp-fudgetime2 + 0.5); This is a question for Juergen... H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob writes: Brian Inglis brian.ing...@systematicsw.ab.ca wrote: As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd Then that better be corrected! It is hogwash. I've got a couple of folks wondering about driver46. I'll let Juergen discuss this. He has reasons for suggesting that driver46 is a better way to communicate with gpsd. I don't recall what they were, offhand. SHM has its uses, and it has its problems. Some have also suggested using chrony pipes as a way to get timestamps in to NTP. Now I'm trying to remember another discussion where the issue is 'we have a refclock that will give us the time but not the date.' as I recall that has bearing on the SHM driver. Personally, I don't understand why we should support these devices, but apparently it's important to some folks and perhaps I just don't understand the issue. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Mon, Aug 25, 2014 at 4:44 AM, Harlan Stenn st...@ntp.org wrote: Personally, I don't understand why we should support these devices, but apparently it's important to some folks and perhaps I just don't understand the issue. You have to draw the line somewhere. Perhaps the ntp developers could use voting of some sort to make assess the level of interest. When you read the driver notes it seems that people with unique devices wrote drivers. Maybe it was easier back in the day. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: Rob writes: Brian Inglis brian.ing...@systematicsw.ab.ca wrote: As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd Then that better be corrected! It is hogwash. I've got a couple of folks wondering about driver46. I'll let Juergen discuss this. He has reasons for suggesting that driver46 is a better way to communicate with gpsd. I don't recall what they were, offhand. That may well be true, but there is no reason whatsoever to suggest that driver 28 is the ancient way to talk to gpsd. It has never been true. Driver 28 was not written as a way to talk to gpsd. Statements like that belong in the gpsd documentation, where it could be written that using SHM is the ancient way to talk to ntpd when they like. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: Now I'm trying to remember another discussion where the issue is 'we have a refclock that will give us the time but not the date.' as I recall that has bearing on the SHM driver. Personally, I don't understand why we should support these devices, but apparently it's important to some folks and perhaps I just don't understand the issue. The issue was that we have devices that provide PPS, status and time but not date, and that ntpd has no way of supporting those devices by using only the PPS and status information. The way PPS is validated forces one to have a device that provides date and time. One cannot get date and time from the internet (NTP) and get PPS and its status from a local device. Also, the evaluation of status is too slow because it is filtered like date/time information. I agree that those devices are probably rare on the current market, and there is no desire from the ntpd developers to directly support them. But it would be nice when the strange quirks that were built in the software and that hinder the support of those devices would be removed. As earlier discussion shows, the particular problem encountered here also affects other setups, e.g. with two (redundant) PPS clocks on the same system. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: Harlan Stenn st...@ntp.org wrote: Paul wrote: To carp yet again: you should add timepps.h to the tar ball and stick to that. Leave the package building to the distributions. If people want/need more current features they should learn how to build the current dev source and you should make that a LOT easier by including timepps.h for Linux because it's never going to be in Debian or derived distros. [...] Note that this is not a Debian-specific problem. Other distributions suffer from that timepps.h issue just as well. I agree that it should be in the ntp source when it is not going to be in the standard set of header files for Linux. Since current Linux kernels *do* support PPS, and timepps.h is a valid interface to use it, does anyone know *why* timepps.h isn't in the standard set of header files for Linux, and is never going to be? Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn wrote: Rob writes: Harlan wrote: All the time variables are fixed-point decimals in seconds - you should be able to say 0.001 to mean a millisecond (or -0.001 if you need to go the other direction). Should. But: if (pp-sloppyclockflag CLK_FLAG1) up-max_delta = 0; else if (pp-fudgetime2 1. || pp-fudgetime2 86400.) up-max_delta = 4*3600; else up-max_delta = (time_t)floor(pp-fudgetime2 + 0.5); This is a question for Juergen... H Please note the 4 hours limitation has already been discussed back in 2005, with no valuable result: clocktime() needs work https://bugs.ntp.org/417 In 2013 I opened another bugzilla issue to get SHM improved and some of its limitations removed: Request for a more versatile shared memory (SHM) refclock driver http://bugs.ntp.org/show_bug.cgi?id=2470 Now Juergen Perlinger has worked on Bug 2622 which also was due to this ugly 4 hours limitation: Synchronisation problem using SHM when time difference is more than four hours https://bugs.ntp.org/show_bug.cgi?id=2622 I haven't looked ath Juergen's changes, but I hope and trust he has improved the SHM driver, which is IMO a good and versatile interface to ntpd. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Mon, Aug 25, 2014 at 12:00 PM, Martin Burnicki martin.burni...@meinberg.de wrote: Since current Linux kernels *do* support PPS, and timepps.h is a valid interface to use it, does anyone know *why* timepps.h isn't in the standard set of header files for Linux, and is never going to be? The Debian maintainers think it's the job of the kernel developers to provide it and the kernel developers [my speculation, the result of reading between the lines] think it's redundant because it's just a wrapper (syntactic sugar) around the real API. Maybe they covertly agree that since NTP is (perhaps) the only software using the RFC-style interface it should provide timepps.h ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 24/08/14 05:43, Rob wrote: The issues #2 and #3 could have been avoided by just naming the package ntp, at a higher version number. Then one could install and track the development version by adding the proper repository I don't think that is going to be acceptable. The correct way is to use the provides mechanism, so that installing the package will satisfy the dependencies. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
David Woolley david@ex.djwhome.demon.invalid wrote: On 24/08/14 05:43, Rob wrote: The issues #2 and #3 could have been avoided by just naming the package ntp, at a higher version number. Then one could install and track the development version by adding the proper repository I don't think that is going to be acceptable. Why not? Is that an issue with Debian's way of handling repositories? The correct way is to use the provides mechanism, so that installing the package will satisfy the dependencies. I manually fixed it like that on the previously downloaded sources (will have to do that again when I download the newest version), but I still find it a nuisance that the service has a different name for no real reason (and introducing a bug while at it). Notice that /etc/init.d/ntp was renamed to /etc/init.d/ntp-dev, but there has been no such rename of ntpd to ntpd-dev, ntpq to ntpq-dev, etc. So, why? The package already conflicts with ntp. So you cannot install ntp and ntp-dev at the same time. I wonder why it then still has to be renamed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html The Debian package is still at p448 but I downloaded the source tarball to have a peek in it, and as far as I understand this change it is not going to solve one of my current issues... (maybe it could have if the fudge time2 could be specified in milliseconds?) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-08-24 05:12, Rob wrote: Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html The Debian package is still at p448 but I downloaded the source tarball to have a peek in it, and as far as I understand this change it is not going to solve one of my current issues... (maybe it could have if the fudge time2 could be specified in milliseconds?) fudge time* are seconds as doubles so you can include your cable delay in ns. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2014-08-24 05:12, Rob wrote: Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html The Debian package is still at p448 but I downloaded the source tarball to have a peek in it, and as far as I understand this change it is not going to solve one of my current issues... (maybe it could have if the fudge time2 could be specified in milliseconds?) fudge time* are seconds as doubles so you can include your cable delay in ns. This specific value is used as a maximal offset between supplied time and system time and is rounded to seconds (I don't know why). It could maybe have solved an issue that I wanted to work around by marking this clock both prefer and noselect, by setting a very small value for this maximal offset. But I don't know if that would work, it may be that the clock is not accepted as a pps valid indicator (prefer) when the offset is outside the fudge time2 window. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob writes: Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html The Debian package is still at p448 but I downloaded the source tarball to have a peek in it, and as far as I understand this change it is not going to solve one of my current issues... (maybe it could have if the fudge time2 could be specified in milliseconds?) All the time variables are fixed-point decimals in seconds - you should be able to say 0.001 to mean a millisecond (or -0.001 if you need to go the other direction). -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-08-24 13:48, Rob wrote: Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2014-08-24 05:12, Rob wrote: Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html The Debian package is still at p448 but I downloaded the source tarball to have a peek in it, and as far as I understand this change it is not going to solve one of my current issues... (maybe it could have if the fudge time2 could be specified in milliseconds?) fudge time* are seconds as doubles so you can include your cable delay in ns. This specific value is used as a maximal offset between supplied time and system time and is rounded to seconds (I don't know why). It could maybe have solved an issue that I wanted to work around by marking this clock both prefer and noselect, by setting a very small value for this maximal offset. But I don't know if that would work, it may be that the clock is not accepted as a pps valid indicator (prefer) when the offset is outside the fudge time2 window. As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd: fudge time2 may predate the panic gate threshold override in the daemon, or maybe just uses that to control whether the time is believed at startup. How about setting fudge flag1 0 time2 1, and at startup or when unsynced, have your monitoring program set the valid flag, and set all the timestamp values to zero? If you are currently leaving your valid flag clear, setting valid and zeroing the timestamps may make the driver read and ignore your clock until it starts providing good data, and also let the daemon know. Other drivers e.g. NMEA using only $GPGGA or $GPGLL can operate while providing only UTC time and no date, which NTP gets by checking other sources. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). There appears to be a package ntp-doc-dev on the site, but I cannot install it as my system is 64-bit and the repository cannot be installed on it. I can only install the source repository and apparently the doc package is in the binary repository. Who still has those i386 systems out there? Why doesn't ntp-dev support 64-bit?? Anyway, I checked the ntpd/refclock_shm.c source and I cannot find any reference to flag1 in there. So I'm lost. What is the magic? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html There appears to be a package ntp-doc-dev on the site, but I cannot install it as my system is 64-bit and the repository cannot be installed on it. I can only install the source repository and apparently the doc package is in the binary repository. Who still has those i386 systems out there? Why doesn't ntp-dev support 64-bit?? No idea what you mean there - we do 64-bit builds (under linux and other OSes) all the time. You might want to check with whoever handles building packages for your distro. Anyway, I checked the ntpd/refclock_shm.c source and I cannot find any reference to flag1 in there. So I'm lost. What is the magic? This will be post-4.2.7p462 . See the shm_control() stuff, which starts about line 232. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). There appears to be a package ntp-doc-dev on the site, but I cannot install it as my system is 64-bit and the repository cannot be installed on it. I can only install the source repository and apparently the doc package is in the binary repository. Who still has those i386 systems out there? Why doesn't ntp-dev support 64-bit?? Hi Most of my systems run ntp-dev from /usr/local rather than the supplied ntpd. On Ubuntu this was a bit more of a fiddle than with NetBSD. NetBSD/6.99.43 amd64 is already using ntp-dev but an older version than I have on NetBSD/6 i386. Neither have I used a refclock with any of my systems now running amd64. $ ntpq -crv -p associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event, version=ntpd 4.2.7p404-o Fri Dec 27 19:28:17 EST 2013 (import), processor=amd64, system=NetBSD/6.99.43, leap=00, stratum=2, precision=-21, rootdelay=0.911, rootdisp=403.422, refid=192.168.59.61, reftime=d7a2d1ab.b09a144b Sat, Aug 23 2014 8:39:07.689, clock=d7a2d1d8.9f549c5e Sat, Aug 23 2014 8:39:52.622, peer=45181, tc=6, mintc=3, offset=0.186565, frequency=17.424, sys_jitter=0.352233, clk_jitter=0.093, clk_wander=0.004 remote refidst t poll reach delay offset jitter = +d525mw03 192.168.59.61 2 s 64 3770.120 -0.032 0.716 +e350n1c 192.168.59.61 2 s 64 3760.077 -0.144 0.034 +p4x2666 192.168.59.61 2 s 64 3760.165 -0.230 0.031 *me6000e .PPSb. 1 u 64 3770.9110.187 0.352 +me6000g 192.168.59.61 2 u 64 3770.263 -0.239 0.067 +mail 81.187.61.78 3 u 128 3770.362 -0.023 0.549 +mail0 81.187.61.78 3 u 128 3770.648 -0.363 0.644 +ns3 81.187.61.78 3 u 128 3770.447 -0.210 0.093 David Anyway, I checked the ntpd/refclock_shm.c source and I cannot find any reference to flag1 in there. So I'm lost. What is the magic? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
David Lord sn...@lordynet.org wrote: Rob wrote: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). There appears to be a package ntp-doc-dev on the site, but I cannot install it as my system is 64-bit and the repository cannot be installed on it. I can only install the source repository and apparently the doc package is in the binary repository. Who still has those i386 systems out there? Why doesn't ntp-dev support 64-bit?? Hi Most of my systems run ntp-dev from /usr/local rather than the supplied ntpd. I run ntp-dev, but from a Debian repository offered at http://packages.ntp.org/debian I had to compile it myself because it does not offer 64-bit binaries, but I also cannot install the docs because they are in the binary repository and it cannot be added to a 64-bit system. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Sat, Aug 23, 2014 at 6:05 AM, Harlan Stenn st...@ntp.org wrote: No idea what you mean there - we do 64-bit builds (under linux and other OSes) all the time. You might want to check with whoever handles building packages for your distro. You lot are not fulfilling your obligation to Rob. Tsk, tsk. More seriously -- having that somewhat stale deb repo probably isn't helping anyone and causes confusion (like yours) between ntp-dev tar balls and ntp-dev debs including the (nearly empty) ntp-dev-doc deb. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: Rob writes: Harlan Stenn st...@ntp.org wrote: Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? I have installed ntp-dev and as part of that also ntp-dev-doc, but it is essentially empty (only an automatically generated changelog). It's in the source distribution, html/drivers/driver28.html Ok in my version that still states that this flag is unused, so it is a very recent change. There appears to be a package ntp-doc-dev on the site, but I cannot install it as my system is 64-bit and the repository cannot be installed on it. I can only install the source repository and apparently the doc package is in the binary repository. Who still has those i386 systems out there? Why doesn't ntp-dev support 64-bit?? No idea what you mean there - we do 64-bit builds (under linux and other OSes) all the time. You might want to check with whoever handles building packages for your distro. I am using the Debian packages from your site: # ntp development version #deb http://packages.ntp.org/debian stable main deb-src http://packages.ntp.org/debian stable main Unfortunately I cannot use the first source (commented above) as it is only for i386. Anyway, I checked the ntpd/refclock_shm.c source and I cannot find any reference to flag1 in there. So I'm lost. What is the magic? This will be post-4.2.7p462 . See the shm_control() stuff, which starts about line 232. Ok I have currently installed ntp-dev-4.2.7p448 of July 15, so I will first need to update then. Maybe later in the weekend. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Paul tik-...@bodosom.net wrote: On Sat, Aug 23, 2014 at 6:05 AM, Harlan Stenn st...@ntp.org wrote: No idea what you mean there - we do 64-bit builds (under linux and other OSes) all the time. You might want to check with whoever handles building packages for your distro. You lot are not fulfilling your obligation to Rob. Tsk, tsk. More seriously -- having that somewhat stale deb repo probably isn't helping anyone and causes confusion (like yours) between ntp-dev tar balls and ntp-dev debs including the (nearly empty) ntp-dev-doc deb. When I started using ntp-dev to solve an issue I had with the default Debian ntp, it appeared to me that the deb packages on that site were just a different (and more convenient in this case) distribution of the same thing. Probably generated using some daily job. However, since then I already have had so many small difficulties with the packages that it probably would have saved me time to use the tar ball instead. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Paul writes: More seriously -- having that somewhat stale deb repo probably isn't helping anyone and causes confusion (like yours) between ntp-dev tar balls and ntp-dev debs including the (nearly empty) ntp-dev-doc deb. I didn't know that Rob was talking about the debian package stuff from ntp.org until he replied to that message. I'd love to see folks step-up to maintain various distro packages, preferably people who are on appropriate distro package teams. If the distros want to do this on their site instead of on ours, that's great too. Interested folks should email me about this. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Sat, Aug 23, 2014 at 4:00 PM, Harlan Stenn st...@ntp.org wrote: I didn't know that Rob was talking about the debian package stuff from ntp.org until he replied to that message. Look for 'ntp-dev conflicts with ntp' from early this month. Of course there's going to be confusion when 99.99% of people think ntp-dev means the tarball and the rest think it's ntp-dev.deb. I'd love to see folks step-up to maintain various distro packages, I believe Steve Kostecke (who provided the buid assist in that thread) makes the debs. preferably people who are on appropriate distro package teams. The problem is if you don't have a deb build-bot then ntp-dev@ntp.org gets out of sync which defeats the purpose of being on dev. To carp yet again: you should add timepps.h to the tar ball and stick to that. Leave the package building to the distributions. If people want/need more current features they should learn how to build the current dev source and you should make that a LOT easier by including timepps.h for Linux because it's never going to be in Debian or derived distros. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Paul writes: On Sat, Aug 23, 2014 at 4:00 PM, Harlan Stenn st...@ntp.org wrote: I didn't know that Rob was talking about the debian package stuff from ntp.org until he replied to that message. Look for 'ntp-dev conflicts with ntp' from early this month. Of course there's going to be confusion when 99.99% of people think ntp-dev means the tarball and the rest think it's ntp-dev.deb. I'd love to see folks step-up to maintain various distro packages, I believe Steve Kostecke (who provided the buid assist in that thread) makes the debs. Not anymore. preferably people who are on appropriate distro package teams. The problem is if you don't have a deb build-bot then ntp-dev@ntp.org gets out of sync which defeats the purpose of being on dev. Goes to my call for somebody to take over the debian packaging. They can host it wherever they want. An appropriate person will be given access to a debian packaging VM instance (or some equivalent) at ntp.org. To carp yet again: you should add timepps.h to the tar ball and stick to that. Leave the package building to the distributions. If people want/need more current features they should learn how to build the current dev source and you should make that a LOT easier by including timepps.h for Linux because it's never going to be in Debian or derived distros. Then whoever steps up to take over the debian build/packaging could add this file to ports/debian/ . -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: To carp yet again: you should add timepps.h to the tar ball and stick to that. Leave the package building to the distributions. If people want/need more current features they should learn how to build the current dev source and you should make that a LOT easier by including timepps.h for Linux because it's never going to be in Debian or derived distros. Then whoever steps up to take over the debian build/packaging could add this file to ports/debian/ . Note that this is not a Debian-specific problem. Other distributions suffer from that timepps.h issue just as well. I agree that it should be in the ntp source when it is not going to be in the standard set of header files for Linux. However, my current reason for using the dev version is not that issue (it can be solved by fetching the source package for the distribution and re-compile it after the package containing timepps.h has been installed), but I needed a more recent version to get more resolution on the offset and jitter values. I wanted to use distribution packages as much as possible, because there are several systems where I need this ntpd. I encountered the following issues: 1. the distributed binaries of ntp-dev are only for i386, not for amd64. so I needed to get the source package and recompile. 2. the package is named ntp-dev not ntp, so it cannot really replace ntp. (I have another package that is dependent on ntp, so the ntp package cannot be removed, and ntp-dev cannot be installed on top of ntp) 3. the renaming of ntp to ntp-dev has not been done completely correctly. e.g. the service name was changed from ntp to ntp-dev (completely superfluous in my opinion) so the file in /etc/init.d is now named ntp-dev instead of ntp, a settings file in /etc/default is installed as ntp-dev instead of ntp, but the /etc/init.d/ntp-dev still reads the now nonexistant /etc/default/ntp instead of /etc/default/ntp-dev. The issues #2 and #3 could have been avoided by just naming the package ntp, at a higher version number. Then one could install and track the development version by adding the proper repository. Of course the repository should include amd64 binaries. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki martin.burni...@meinberg.de wrote: Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: This could basically work with all types of refclock, e.g.: # refclocks with PPS signal and status, but no absolute time server 127.127.8.0 noselect server 127.127.22.0 stat 127.127.8.0 # sync state from parse driver server 127.127.28.0 noselect server 127.127.22.1 stat 127.127.28.0 # sync state from SHM0 Ok that looks good, but I have to check if it is possible to relay status information through the SHM driver in a reasonable way. (just put a valid time of zero in the clock for valid, and stop putting time values in the clock for invalid? is that what you have in mind?) This was just an example. Since the PPS driver by itself is unable to retrieve the status (it also wouldn't kno how to do it) using one of the other existing refclock which already support this came into my mind. Anyway, the details would have to be checked for any refclock driver which should nbe used to pass the status only. To continue this thread... At the end of that discussion, I have tried to create a workaround for the problem with my GPSDO. It can actually provide UTC (or GPS) time on the serial port, but not the date. Before, I assumed that I could not write a driver to provide time to ntpd (as ntpd considers time and date a single value). What I did: when the GPSDO provides UTC time on the serial port, read the current date/time on the system, extract the date from that, combine that with the UTC time from the GPSDO and feed that into an SHM segment. I only do that when the status of the GPSDO indicates it is locked OK. The provided date/time will be correct when the system at least has the date correctly set. That will normally be the case. For cases where this fails (and to get leapsecond announcements), I still have a couple of internet NTP servers. But now I could mark the SHM clock as prefer and not the external servers. Yesterday, on one of the systems the powersupply of the GPSDO became erratic (a known issue with those supplies) and it started cycling through startup/tracking. This put the validation to the test, and of course it works suboptimally. Issues observed: 1. when the GPSDO restarts, its PPS is off by a random amount. it indicates this fact on the status output, so the monitoring program stops updating the SHM segment. However, the SHM is polled by ntpd at 64-second intervals and it takes 8 cycles before it gets the message that this refclock is invalid now, so for about 10 minutes ntpd is still taking the PPS as valid and will be pulling the clock to the wrong time. 2. as the SHM source has been marked prefer (it has to be, to let it gate the PPS refclock), ntpd starts locking to that clock once it becomes available. however, the accuracy of such a serial port clock is way less than that of an external NTP reference over the internet. it should prefer my 3 external references over that SHM source. I tried doing that by setting a high stratum on the SHM source, but it does not work. Either the prefer or the fact that it is a local clock makes ntpd select it as a reference and reject the external sources (that are correct). Would it be possible to have a clock both prefer and noselect? Also, I think in cases like this it would be better when ntpd relied a bit more on its longtime evaluation of clock drift. When the system has been locked to PPS for a long time, and then the PPS signal is lost or suddenly jumps, it could be argued it is better to freewheel for some time (e.g. 15-30 minutes) to see if correct PPS is restored, than to forget about all the learned history and start locking on another refclock. (messing up the learned frequency information!) When everything is synced, the system is within a few microseconds and would drift away at microseconds/minute rate. But ntpd starts pulling it away at much higher rate to agree to another source that as an offset at millisecond level. Furthermore, because of issue 1, it looks like the mechanism of validating PPS should not be that another refclock (in the current code: the prefer refclock) is still considered valid, but there should be an immediate action. When the GPSDO says the time is invalid, it should not be used from then on, not 10 minutes later. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob, You have seen 'flag1' in the recent ntp-dev SHM driver documentation, right? -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Le 1 août 2014 à 00:43, Rob a écrit : William Unruh un...@invalid.ca wrote: I think you need to read up on the cmos clock. As I said, it reports only the seconds, but is settable and readable to microseconds. The CMOS clock is running off a 32768Hz crystal, so no way it can be more accurately set than 30us. Some, such as the venerable MC146818A can use higher clock speeds. Even it could be possible in theory to set and read it accurately to that value, apparently Linux does not do that. That makes it questionable to me if it can be done. I could understand when Windows would not exploit such a capability, when there is no monetary gain to be made. But the Linux developers are too proud and too nerdy to skip such an opportunity. Inclined to agree. None of the TC data sheets I have looked at show them holding microsecond resolution data. All have just one byte recording integral seconds. Quite a few RTCs have either a clock out, or programmable square wave outputs, which when used could give access to higher resolution, but as you point out , access to that is not implemented in general purpose computers, or OS's. The fact that there is a microsecond-accurate API to set and read the clock does not indicate anything. Remember Linux can run on any platform, and there may be other platforms, now or in the future, that can use this accuracy. In my experience, the clock always jumps a few hundred milliseconds when rebooting a PC. ___ 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] LOCL clock reachability not 377?
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: It looks good. What is important for my box (but maybe only for mine...) is that there is some method to feed OK/FAULT status to ntpd without a reference clock driver, or with a reference clock driver that ntpd understands will not provide time but only status. That driver could be similar to SHM (or it could be SHM with a fudge flag set), in that it could use a shared memory segment where an external program puts a flag indicating the validity of the PPS source. Even though I had mentioned your case I haven't accounted for this in the examples. I think I would prefer if this could be a configuration option associated with the PPS driver, so ntpd knows this PPS source only provides a status but not the current absolute time. This could basically work with all types of refclock, e.g.: # refclocks with PPS signal and status, but no absolute time server 127.127.8.0 noselect server 127.127.22.0 stat 127.127.8.0 # sync state from parse driver server 127.127.28.0 noselect server 127.127.22.1 stat 127.127.28.0 # sync state from SHM0 My GPSDO is very good at providing PPS and 10 MHz, but otherwise it is old and rusty. Apparently many of them are going around in hobbyist circles. It does provide IRIG output, but that is not really useful as you already indicate (and difficult to interface as well), and an RS232 command/status interface that only provides UTC/GPS time but no date. However, on that interface there is a good indication of the search/lock status and the momentary (estimated) error, which I use to generate nagios alerts when it goes haywire. For that, a daemon is running that polls it every few seconds, which could be extended to write the SHM flag. In the example above the daemon could also just write the sync status to the SHM segment. Since the noselect keyword is given ntpd would poll it but not try to use it as normal refclock. In the PPS config line a stat rather than a ref parameter could be used to rtell that only the sync status should be picked up from the associated parse or SHM refclock. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: William Unruh un...@invalid.ca wrote: On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). There are complications. While the clock would probably be capable of maintaining the time within a second, it cannot be set to a reasonable accuracy. On the system-under-test, i.e. with the locked PPS source, the LOCL clock, and the unreachable external references, I did a reboot. With my proposal you wouldn't need the local clock driver for this. Result: after the reboot, the system time was off by 270ms and the PPS was not trusted. The time remained off by 270ms as indicated by a 270ms offset on PPS (marked with an x), and remained freerunning. Only after I managed to get a reachable external reference again, it stepped 270ms and then locked to the PPS again. Of course this would not have happened when the system had remained running, as it normally would. I rebooted it for major network reconfig and after that I was able to find NTP servers on another internet connection so it now has 3 external references again. The concept of the trust time includes that the time source must have been synchronized before, and when synchronization is then lost the trust time starts to be counted. In context of the PPS input this means that ntpd must be sure the absolute time has been set to within some bounds from some absolute source, like (ntpdate used to do before the -g flag was invented ;-)) before the PPS signal is initially accepted. But if that time source fails afterwards the PPS signal would be accepted for a particular trust time which could be 0, some dedicated time interval, or unlimited, depending on the configuration of the PPS source. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh wrote: Yes, not entirely surprizing, especially considering the way ntp is designed right now. This is a combination of bad ntpd design, and restart when an external source is mandatory. I think the design was OK when it was originally invented many years ago. However, as you can see from my other comments I agree that this isn't optimal for today's requirements. Software which is designed later can always be designed trying to avoid limitations which have shown up in concepts used by older software a long time after the original concept had been determined. This is similar with PTP vs. NTP, which also benefits from hardware time stamping only and has been originally designed to use follow-up packets to send the time stamps captured when the original packet went out on the wire. Even this PTP 2-step concept is actually obsoleted by 1-step mode, where the NIC hardware can replace the original transmission time at the end of an outgoing PTP packet by the time stamp captured at the beginning of that packet. This reguires special, fast hardware, though. So you see, from a later point of view there's always room for improvements if the requirements or technical possibilities have changed. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: William Unruh un...@invalid.ca wrote: On 2014-07-31, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). There are complications. While the clock would probably be capable of maintaining the time within a second, it cannot be set to a reasonable accuracy. On the system-under-test, i.e. with the locked PPS source, the LOCL clock, and the unreachable external references, I did a reboot. A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. This is only the case for Linux, and AFAIK only if the system has been configured to do these updates. I don't know if this is also true for *BSD and other Unix-like systems, but at least for Windows it is certainly not. So I think the concept doesn't have to rely on this by default, but on the other hand there should be ways to configure this for particular cases where the user is sure the system time is set to +/- 0.5 s when ntpd starts. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn wrote: Martin Burnicki writes: Miroslav Lichvar wrote: Agreed, it would be useful to have an option to specify the PPS-time source association for each PPS refclock directly. In chrony, this is done with the lock refclock option. It's typically used like this: refclock SHM 0 offset 0.5 refid SHM0 noselect refclock PPS /dev/pps0 lock SHM0 The SHM refclock (e.g. GPS NMEA) is configured with the noselect option so it's never selected and only used by the PPS refclock to align the pulses to the SHM time. When SHM stops getting new samples the PPS refclock will stop immediately too. When the PPS refclock doesn't have the lock option and the local stratum option is not used, the pulses will be accepted only when the clock is synchronized, first to another refclock or NTP server and then possibly the PPS refclock itself. If local stratum is enabled, the PPS will work immediately without any other sources, but the clock obviously needs to be already close to the correct time on start, otherwise it will be off by a whole number of seconds. This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: 1) A refclock provides absolute time, status, and a PPS signal 1a) The refclock contains a good oscillator, so the PPS signal could be accepted for some time after the refclock started freewheeling. 1b) The refclock only has a simply xtal which starts drifting immediately when the refclock starts freewheeling. In either of these cases we could have a parameter for the appropriate value of PHI for that clock. Yes. the problem is where to get it from. 2) A good PPS signal is available, but no absolute time (e.g. in case of a Rubidium) 2a) Some status information is available telling if the PPS signal is good or not 2b) No information on the PPS quality is available Agreed - I've been trying to sell DLM on this idea for years. ;-) or better :-( Case 1a) or 1b) is usually true for most GPS receivers. 1a) is for example the case for Meinberg GPS receivers, which have a good oscillator (TCXO or even OCXO) on board, but in contrast to the GPSDO mentioned by Rob, which doesn't provide absolute time, the Meinberg devices do. NTP's parse driver supports the concept of a trust time which means that *if* the time source has been synchronized and then starts freewheeling you can configure a time interval during which the parse driver doesn't tell ntpd that the refclock has started freewheeling, and thus the refclock plus associated PPS signal are still accepted for that interval. So only after the trust time has been expired the PPS signal is discarded. 1b) is the case for most cheap GPS receivers. If they loose the satellite signal they often start drifting quite a lot, in which case it could make sense to discard the PPS signal immediately. In terms of the trust time mentioned in 1a) this would mean the trust time is very short, or even 0. If the value of phi cannot be easily measured (or is not provided by the manufacturer), this would be a better choice. Of course there's a large difference between cheap crystals and good oscillators, but even in case of a GPS disciplined oscillator the resulting drift may depend on how good the oscillator has been disciplined before. I think the trust time concept is easy to be understood by normal users and allows to take also into account which accuracy is required by certain applications. From my experience many users are only interested in a network time which is accurate to the second, so that e.g. their outgoing emails have the right time. If they have a good refclock then these folks usually select a large trust time since the refclock is more stable than the PC's time, even when it is freewheeling. On the other hand there are applications requiring highest possible accuracy, in which case the best value for a trust time can be determined if the characteristics of the refclock/PPS source are known. And the General Timestamp API (GTSAPI) project from NTF would nicely wrap this information into a timestamp for you, directly. For cases 2a) and 2b) there is no absolute time available from the PPS source. If a status is available this could be evaluated, eventually with a trust time. If no status is available you simply could always trust the PPS source (unlimited trust time), or you shouldn't use it as reference time source. ;-) If devices that do not have absolute clocks have a way to track relative time the GTSAPI would provide the error bounds information usefully there, too. The GTSAPI is probably good for applications, but IMO internally ntpd should take care of the time stamps and time differences by itself. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Thu, Jul 31, 2014 at 04:31:08PM +0200, Martin Burnicki wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: 1) A refclock provides absolute time, status, and a PPS signal 1a) The refclock contains a good oscillator, so the PPS signal could be accepted for some time after the refclock started freewheeling. 1b) The refclock only has a simply xtal which starts drifting immediately when the refclock starts freewheeling. 2) A good PPS signal is available, but no absolute time (e.g. in case of a Rubidium) 2a) Some status information is available telling if the PPS signal is good or not 2b) No information on the PPS quality is available To generalize it a bit more, there could be also a case of a PPS that is not locked in phase and a case of a PPS that's not even locked in frequency. When only a source with poor short-term stability is available, I think it would be pretty cool if it could be combined with a PPS derived from a cheap TCXO. Doing this in ntpd could be tricky however. Beside the implementation of such a flexible concept in ntpd it would have to be discussed how this can easily be configured. With NTP's basic configuration syntax in mind a possible way could be something like this: # a refclock with PPS signal but no good oscillator server 127.127.8.0 server 127.127.22.0 ref 127.127.8.0 # a refclock with PPS signal and good oscillator server 127.127.8.1 server 127.127.22.1 ref 127.127.8.1 trust 3600 # a PPS source relying on the usual system peer to # provide absolute time server 127.127.22.2 ref sys_peer # a PPS source which should be trusted always server 127.127.22.3 trust always This looks good, but shouldn't it be rather specified with a fudge command? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Thu, Jul 31, 2014 at 10:43:12PM +, Rob wrote: William Unruh un...@invalid.ca wrote: I think you need to read up on the cmos clock. As I said, it reports only the seconds, but is settable and readable to microseconds. The CMOS clock is running off a 32768Hz crystal, so no way it can be more accurately set than 30us. Even it could be possible in theory to set and read it accurately to that value, apparently Linux does not do that. That makes it questionable to me if it can be done. I could understand when Windows would not exploit such a capability, when there is no monetary gain to be made. But the Linux developers are too proud and too nerdy to skip such an opportunity. Well, the problem with reading or setting the RTC accurately is that it takes up to 1 second, for a system call that's unacceptable. It can't be really compared to the system clock, which can be read in few tens of nanoseconds, on Linux it usually doesn't even involve a real system call. The fact that there is a microsecond-accurate API to set and read the clock does not indicate anything. Remember Linux can run on any platform, and there may be other platforms, now or in the future, that can use this accuracy. The RTC ioctls use only second resolution, AFAIK there is no API that would allow reading or setting the RTC with better resolution, you need to do it yourself by timing the ioctl call when setting the clock and enabling the interrupt when reading the clock. When ntpd is running, the kernel 11-minute update mode will time the RTC update to few ticks, that's few milliseconds with a 1000Hz kernel. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Miroslav Lichvar wrote: On Thu, Jul 31, 2014 at 04:31:08PM +0200, Martin Burnicki wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: 1) A refclock provides absolute time, status, and a PPS signal 1a) The refclock contains a good oscillator, so the PPS signal could be accepted for some time after the refclock started freewheeling. 1b) The refclock only has a simply xtal which starts drifting immediately when the refclock starts freewheeling. 2) A good PPS signal is available, but no absolute time (e.g. in case of a Rubidium) 2a) Some status information is available telling if the PPS signal is good or not 2b) No information on the PPS quality is available To generalize it a bit more, there could be also a case of a PPS that is not locked in phase and a case of a PPS that's not even locked in frequency. When only a source with poor short-term stability is available, I think it would be pretty cool if it could be combined with a PPS derived from a cheap TCXO. Doing this in ntpd could be tricky however. Hm, I maybe I don't understand correctly what you mean. You want to use a PPS signal without proper phase and frequency, and then use *in addition* another PPS derived from a TCXO? Do you have an example for this? Beside the implementation of such a flexible concept in ntpd it would have to be discussed how this can easily be configured. With NTP's basic configuration syntax in mind a possible way could be something like this: # a refclock with PPS signal but no good oscillator server 127.127.8.0 server 127.127.22.0 ref 127.127.8.0 # a refclock with PPS signal and good oscillator server 127.127.8.1 server 127.127.22.1 ref 127.127.8.1 trust 3600 # a PPS source relying on the usual system peer to # provide absolute time server 127.127.22.2 ref sys_peer # a PPS source which should be trusted always server 127.127.22.3 trust always This looks good, but shouldn't it be rather specified with a fudge command? Maybe. What I wrote was just a suggestion, and I said the syntax had to be discussed. Actually e.g. the parse driver (driver 8) supports both keywords on the config line, and fudge commands. For example: server 127.127.8.0 mode 2 minpoll 4 maxpoll 4 fudge 127.127.8.0 time1 0.0 fudge 127.127.8.0 refid GPS While minpoll/maxpoll are general options for a server line, the mode parameter is specific to the *parse* driver. On the other hand, as far as I can see commands like fudge time1 and fudge refid are supported by ntpd's generic refclock interface and thus can basically be used with *every* refclock driver. So in my opinion if the ref and trust keyword which I've used in the examples above are specific to the ATOM driver (driver 22) only then they should be specified on the server line for the PPS refclock. Nevertheless, this can be subject to discussions, of course. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki martin.burni...@meinberg.de wrote: Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: It looks good. What is important for my box (but maybe only for mine...) is that there is some method to feed OK/FAULT status to ntpd without a reference clock driver, or with a reference clock driver that ntpd understands will not provide time but only status. That driver could be similar to SHM (or it could be SHM with a fudge flag set), in that it could use a shared memory segment where an external program puts a flag indicating the validity of the PPS source. Even though I had mentioned your case I haven't accounted for this in the examples. I think I would prefer if this could be a configuration option associated with the PPS driver, so ntpd knows this PPS source only provides a status but not the current absolute time. This could basically work with all types of refclock, e.g.: # refclocks with PPS signal and status, but no absolute time server 127.127.8.0 noselect server 127.127.22.0 stat 127.127.8.0 # sync state from parse driver server 127.127.28.0 noselect server 127.127.22.1 stat 127.127.28.0 # sync state from SHM0 Ok that looks good, but I have to check if it is possible to relay status information through the SHM driver in a reasonable way. (just put a valid time of zero in the clock for valid, and stop putting time values in the clock for invalid? is that what you have in mind?) My GPSDO is very good at providing PPS and 10 MHz, but otherwise it is old and rusty. Apparently many of them are going around in hobbyist circles. It does provide IRIG output, but that is not really useful as you already indicate (and difficult to interface as well), and an RS232 command/status interface that only provides UTC/GPS time but no date. However, on that interface there is a good indication of the search/lock status and the momentary (estimated) error, which I use to generate nagios alerts when it goes haywire. For that, a daemon is running that polls it every few seconds, which could be extended to write the SHM flag. In the example above the daemon could also just write the sync status to the SHM segment. Since the noselect keyword is given ntpd would poll it but not try to use it as normal refclock. Yes but if I remember well the SHM clock does not have a sync status, only a timestamp can be written there and a flag set that this has been done, which will be seen by ntpd and reset again. Well, maybe for quick results I will just pursue another path that I had thought about in the past: in my daemon that reads the UTC time from the GPSDO, I can combine that with the system date from the local system clock to form a complete timestamp to put in an SHM segment. I can then configure this in ntpd as a time source. This will normally work okay when at least the system date is correct, and it will be a stratum 1 time source that ntpd can lock on to when there is no external reference. When the system date is incorrect and there are three external references, the situation will probably be corrected, the system date will step, and from then on the clock is providing correct time (within a couple of tens of ms due to the usual serial delays). It is like the LOCL clock, except it has an uncertainty window of a day instead of a second. That should solve the reboot issue. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki martin.burni...@meinberg.de wrote: A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. This is only the case for Linux, and AFAIK only if the system has been configured to do these updates. I don't know if this is also true for *BSD and other Unix-like systems, but at least for Windows it is certainly not. I think it is enabled in Linux by default. When the clocked is synced to NTP, the CMOS is written every 11 minutes. However, I think it works as Miroslav wrote: the CMOS clock can only be set to seconds, and you can try to get it set correctly by issuing the call a the right moment. However, the whole cycle of write time to CMOS, reboot, read time from CMOS again still has a large uncertainty, larger than the window ntpd accepts for PPS. So it declares the PPS an outlyer most of the time. What happens in Windows does not bother me very much, Windows is totally unusable for timing at the accuracy I require anyway. But of course I understand that you are interested in that :-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki martin.burni...@meinberg.de wrote: My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). There are complications. While the clock would probably be capable of maintaining the time within a second, it cannot be set to a reasonable accuracy. On the system-under-test, i.e. with the locked PPS source, the LOCL clock, and the unreachable external references, I did a reboot. With my proposal you wouldn't need the local clock driver for this. Of course :-) But now we have a running system and encountered a problem, so I was investigating a bit... In context of the PPS input this means that ntpd must be sure the absolute time has been set to within some bounds from some absolute source, like (ntpdate used to do before the -g flag was invented ;-)) before the PPS signal is initially accepted. But if that time source fails afterwards the PPS signal would be accepted for a particular trust time which could be 0, some dedicated time interval, or unlimited, depending on the configuration of the PPS source. That is right! At the moment, one of my problems is that the LOCL clock cannot bring the time back to sufficient accuracy for the PPS signal to be accepted as trusted in ntpd (after a reboot). Of course it is no problem when the system remains running or when there is an external reference. I will probably work around it in the way I described elsewhere. (combine the time from the GPSDO with the date from the system to form a timestamp sent to ntpd via SHM) That is, until a nice solution for all this is incorporated in ntpd. I think your suggestions are very good. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: This could basically work with all types of refclock, e.g.: # refclocks with PPS signal and status, but no absolute time server 127.127.8.0 noselect server 127.127.22.0 stat 127.127.8.0 # sync state from parse driver server 127.127.28.0 noselect server 127.127.22.1 stat 127.127.28.0 # sync state from SHM0 Ok that looks good, but I have to check if it is possible to relay status information through the SHM driver in a reasonable way. (just put a valid time of zero in the clock for valid, and stop putting time values in the clock for invalid? is that what you have in mind?) This was just an example. Since the PPS driver by itself is unable to retrieve the status (it also wouldn't kno how to do it) using one of the other existing refclock which already support this came into my mind. Anyway, the details would have to be checked for any refclock driver which should nbe used to pass the status only. How have you done this before? My GPSDO is very good at providing PPS and 10 MHz, but otherwise it is old and rusty. Apparently many of them are going around in hobbyist circles. It does provide IRIG output, but that is not really useful as you already indicate (and difficult to interface as well), and an RS232 command/status interface that only provides UTC/GPS time but no date. However, on that interface there is a good indication of the search/lock status and the momentary (estimated) error, which I use to generate nagios alerts when it goes haywire. For that, a daemon is running that polls it every few seconds, which could be extended to write the SHM flag. In the example above the daemon could also just write the sync status to the SHM segment. Since the noselect keyword is given ntpd would poll it but not try to use it as normal refclock. Yes but if I remember well the SHM clock does not have a sync status, only a timestamp can be written there and a flag set that this has been done, which will be seen by ntpd and reset again. I'm actually already out for the weekend, and will have limited internet access the next days, so I'm currently unable to look at this in more detail, and my replies may also be delayed for the next days. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. This is only the case for Linux, and AFAIK only if the system has been configured to do these updates. I don't know if this is also true for *BSD and other Unix-like systems, but at least for Windows it is certainly not. I think it is enabled in Linux by default. When the clocked is synced to NTP, the CMOS is written every 11 minutes. However, I think it works as Miroslav wrote: the CMOS clock can only be set to seconds, and you can try to get it set correctly by issuing the call a the right moment. Yes, I have worked with this RTC chip many years ago, but this was not based on a PC hut on some embedded device. Anyway, I know all those limitations. However, the whole cycle of write time to CMOS, reboot, read time from CMOS again still has a large uncertainty, larger than the window ntpd accepts for PPS. So it declares the PPS an outlyer most of the time. What happens in Windows does not bother me very much, Windows is totally unusable for timing at the accuracy I require anyway. But of course I understand that you are interested in that :-) Personally I'm preferably also work with Linux, but I'm also doing some programming for Windows, so sometimes I also took a look at the Windows-specific code in ntpd. I think quite a lot of people are using ntpd under Windwos, and this should be kept in mind, i.e. even though ntpd might account on OS specific features, it shouldbn't basically rely on it. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: I think your suggestions are very good. Thanks! Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Fri, Aug 01, 2014 at 12:59:32PM +0200, Martin Burnicki wrote: Miroslav Lichvar wrote: To generalize it a bit more, there could be also a case of a PPS that is not locked in phase and a case of a PPS that's not even locked in frequency. When only a source with poor short-term stability is available, I think it would be pretty cool if it could be combined with a PPS derived from a cheap TCXO. Doing this in ntpd could be tricky however. Hm, I maybe I don't understand correctly what you mean. You want to use a PPS signal without proper phase and frequency, and then use *in addition* another PPS derived from a TCXO? I meant to use a PPS signal from an external undisciplined *XO to stabilize the system clock. The driver would track the phase and frequency offsets against other sources or the system clock over a longer interval and use that to correct the samples before normal processing. I think this could be useful with jittery sources (e.g. NTP) or reference clocks that don't have their own stabilized oscillator. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki writes: Harlan Stenn wrote: And the General Timestamp API (GTSAPI) project from NTF would nicely wrap this information into a timestamp for you, directly. For cases 2a) and 2b) there is no absolute time available from the PPS source. If a status is available this could be evaluated, eventually with a trust time. If no status is available you simply could always trust the PPS source (unlimited trust time), or you shouldn't use it as reference time source. ;-) If devices that do not have absolute clocks have a way to track relative time the GTSAPI would provide the error bounds information usefully there, too. The GTSAPI is probably good for applications, but IMO internally ntpd should take care of the time stamps and time differences by itself. We demonstrated using the GTSAPI as the kernel timestamp structure, replacing the struct timeval/struct timestamp as the base timekeeping struture. That's where the core timekeeping information must be maintained for best use of GTSAPI timestamps. As soon as resources are available, we'll have more public information on this. If anybody wants to help out on the GTSAPI effort, we need money and people to work on it. I'd *love* to be the PM on this project, and I just don't have the time. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote:
Martin Burnicki wrote:
In the example above the daemon could also just write
the sync status to the SHM segment.
Since the noselect keyword is given ntpd would poll
it but not try to use it as normal refclock.
Yes but if I remember well the SHM clock does not have
a sync status, only a timestamp can be written there
and a flag set that this has been done,
which will be seen by ntpd and reset again.
It has a valid int value?
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html
Are you talking about needing something in addition,
a Quality of Fix value (GPS, DGPS, PPS, RTK, ...)?
could the SHM value be extended for values grater than one to implement
this?
... some value scale 0, 1, 2-126
where higher values are a log2 seconds holdover (trust) value?
{e.g. a Telcom PRC/PRS Rubidium Oscillator (72days) would be a 22 or 23?
although those ITU/ANSI values seem conservative (to me)}.
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh wrote: Ie, once ATOM has been selected, it should remain selected, unless it also gets switched of for a few hours, or there is a disagreement between ATOM and some other selected clock source by more than a second. On the other hand, if the PPS signal is bound to a certain time source and that time source starts freewheeling the 1 PPS signal also starts to drift, and that may *not* be what you want. If I remember correctly we had a discussion here quite some time ago where ntpd enabled kernel PPS when a GPS receiver+PPS was synchronized, but didn't disable kernel PPS when the GPS receiver lost its input signal. The PPS from the GPS receiver started to drift away and also pulled the kernel time away. So as usually it always depends on some preconditions, i.e. if the PPS signal is still reliable in case the associated prefered peer goes away, or not. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob schrieb: A C agcarver+...@acarver.net wrote: ATOM always stops when the prefer peers die even if there are other peers available but not marked prefer. I'm still running an older development version (4.2.7p270) that I modified to remove all the prefer code so that the selection algorithm continues to run normally without shutting down the ATOM driver as peers come and go. If all the peers die then ATOM will stop, too since there's no more selected clock. Yes this is where the problem is. The ATOM clock needs to have some way of determining that the PPS pulses are valid, and the kludge to use the existing prefer keyword to indicate a clock that is to be used for that is causing all the trouble. The designer probably believed that any clock that provides PPS would also output some serial stream with less accurate time and also status, and that this would then be marked prefer. When that clock is OK, the PPS is also OK. However, that is broken. Not only do you probably not want to mark that clock prefer (external references are often more accurate than the serial NMEA time, for example), but also you may have two or more ATOM PPS clocks, each with their own status, and there is no way to do that with this method. I've already proposed some times ago that another way of assigning PPS signal(s) to other time source(s) would be more versatile: http://lists.ntp.org/pipermail/questions/2009-April/022599.html http://lists.ntp.org/pipermail/questions/2009-April/022600.html This would also provide a simple way to declare a PPS signal reliable, e.g. if it is derived from a Rubidium or so, in which case it could continue to be accepted even though other time sources become unreachable. On the other hand, if a PPS input signal is associated to a particular time source the PPS signal could be discarded if the associated time source becomes unreachable. Also, you may have (I do have) a GPSDO that provides PPS and status info, but no time. So I know when the PPS is valid, but I don't have an NMEA or TSIP or whatever stream to feed to a reference clock driver. I'm sure there would also be a way to configure such specific setup. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki martin.burni...@meinberg.de wrote: Rob schrieb: A C agcarver+...@acarver.net wrote: ATOM always stops when the prefer peers die even if there are other peers available but not marked prefer. I'm still running an older development version (4.2.7p270) that I modified to remove all the prefer code so that the selection algorithm continues to run normally without shutting down the ATOM driver as peers come and go. If all the peers die then ATOM will stop, too since there's no more selected clock. Yes this is where the problem is. The ATOM clock needs to have some way of determining that the PPS pulses are valid, and the kludge to use the existing prefer keyword to indicate a clock that is to be used for that is causing all the trouble. The designer probably believed that any clock that provides PPS would also output some serial stream with less accurate time and also status, and that this would then be marked prefer. When that clock is OK, the PPS is also OK. However, that is broken. Not only do you probably not want to mark that clock prefer (external references are often more accurate than the serial NMEA time, for example), but also you may have two or more ATOM PPS clocks, each with their own status, and there is no way to do that with this method. I've already proposed some times ago that another way of assigning PPS signal(s) to other time source(s) would be more versatile: http://lists.ntp.org/pipermail/questions/2009-April/022599.html http://lists.ntp.org/pipermail/questions/2009-April/022600.html This would also provide a simple way to declare a PPS signal reliable, e.g. if it is derived from a Rubidium or so, in which case it could continue to be accepted even though other time sources become unreachable. Yes, I see you are thinking along the same lines as I was. There has to be some defined relation between the PPS and a refclock, and it should not be via prefer, but using some fudge. And, there should be the possibility (maybe some dummy refclock) to send status information without also providing time information. Unfortunately it is very customary for PPS devices to always send their pulses even when they are not locked. This may make some sense when lock is lost after it had been available, and the device continues to free run with some accuracy. However, it is also done when the device coldstarts and the PPS makes no sense at all. So separate status information certainly is required. But not in the kludgy way it is provided now. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh wrote: Once ntpd has started using the pps clock, there is no need for anything to number the seconds. The system itself does that perfectly fine. There is no way that the system is going jump a second, unless it is a very very badly broken system. Ie, one only needs something to number the seconds at the beginning when you start up PPS. Thereafter pps on its own is perfectly capable to maintaining the time. As I've mentioned in my other post in this thread, it depends, and under different circumstances it may perfectly make sense to discard the PPS signal when the associated time source starts freewheeling. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Thu, Jul 31, 2014 at 10:43:20AM +0200, Martin Burnicki wrote: Rob schrieb: However, that is broken. Not only do you probably not want to mark that clock prefer (external references are often more accurate than the serial NMEA time, for example), but also you may have two or more ATOM PPS clocks, each with their own status, and there is no way to do that with this method. I've already proposed some times ago that another way of assigning PPS signal(s) to other time source(s) would be more versatile: http://lists.ntp.org/pipermail/questions/2009-April/022599.html http://lists.ntp.org/pipermail/questions/2009-April/022600.html This would also provide a simple way to declare a PPS signal reliable, e.g. if it is derived from a Rubidium or so, in which case it could continue to be accepted even though other time sources become unreachable. On the other hand, if a PPS input signal is associated to a particular time source the PPS signal could be discarded if the associated time source becomes unreachable. Agreed, it would be useful to have an option to specify the PPS-time source association for each PPS refclock directly. In chrony, this is done with the lock refclock option. It's typically used like this: refclock SHM 0 offset 0.5 refid SHM0 noselect refclock PPS /dev/pps0 lock SHM0 The SHM refclock (e.g. GPS NMEA) is configured with the noselect option so it's never selected and only used by the PPS refclock to align the pulses to the SHM time. When SHM stops getting new samples the PPS refclock will stop immediately too. When the PPS refclock doesn't have the lock option and the local stratum option is not used, the pulses will be accepted only when the clock is synchronized, first to another refclock or NTP server and then possibly the PPS refclock itself. If local stratum is enabled, the PPS will work immediately without any other sources, but the clock obviously needs to be already close to the correct time on start, otherwise it will be off by a whole number of seconds. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Miroslav Lichvar wrote: Agreed, it would be useful to have an option to specify the PPS-time source association for each PPS refclock directly. In chrony, this is done with the lock refclock option. It's typically used like this: refclock SHM 0 offset 0.5 refid SHM0 noselect refclock PPS /dev/pps0 lock SHM0 The SHM refclock (e.g. GPS NMEA) is configured with the noselect option so it's never selected and only used by the PPS refclock to align the pulses to the SHM time. When SHM stops getting new samples the PPS refclock will stop immediately too. When the PPS refclock doesn't have the lock option and the local stratum option is not used, the pulses will be accepted only when the clock is synchronized, first to another refclock or NTP server and then possibly the PPS refclock itself. If local stratum is enabled, the PPS will work immediately without any other sources, but the clock obviously needs to be already close to the correct time on start, otherwise it will be off by a whole number of seconds. This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: 1) A refclock provides absolute time, status, and a PPS signal 1a) The refclock contains a good oscillator, so the PPS signal could be accepted for some time after the refclock started freewheeling. 1b) The refclock only has a simply xtal which starts drifting immediately when the refclock starts freewheeling. 2) A good PPS signal is available, but no absolute time (e.g. in case of a Rubidium) 2a) Some status information is available telling if the PPS signal is good or not 2b) No information on the PPS quality is available Case 1a) or 1b) is usually true for most GPS receivers. 1a) is for example the case for Meinberg GPS receivers, which have a good oscillator (TCXO or even OCXO) on board, but in contrast to the GPSDO mentioned by Rob, which doesn't provide absolute time, the Meinberg devices do. NTP's parse driver supports the concept of a trust time which means that *if* the time source has been synchronized and then starts freewheeling you can configure a time interval during which the parse driver doesn't tell ntpd that the refclock has started freewheeling, and thus the refclock plus associated PPS signal are still accepted for that interval. So only after the trust time has been expired the PPS signal is discarded. 1b) is the case for most cheap GPS receivers. If they loose the satellite signal they often start drifting quite a lot, in which case it could make sense to discard the PPS signal immediately. In terms of the trust time mentioned in 1a) this would mean the trust time is very short, or even 0. For cases 2a) and 2b) there is no absolute time available from the PPS source. If a status is available this could be evaluated, eventually with a trust time. If no status is available you simply could always trust the PPS source (unlimited trust time), or you shouldn't use it as reference time source. ;-) In order to have some plausibility check, in case 1) the refclock (including PPS source) could me detected and marked as falseticker if the time-and-pps deviates more than a certain limit from other time sources. For cases 2 it could be good to be at least able to specify that the absolute time (and leap second warning, etc.) shall be derived from some other source, e.g. the system peer determined by the usual algorithms. Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. I don't think this would be acceptable for environments where an accurate precise time is most important. Since the NTP daemon is unable to know the precision and stability of a PPS source just from the PPS slopes the concept of a trust time could help fine-tuning a configuration in which several PPS sources of different quality are available. Beside the implementation of such a flexible concept in ntpd it would have to be discussed how this can easily be configured. With NTP's basic configuration syntax in mind a possible way could be something like this: # a refclock with PPS signal but no good oscillator server 127.127.8.0 server 127.127.22.0 ref 127.127.8.0 # a refclock with PPS signal and good oscillator server 127.127.8.1 server 127.127.22.1 ref 127.127.8.1 trust 3600 # a PPS source relying on the usual system peer to # provide absolute time server 127.127.22.2 ref sys_peer # a PPS source which should be trusted always server 127.127.22.3 trust always Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: Unfortunately it is very customary for PPS devices to always send their pulses even when they are not locked. This may make some sense when lock is lost after it had been available, and the device continues to free run with some accuracy. However, it is also done when the device coldstarts and the PPS makes no sense at all. So separate status information certainly is required. But not in the kludgy way it is provided now. I agree. Please see my reply to Miroslav. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). Now, it is certainly true that that provides no redundancy and there are situations in which you could be let astray, but that is also true even if you have 5 time sources. Ie, a PPS source on its own is quite capable of disciplining the system to microsecond accuracy even if all other time sources disappear, as long as they are there to deliver the seconds initially. To have PPS be discarded just because the supplier of seconds goes offline seems far far too extreme to me. Note that the supplier of seconds could even be a human setting the clock by hand intially. (one could do that to within certianly less than half a second). I don't think this would be acceptable for environments where an accurate precise time is most important. Of course, the greater the redundnacy, the better. Anyway, your proposals seem very sensible to me, and encompass my use case above. Since the NTP daemon is unable to know the precision and stability of a PPS source just from the PPS slopes the concept of a trust time could help fine-tuning a configuration in which several PPS sources of different quality are available. Beside the implementation of such a flexible concept in ntpd it would have to be discussed how this can easily be configured. With NTP's basic configuration syntax in mind a possible way could be something like this: # a refclock with PPS signal but no good oscillator server 127.127.8.0 server 127.127.22.0 ref 127.127.8.0 # a refclock with PPS signal and good oscillator server 127.127.8.1 server 127.127.22.1 ref 127.127.8.1 trust 3600 # a PPS source relying on the usual system peer to # provide absolute time server 127.127.22.2 ref sys_peer # a PPS source which should be trusted always server 127.127.22.3 trust always Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh un...@invalid.ca wrote: On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). There are complications. While the clock would probably be capable of maintaining the time within a second, it cannot be set to a reasonable accuracy. On the system-under-test, i.e. with the locked PPS source, the LOCL clock, and the unreachable external references, I did a reboot. Result: after the reboot, the system time was off by 270ms and the PPS was not trusted. The time remained off by 270ms as indicated by a 270ms offset on PPS (marked with an x), and remained freerunning. Only after I managed to get a reachable external reference again, it stepped 270ms and then locked to the PPS again. Of course this would not have happened when the system had remained running, as it normally would. I rebooted it for major network reconfig and after that I was able to find NTP servers on another internet connection so it now has 3 external references again. I think you should be prepared for an offset up to half a second when saving the time to the CMOS clock, rebooting, and reading it back. Not good. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki martin.burni...@meinberg.de wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: It looks good. What is important for my box (but maybe only for mine...) is that there is some method to feed OK/FAULT status to ntpd without a reference clock driver, or with a reference clock driver that ntpd understands will not provide time but only status. That driver could be similar to SHM (or it could be SHM with a fudge flag set), in that it could use a shared memory segment where an external program puts a flag indicating the validity of the PPS source. My GPSDO is very good at providing PPS and 10 MHz, but otherwise it is old and rusty. Apparently many of them are going around in hobbyist circles. It does provide IRIG output, but that is not really useful as you already indicate (and difficult to interface as well), and an RS232 command/status interface that only provides UTC/GPS time but no date. However, on that interface there is a good indication of the search/lock status and the momentary (estimated) error, which I use to generate nagios alerts when it goes haywire. For that, a daemon is running that polls it every few seconds, which could be extended to write the SHM flag. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-31, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). There are complications. While the clock would probably be capable of maintaining the time within a second, it cannot be set to a reasonable accuracy. On the system-under-test, i.e. with the locked PPS source, the LOCL clock, and the unreachable external references, I did a reboot. A reboot is a restart and on a restart you need an external source for the seconds. Result: after the reboot, the system time was off by 270ms and the PPS was not trusted. The time remained off by 270ms as indicated by a 270ms offset on PPS (marked with an x), and remained freerunning. Yes, not entirely surprizing, especially considering the way ntp is designed right now. This is a combination of bad ntpd design, and restart when an external source is mandatory. Only after I managed to get a reachable external reference again, it stepped 270ms and then locked to the PPS again. Not surprizing. A restart is NOT a situation under which I would expect the local clock to keep resonable time, not least because when the computer is off, it does not keep time at all. And the RTC is in general a lousy source of time. Of course this would not have happened when the system had remained running, as it normally would. I rebooted it for major network reconfig and after that I was able to find NTP servers on another internet connection so it now has 3 external references again. I think you should be prepared for an offset up to half a second when saving the time to the CMOS clock, rebooting, and reading it back. Not good. The problem is usually drift. The drift in a cmos clock is of order of 10s to hundreds of PPM. At 100PPM, the clock will be out by a second after only 3 hrs. I never claimed that relying on the RTC was a good idea. I claim that relying on the local system clock to keep time to within a second after having been disciplined by ntpd and between ntpd PPS queries is a good assumption. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh un...@invalid.ca wrote: On 2014-07-31, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). There are complications. While the clock would probably be capable of maintaining the time within a second, it cannot be set to a reasonable accuracy. On the system-under-test, i.e. with the locked PPS source, the LOCL clock, and the unreachable external references, I did a reboot. A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. I think you should be prepared for an offset up to half a second when saving the time to the CMOS clock, rebooting, and reading it back. Not good. The problem is usually drift. The drift in a cmos clock is of order of 10s to hundreds of PPM. At 100PPM, the clock will be out by a second after only 3 hrs. No, the problem is that the CMOS can only be set to an accuracy of one second. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Martin Burnicki writes: Miroslav Lichvar wrote: Agreed, it would be useful to have an option to specify the PPS-time source association for each PPS refclock directly. In chrony, this is done with the lock refclock option. It's typically used like this: refclock SHM 0 offset 0.5 refid SHM0 noselect refclock PPS /dev/pps0 lock SHM0 The SHM refclock (e.g. GPS NMEA) is configured with the noselect option so it's never selected and only used by the PPS refclock to align the pulses to the SHM time. When SHM stops getting new samples the PPS refclock will stop immediately too. When the PPS refclock doesn't have the lock option and the local stratum option is not used, the pulses will be accepted only when the clock is synchronized, first to another refclock or NTP server and then possibly the PPS refclock itself. If local stratum is enabled, the PPS will work immediately without any other sources, but the clock obviously needs to be already close to the correct time on start, otherwise it will be off by a whole number of seconds. This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: 1) A refclock provides absolute time, status, and a PPS signal 1a) The refclock contains a good oscillator, so the PPS signal could be accepted for some time after the refclock started freewheeling. 1b) The refclock only has a simply xtal which starts drifting immediately when the refclock starts freewheeling. In either of these cases we could have a parameter for the appropriate value of PHI for that clock. 2) A good PPS signal is available, but no absolute time (e.g. in case of a Rubidium) 2a) Some status information is available telling if the PPS signal is good or not 2b) No information on the PPS quality is available Agreed - I've been trying to sell DLM on this idea for years. Case 1a) or 1b) is usually true for most GPS receivers. 1a) is for example the case for Meinberg GPS receivers, which have a good oscillator (TCXO or even OCXO) on board, but in contrast to the GPSDO mentioned by Rob, which doesn't provide absolute time, the Meinberg devices do. NTP's parse driver supports the concept of a trust time which means that *if* the time source has been synchronized and then starts freewheeling you can configure a time interval during which the parse driver doesn't tell ntpd that the refclock has started freewheeling, and thus the refclock plus associated PPS signal are still accepted for that interval. So only after the trust time has been expired the PPS signal is discarded. 1b) is the case for most cheap GPS receivers. If they loose the satellite signal they often start drifting quite a lot, in which case it could make sense to discard the PPS signal immediately. In terms of the trust time mentioned in 1a) this would mean the trust time is very short, or even 0. If the value of phi cannot be easily measured (or is not provided by the manufacturer), this would be a better choice. And the General Timestamp API (GTSAPI) project from NTF would nicely wrap this information into a timestamp for you, directly. For cases 2a) and 2b) there is no absolute time available from the PPS source. If a status is available this could be evaluated, eventually with a trust time. If no status is available you simply could always trust the PPS source (unlimited trust time), or you shouldn't use it as reference time source. ;-) If devices that do not have absolute clocks have a way to track relative time the GTSAPI would provide the error bounds information usefully there, too. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob writes: A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. Except when the CMOS battery is insufficiently alive. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-31 07:31, Martin Burnicki wrote: Miroslav Lichvar wrote: This sounds good. I think we'd have to distinguish some basic cases a few of which immediately come to my mind: 1) A refclock provides absolute time, status, and a PPS signal 1a) The refclock contains a good oscillator, so the PPS signal could be accepted for some time after the refclock started freewheeling. 1b) The refclock only has a simply xtal which starts drifting immediately when the refclock starts freewheeling. 2) A good PPS signal is available, but no absolute time (e.g. in case of a Rubidium) 2a) Some status information is available telling if the PPS signal is good or not 2b) No information on the PPS quality is available Case 1a) or 1b) is usually true for most GPS receivers. 1a) is for example the case for Meinberg GPS receivers, which have a good oscillator (TCXO or even OCXO) on board, but in contrast to the GPSDO mentioned by Rob, which doesn't provide absolute time, the Meinberg devices do. NTP's parse driver supports the concept of a trust time which means that *if* the time source has been synchronized and then starts freewheeling you can configure a time interval during which the parse driver doesn't tell ntpd that the refclock has started freewheeling, and thus the refclock plus associated PPS signal are still accepted for that interval. So only after the trust time has been expired the PPS signal is discarded. 1b) is the case for most cheap GPS receivers. If they loose the satellite signal they often start drifting quite a lot, in which case it could make sense to discard the PPS signal immediately. In terms of the trust time mentioned in 1a) this would mean the trust time is very short, or even 0. Some of the cheap GPS receivers derive the PPS from the RF carrier sent by the constellation. The PPS output is available if the oscillator is still receiving a synchronizing signal from the receiver even if the GPS CPU itself has unlocked. Unlocking is far more frequent than a total loss of signal. As an example, I have a GlobalSat receiver which uses the satellite signal to control the oscillator separate from the time output. Occasionally the lock is lost so the time output drifts or stops but the receiver still sees RF energy from the satellites at the receiver input which keeps the PPS under reasonable control (slight jitter of a up to a few milliseconds but not bad). If I could keep my system ticking with the PPS input even though other clocks were dead I'd be ok. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Harlan Stenn st...@ntp.org wrote: Rob writes: A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. Except when the CMOS battery is insufficiently alive. H That is no problem unless you actually remove power from the machine. In this case it was a reboot command so no power ops involved at all, but even a halt will not cause problems in this case. Only when you pull the plug (e.g. to do some hardware work), the battery comes into action. No, what is the real problem is that the CMOS clock has its own crystal and prescaler to divide down to one-second pulses, and the only thing that can be loaded is the counter. So you have a +/- .5 second uncertainty when just loading a new time into the CMOS clock and retrieving it later on a reboot. This could probably be circumvented by storing the measured subsecond offset of the CMOS clock in a disk file during shutdown (or when updating the CMOS clock) and using that during the boot procedure. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-31, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-07-31, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote: Unlike otherwise stated in this thread I don't think it's a good idea to leave the 1 PPS signal alone disciplining the time of the NTP server. This can easily yield unforeseen problems, similarly as if you use an IRIG time reference which only provides day-of-year and time-of-day, but no year number. If you don't take care then such signal can be accepted and provide a valid time which is off by an integral number of years. My point is that most of the internal clocks on computers are well able to maintain the time to better than a second for a long time, even if they were freewheeling, and if disciplined by a PPS, they are able to maintain the time forever (well, until the next power failure anyway). There are complications. While the clock would probably be capable of maintaining the time within a second, it cannot be set to a reasonable accuracy. On the system-under-test, i.e. with the locked PPS source, the LOCL clock, and the unreachable external references, I did a reboot. A reboot is a restart and on a restart you need an external source for the seconds. Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. Sure it could. And how does the system know what a short reboot is. ntpd can hardly be expected to root throught the filesysytem trying to figure out how long it has been since last boot, or how far off the rtc is. ntpd distrusts the rtc at the best of times. I think you should be prepared for an offset up to half a second when saving the time to the CMOS clock, rebooting, and reading it back. Not good. The problem is usually drift. The drift in a cmos clock is of order of 10s to hundreds of PPM. At 100PPM, the clock will be out by a second after only 3 hrs. No, the problem is that the CMOS can only be set to an accuracy of one second. Well, actually no. It can be set to an accuracy of about 1usec. And read to that accuracy. It only reports the time the second it is true. But It emits an interrupt on the turnover of the second. Of course for some Linux kernels, the handling of that interrupt is seriously broken, but even then it can be read by polling to a few usec. Setting is a rococo procedure. You have to write to the rtc something like .5 sec before you want that second to fall. But that can set it to usec accuracy. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh un...@invalid.ca wrote: Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. Sure it could. And how does the system know what a short reboot is. ntpd can hardly be expected to root throught the filesysytem trying to figure out how long it has been since last boot, or how far off the rtc is. ntpd distrusts the rtc at the best of times. Well, ntpd reads the stored estimated frequency error from disk too. The fact that it does all that is within its capacity to destroy this value does not matter. No, the problem is that the CMOS can only be set to an accuracy of one second. Well, actually no. It can be set to an accuracy of about 1usec. And read to that accuracy. It only reports the time the second it is true. But It emits an interrupt on the turnover of the second. Of course for some Linux kernels, the handling of that interrupt is seriously broken, but even then it can be read by polling to a few usec. Setting is a rococo procedure. You have to write to the rtc something like .5 sec before you want that second to fall. But that can set it to usec accuracy. You are mistaken. The running clock in Linux can be set and read that accurately, but not the CMOS clock. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 30/07/14 23:15, Harlan Stenn wrote: The reason to use a middle range stratum for a local refclock is so that nobody else will start to belive that source if that machine gets access to outside machines again. You use a high stratum number for that. The default is too low for nearly all time island cases, and if you have a time island that really has that many strata, that is the case when you should be carefully choosing values, not accepting defaults. I therefore assumed that the default had been chosen for the synchronized by other means case. That case goes back for the best part of two decades. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-31, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. Sure it could. And how does the system know what a short reboot is. ntpd can hardly be expected to root throught the filesysytem trying to figure out how long it has been since last boot, or how far off the rtc is. ntpd distrusts the rtc at the best of times. Well, ntpd reads the stored estimated frequency error from disk too. The fact that it does all that is within its capacity to destroy this value does not matter. No, the problem is that the CMOS can only be set to an accuracy of one second. Well, actually no. It can be set to an accuracy of about 1usec. And read to that accuracy. It only reports the time the second it is true. But It emits an interrupt on the turnover of the second. Of course for some Linux kernels, the handling of that interrupt is seriously broken, but even then it can be read by polling to a few usec. Setting is a rococo procedure. You have to write to the rtc something like .5 sec before you want that second to fall. But that can set it to usec accuracy. You are mistaken. The running clock in Linux can be set and read that accurately, but not the CMOS clock. I think you need to read up on the cmos clock. As I said, it reports only the seconds, but is settable and readable to microseconds. The seconds rollover is exactly on the second so polling could do it, but it also issues and interrupt. And it is also settable to the order of microseconds. Look at the code in hwclock as an example. Or the code in chrony. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-31, William Unruh un...@invalid.ca wrote: On 2014-07-31, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: Why? The time is copied to the CMOS clock regularly, and one could expect that during the short reboot the CMOS would not drift away so much that the time could not be synced to the PPS unambiguously. Sure it could. And how does the system know what a short reboot is. ntpd can hardly be expected to root throught the filesysytem trying to figure out how long it has been since last boot, or how far off the rtc is. ntpd distrusts the rtc at the best of times. Well, ntpd reads the stored estimated frequency error from disk too. The fact that it does all that is within its capacity to destroy this value does not matter. No, the problem is that the CMOS can only be set to an accuracy of one second. Well, actually no. It can be set to an accuracy of about 1usec. And read to that accuracy. It only reports the time the second it is true. But It emits an interrupt on the turnover of the second. Of course for some Linux kernels, the handling of that interrupt is seriously broken, but even then it can be read by polling to a few usec. Setting is a rococo procedure. You have to write to the rtc something like .5 sec before you want that second to fall. But that can set it to usec accuracy. You are mistaken. The running clock in Linux can be set and read that accurately, but not the CMOS clock. I think you need to read up on the cmos clock. As I said, it reports only the seconds, but is settable and readable to microseconds. The seconds rollover is exactly on the second so polling could do it, but it also issues and interrupt. And it is also settable to the order of microseconds. Look at the code in hwclock as an example. Or the code in chrony. Just so you do not have to take my word, here the comments in hwclock.c /* * The Hardware Clock can only be set to any integer time plus * one * half second. The integer time is required because there is * no * interface to set or get a fractional second. The additional * half * second is because the Hardware Clock updates to the following * second precisely 500 ms (not 1 second!) after you release the * divider reset (after setting the new time) - see description * of * DV2, DV1, DV0 in Register A in the MC146818A data sheet (and * note * that although that document doesn't say so, real-world code * seems * to expect that the SET bit in Register B functions the same * way). * That means that, e.g., when you set the clock to 1:02:03, it * effectively really sets it to 1:02:03.5, because it will * update to * 1:02:04 only half a second later. Our caller passes the * desired * integer Hardware Clock time in sethwtime, and the * corresponding * system time (which may have a fractional part, and which may * or may * not be the same!) in refsystime. In an ideal situation, we * would * then apply sethwtime to the Hardware Clock at * refsystime+500ms, so * that when the Hardware Clock ticks forward to sethwtime+1s * half a * second later at refsystime+1000ms, everything is in sync. So * we * spin, waiting for gettimeofday() to return a time at or after * that * time (refsystime+500ms) up to a tolerance value, initially * 1ms. If * we miss that time due to being preempted for some other * process, * then we increase the margin a little bit (initially 1ms, * doubling * each time), add 1 second (or more, if needed to get a time * that is * in the future) to both the time for which we are waiting and * the * time that we will apply to the Hardware Clock, and start * waiting * again. * * For example, the caller requests that we set the Hardware * Clock to * 1:02:03, with reference time (current system time) = * 6:07:08.250. * We want the Hardware Clock to update to 1:02:04 at * 6:07:09.250 on * the system clock, and the first such update will occur 0.500 * seconds after we write to the Hardware Clock, so we spin * until the * system clock reads 6:07:08.750. If we get there, great, but * let's * imagine the system is so heavily loaded that our process is * preempted and by the time we get to run again, the system * clock * reads 6:07:11.990. We now want to wait until the next * xx:xx:xx.750 * time, which is 6:07:12.750 (4.5 seconds after the reference * time), * at which point we will set the Hardware
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh un...@invalid.ca wrote: I think you need to read up on the cmos clock. As I said, it reports only the seconds, but is settable and readable to microseconds. The CMOS clock is running off a 32768Hz crystal, so no way it can be more accurately set than 30us. Even it could be possible in theory to set and read it accurately to that value, apparently Linux does not do that. That makes it questionable to me if it can be done. I could understand when Windows would not exploit such a capability, when there is no monetary gain to be made. But the Linux developers are too proud and too nerdy to skip such an opportunity. The fact that there is a microsecond-accurate API to set and read the clock does not indicate anything. Remember Linux can run on any platform, and there may be other platforms, now or in the future, that can use this accuracy. In my experience, the clock always jumps a few hundred milliseconds when rebooting a PC. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Thu, Jul 31, 2014 at 12:17 PM, A C agcarver+...@acarver.net wrote: Some of the cheap GPS receivers derive the PPS from the RF carrier sent by the constellation. The PPS output is available if the oscillator is still receiving a synchronizing signal from the receiver even if the GPS CPU itself has unlocked. Unlocking is far more frequent than a total loss of signal. As an example, I have a GlobalSat receiver which uses the satellite signal to control the oscillator separate from the time output. Occasionally the lock is lost so the time output drifts or stops but the receiver still sees RF energy from the satellites at the receiver input which keeps the PPS under reasonable control (slight jitter of a up to a few milliseconds but not bad). If I could keep my system ticking with the PPS input even though other clocks were dead I'd be ok. As someone intimately familiar with the design of GPS receivers, this makes no sense to me. Could you elaborate? Henry ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-31 16:15, Henry Hallam wrote: On Thu, Jul 31, 2014 at 12:17 PM, A C agcarver+...@acarver.net wrote: Some of the cheap GPS receivers derive the PPS from the RF carrier sent by the constellation. The PPS output is available if the oscillator is still receiving a synchronizing signal from the receiver even if the GPS CPU itself has unlocked. Unlocking is far more frequent than a total loss of signal. As an example, I have a GlobalSat receiver which uses the satellite signal to control the oscillator separate from the time output. Occasionally the lock is lost so the time output drifts or stops but the receiver still sees RF energy from the satellites at the receiver input which keeps the PPS under reasonable control (slight jitter of a up to a few milliseconds but not bad). If I could keep my system ticking with the PPS input even though other clocks were dead I'd be ok. As someone intimately familiar with the design of GPS receivers, this makes no sense to me. Could you elaborate? Henry It's basing the oscillator control off the chipped C/A code. The autocorrelator usually can see a bird but the BER may be too high to allow a successful decode of the data. However, the signal stream itself is usually sufficient to provide a oscillator reference. So some designs can funnel this (often through a filter to clean it up) over to the oscillator for discipline and the PPS pulse can be clocked from the disciplined oscillator without needing an actual fix. The only thing that happens when a fix is lost is that the pulse on the PPS line doesn't have a matching timestamp coming out of the CPU. A similar principle has been used to get some useful information out of the P(Y)-coded signal without actually knowing the encryption keys for it. A few GPS receivers meant for survey purposes have been able to use some of the P(Y)-code to clean up jitter and fine tune oscillators to reduce the DOP in addition to simple time averaging of the normal C/A signal. I got to see one in action many years ago, it did quite well compared to a normal commercial receiver. The true data inside the P(Y)-code is never known but the stream from the autocorrelator can keep the oscillator on track. Chasing P(Y) is much more difficult than C/A so you're not going to find that trick in any cheap consumer GPS. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Paradoxically , the LCL clock is fine when there are no refclocks. That is, when you don't need or want it. remote refid st t when poll reach delay offset jitter == *127.127.1.1 .LOCL. 5 l8 64 3770.0000.000 0.008 +192.168.1.4 .PPS1. 1 u5 16 3770.900 -0.022 0.030 +192.168.1.23.GPS.1 u 23 64 3770.804 -0.134 0.017 Le 30 juil. 2014 à 06:46, Brian Inglis a écrit : On 2014-07-29 21:32, Paul wrote: On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: As I discovered recently under similar circumstances, offline servers are considered falsetickers, and if you have insufficient other candidates, or fewer than 3, nothing gets selected. I don't think I'm seeing what you're seeing but I could be confused. I believe I mentioned the same thing last time around on this topic. Default for minsane is 3, if that is where you are confused. Not seen this topic mentioned in the last year or more. ntpd --version;ntpq -pn ntpd 4.2.7p440@1.2483-o Tue Apr 22 11:51:47 UTC 2014 (6) remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l28 3770.000 -0.002 0.004 *127.127.1.0 .LOCL. 12 l 65800.0000.000 0.004 192.168.0.210 .GPS.1 u 22 32 3771.304 -0.080 0.028 or just using LOCL ... remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l58 3770.000 -0.005 0.008 *127.127.1.0 .LOCL. 12 l 608 2000.0000.000 0.008 naturally you need to let NTP discipline your clock and a cold start requires something to set it. These statuses show the same issue with local clock reach, implying if reach stays at zero, sync will be lost and PPS become a falseticker without anything to number seconds for too long. Read the thread about the OP's config and problems. -- Take care. Thanks, Brian Inglis ___ 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] LOCL clock reachability not 377?
On 2014-07-30, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2014-07-29 21:32, Paul wrote: On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: These statuses show the same issue with local clock reach, implying if reach stays at zero, sync will be lost and PPS become a falseticker without anything to number seconds for too long. Once ntpd has started using the pps clock, there is no need for anything to number the seconds. The system itself does that perfectly fine. There is no way that the system is going jump a second, unless it is a very very badly broken system. Ie, one only needs something to number the seconds at the beginning when you start up PPS. Thereafter pps on its own is perfectly capable to maintaining the time. Read the thread about the OP's config and problems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh un...@invalid.ca wrote: On 2014-07-30, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2014-07-29 21:32, Paul wrote: On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: These statuses show the same issue with local clock reach, implying if reach stays at zero, sync will be lost and PPS become a falseticker without anything to number seconds for too long. Once ntpd has started using the pps clock, there is no need for anything to number the seconds. The system itself does that perfectly fine. There is no way that the system is going jump a second, unless it is a very very badly broken system. Ie, one only needs something to number the seconds at the beginning when you start up PPS. Thereafter pps on its own is perfectly capable to maintaining the time. Yes, with the exception of those silly leap seconds, of course. But they were implemented incorrectly. When leapseconds went in the timezone definitions and the NTP clock ticked in TAI, it would work. However, when I lose my external NTP servers because again someone is entering ACLs to fight some network storm, I prefer my clock to be locked at least until the next leap second so I can find a workaround for the problem. What happened instead is that it started to drift shortly after. I got alerted by nagios when it was 10us off, which was within an hour or so. That is why I added the LOCL clock and it solved that issue, but revealed another one. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
mike cook michael.c...@sfr.fr wrote: Paradoxically , the LCL clock is fine when there are no refclocks. That is, when you don't need or want it. remote refid st t when poll reach delay offset jitter == *127.127.1.1 .LOCL. 5 l8 64 3770.0000.000 0.008 +192.168.1.4 .PPS1. 1 u5 16 3770.900 -0.022 0.030 +192.168.1.23.GPS.1 u 23 64 3770.804 -0.134 0.017 Maybe someone tried to handle that condition and had the sense of the test the wrong way around??? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Le 30 juil. 2014 à 11:00, Rob a écrit : mike cook michael.c...@sfr.fr wrote: Paradoxically , the LCL clock is fine when there are no refclocks. That is, when you don't need or want it. remote refid st t when poll reach delay offset jitter == *127.127.1.1 .LOCL. 5 l8 64 3770.0000.000 0.008 +192.168.1.4 .PPS1. 1 u5 16 3770.900 -0.022 0.030 +192.168.1.23.GPS.1 u 23 64 3770.804 -0.134 0.017 Maybe someone tried to handle that condition and had the sense of the test the wrong way around??? Someone who knows the code would pin this down in a second. What I think is happening is that the local clock driver along with all other refclocks/servers gets polled once at initialization time, so we see reach 1, and then there is some condition tested (do we have another, better refclock?) which if true causes the local clock to be left out out of the loop and so it's reach drifts, 2,4,8,10 etc. till the local clock is flagged a false ticker. ___ 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] LOCL clock reachability not 377?
On Wed, Jul 30, 2014 at 12:46 AM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: Not seen this topic mentioned in the last year or more. See my posts about PPS is a falseticker? of Sun Jun 15 14:37:32 UTC 2014 and Wed Jun 18 20:59:03 UTC 2014 . These statuses show the same issue with local clock reach, implying if reach stays at zero, sync will be lost and PPS become a falseticker without anything to number seconds for too long. But it doesn't -- as previously mentioned. The reach bit cycles up until it is 0, then the LOCAL clock is no longer reference clock, the PPS status changes to x remote refid st t when poll reach delay offset jitter == xPPS(0) .PPS.0 l9 16 3770.0000.001 0.000 LOCAL(0).LOCL. 5 l 536 6400.0000.000 0.000 The next cycle the LOCAL clock starts at reach 1 again, becomes the reference (*), and PPS status changes to o again. or here: Looks like a bug anterior to your version. I see the same issue with version=ntpd 4.2.6p5 at 1.2349-o whether or not there is a preferred local clock or not, and whether or not there are other active server associations. Read the thread about the OP's config and problems. I did. And like others I see this: oPPS(0) .GPPS. 0 l38 3770.0000.001 0.008 *LOCAL(0).LOCL. 12 l 66800.0000.000 0.008 oPPS(0) .GPPS. 0 l18 3770.0000.003 0.008 *LOCAL(0).LOCL. 12 l-810.0000.000 0.008 oPPS(0) .GPPS. 0 l68 3770.0000.003 0.008 *LOCAL(0).LOCL. 12 l 21840.0000.000 0.008 oPPS(0) .GPPS. 0 l18 3770.0000.001 0.008 *LOCAL(0).LOCL. 12 l 568 2000.0000.000 0.008 oPPS(0) .GPPS. 0 l88 3770.0000.005 0.008 LOCAL(0).LOCL. 12 l 71800.0000.000 0.008 oPPS(0) .GPPS. 0 l18 3770.0000.005 0.008 *LOCAL(0).LOCL. 12 l8820.0000.000 0.008 etc. etc. I don't see LOCL marked as a falseticker. This clock has been running and keeping acceptable time for weeks (as an experiment). Since this last came up. I mentioned the version because I *don't* have the OP's various problems -- either in configuration or execution which I think, as I said last month, are the OP's real problem BTW, the other snippet seems to refute the idea that you can't run like this with varying minpoll (although the peer was marked noselect). Or perhaps I misunderstand the assertion. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-30, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-07-30, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2014-07-29 21:32, Paul wrote: On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: These statuses show the same issue with local clock reach, implying if reach stays at zero, sync will be lost and PPS become a falseticker without anything to number seconds for too long. Once ntpd has started using the pps clock, there is no need for anything to number the seconds. The system itself does that perfectly fine. There is no way that the system is going jump a second, unless it is a very very badly broken system. Ie, one only needs something to number the seconds at the beginning when you start up PPS. Thereafter pps on its own is perfectly capable to maintaining the time. Yes, with the exception of those silly leap seconds, of course. But they were implemented incorrectly. When leapseconds went in the timezone definitions and the NTP clock ticked in TAI, it would work. I do not believe this was ever the case as the default. I agree that one needs an external source, or a leapseconds file to tell ntpd when to impliment leapseconds. However, when I lose my external NTP servers because again someone is entering ACLs to fight some network storm, I prefer my clock to be locked at least until the next leap second so I can find a workaround for the problem. What happened instead is that it started to drift shortly after. I got alerted by nagios when it was 10us off, which was within an hour or so. That is why I added the LOCL clock and it solved that issue, but revealed another one. I regard that as a bug. Whether the ntp developers do is another question. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 30/07/14 07:50, mike cook wrote: Paradoxically , the LCL clock is fine when there are no refclocks. That is, when you don't need or want it. My understanding was that the original purpose of the local clock was to cover the case when there were no NTP managed reference clocks (but there was another reference clock disciplining the machine with UTC). That's why the default stratum is in the mid-range, rather than the high numbers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob wrote: What happened instead is that it started to drift shortly after. I got alerted by nagios when it was 10us off, which was within an hour or so. That is why I added the LOCL clock and it solved that issue, but revealed another one. Have you tried orphan mode instead of locl? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
David Woolley writes: On 30/07/14 07:50, mike cook wrote: Paradoxically , the LCL clock is fine when there are no refclocks. That is, when you don't need or want it. My understanding was that the original purpose of the local clock was to cover the case when there were no NTP managed reference clocks (but there was another reference clock disciplining the machine with UTC). That's why the default stratum is in the mid-range, rather than the high numbers. The Undisicplined Local Refclock driver was originally designed to solve the problem where a group of machines would all take their own paths off into the weeds if nobody had a connection to a real clock. For this general case, orphan mode is now the recommended solution. Later it was discovered that folks like NIST could use the local refclock with the LOCKCLOCK code, as they had other software that controleld the system clock and therefore the local refclock was usable as a time source. The reason to use a middle range stratum for a local refclock is so that nobody else will start to belive that source if that machine gets access to outside machines again. See http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock for more information about the stratum configuation, in the Dual Time Servers section. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] LOCL clock reachability not 377?
I while ago I discussed the problem with an ntpd server that has to be synchronized to a GPSDO that provides PPS but no absolute time. After the usual discussion about you should not want that, a solution was finally found using the following tricky workaround: # PPS via ATOM server 127.127.22.0 minpoll 4 maxpoll 4 prefer # external servers, all with prefer, to serve as reference for PPS server 1.2.3.4 prefer server 5.6.7.8 prefer server 9.8.7.6 prefer This worked OK, the time would first be synced to those 3 external servers and when in lock with those the PPS would be enabled and the time locked to that. Fine. But now all my 3 external sources became unreachable at the same time, and ntpd decided that it should let the time wander away slowly. Of course I don't like that so I added: # local clock to continue PPS sync when all external servers fail server 127.127.1.0 prefer The reasoning is that once the time is locked to PPS, it should remain close enough for the local clock to be trusted as an absolute time source (this system is rarely rebooted). This appears to work OK, output from the ntpq -p command is now: remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l 14 16 3770.0000.000 0.001 *LOCAL(0).LOCL. 5 l 93 6420.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 Good. But why is the reach of the LOCAL clock 2 and not 377? The reach bit cycles up until it is 0, then the LOCAL clock is no longer reference clock, the PPS status changes to x remote refid st t when poll reach delay offset jitter == xPPS(0) .PPS.0 l9 16 3770.0000.001 0.000 LOCAL(0).LOCL. 5 l 536 6400.0000.000 0.000 The next cycle the LOCAL clock starts at reach 1 again, becomes the reference (*), and PPS status changes to o again. remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l 12 16 3770.0000.000 0.000 *LOCAL(0).LOCL. 5 l 11 6410.0000.000 0.000 What is the reasoning behind this? ntpd 4.2.7p444@1.2483-o ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-29, Rob nom...@example.com wrote: I while ago I discussed the problem with an ntpd server that has to be synchronized to a GPSDO that provides PPS but no absolute time. After the usual discussion about you should not want that, a solution was finally found using the following tricky workaround: # PPS via ATOM server 127.127.22.0 minpoll 4 maxpoll 4 prefer # external servers, all with prefer, to serve as reference for PPS server 1.2.3.4 prefer server 5.6.7.8 prefer server 9.8.7.6 prefer This worked OK, the time would first be synced to those 3 external servers and when in lock with those the PPS would be enabled and the time locked to that. Fine. But now all my 3 external sources became unreachable at the same time, and ntpd decided that it should let the time wander away slowly. Of course I don't like that so I added: # local clock to continue PPS sync when all external servers fail server 127.127.1.0 prefer Argh, no, never do that. Never use the the local refclock. It is useless for almost all purposes (that there are some corner cases where it is useful is the only reason it is there-- but it causes far more problems than it ever has solved:-) The reasoning is that once the time is locked to PPS, it should remain close enough for the local clock to be trusted as an absolute time source (this system is rarely rebooted). It should do that even if the external clocks disconnect. But I do not know if in your setup your system refuses to use the ATOM if the external clocks disconnect-- that would be stupid, but This appears to work OK, output from the ntpq -p command is now: remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l 14 16 3770.0000.000 0.001 *LOCAL(0).LOCL. 5 l 93 6420.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 Good. But why is the reach of the LOCAL clock 2 and not 377? The reach bit cycles up until it is 0, then the LOCAL clock is no longer reference clock, the PPS status changes to x remote refid st t when poll reach delay offset jitter == xPPS(0) .PPS.0 l9 16 3770.0000.001 0.000 LOCAL(0).LOCL. 5 l 536 6400.0000.000 0.000 The next cycle the LOCAL clock starts at reach 1 again, becomes the reference (*), and PPS status changes to o again. remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l 12 16 3770.0000.000 0.000 *LOCAL(0).LOCL. 5 l 11 6410.0000.000 0.000 What is the reasoning behind this? Sounds to me like a bug. ntpd 4.2.7p444@1.2483-o ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-29 11:33, William Unruh wrote: On 2014-07-29, Rob nom...@example.com wrote: The reasoning is that once the time is locked to PPS, it should remain close enough for the local clock to be trusted as an absolute time source (this system is rarely rebooted). It should do that even if the external clocks disconnect. But I do not know if in your setup your system refuses to use the ATOM if the external clocks disconnect-- that would be stupid, but ATOM always stops when the prefer peers die even if there are other peers available but not marked prefer. I'm still running an older development version (4.2.7p270) that I modified to remove all the prefer code so that the selection algorithm continues to run normally without shutting down the ATOM driver as peers come and go. If all the peers die then ATOM will stop, too since there's no more selected clock. Modifying the code also gave me the opportunity to decouple the minpoll/maxpoll pinng that happens between the local refclocks and external servers[1] -- the suggested configurations for many refclocks have maxpolls that conflict to the operational etiquette for Internet servers plus it prevents the automatic scaling of the poll time to those servers. [1] ATOM's own documentation suggest maxpoll of 4 to 6 to keep the clock synced to PPS. But that pins everything else to the same value unless a minpoll is set on the other servers. However, once minpoll is set, the combination of the pinning by ATOM plus the forced required minpoll means the external servers never change polling period nor do they get the opportunity to start at the short 64s polling interval during initial daemon startup and then ramp to some comfortable value in the 1000 second range. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh un...@invalid.ca wrote: On 2014-07-29, Rob nom...@example.com wrote: I while ago I discussed the problem with an ntpd server that has to be synchronized to a GPSDO that provides PPS but no absolute time. After the usual discussion about you should not want that, a solution was finally found using the following tricky workaround: # PPS via ATOM server 127.127.22.0 minpoll 4 maxpoll 4 prefer # external servers, all with prefer, to serve as reference for PPS server 1.2.3.4 prefer server 5.6.7.8 prefer server 9.8.7.6 prefer This worked OK, the time would first be synced to those 3 external servers and when in lock with those the PPS would be enabled and the time locked to that. Fine. But now all my 3 external sources became unreachable at the same time, and ntpd decided that it should let the time wander away slowly. Of course I don't like that so I added: # local clock to continue PPS sync when all external servers fail server 127.127.1.0 prefer Argh, no, never do that. Never use the the local refclock. It is useless for almost all purposes (that there are some corner cases where it is useful is the only reason it is there-- but it causes far more problems than it ever has solved:-) Please read the message carefully before you utter your standard comment. As I carefully described, in this case it is useful and required. Not because the local clock is a good idea, but because the PPS clock in ntpd is implemented in a braindead way. This has been already discussed the previous time. The reasoning is that once the time is locked to PPS, it should remain close enough for the local clock to be trusted as an absolute time source (this system is rarely rebooted). It should do that even if the external clocks disconnect. But I do not know if in your setup your system refuses to use the ATOM if the external clocks disconnect-- that would be stupid, but I already discussed that. It is stupid, but it is how the ATOM clock works. It uses hacks, not properly designed methods, to determine the validity of the PPS reference. But that is not going to change, so we need to work around it. (by putting prefer on all the server lines, and apparently also by including a local clock) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
Rob, Looks like a bug anterior to your version. I see the same issue with version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local clock or not, and whether or not there are other active server associations. One for Harlen if it has not already been flagged. Tue Jul 29 21:32:48 CEST 2014 remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 25 6410.0000.000 0.008 o127.127.22.1.PPS1. 0 l8 1610.0000.002 0.008 ... remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 300 64 200.0000.000 0.008 o127.127.22.1.PPS1. 0 l 11 16 3770.0000.004 0.008 remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 437 64 1000.0000.000 0.008 o127.127.22.1.PPS1. 0 l4 16 3770.0000.004 0.008 snip Le 29 juil. 2014 à 19:14, Rob a écrit : This appears to work OK, output from the ntpq -p command is now: remote refid st t when poll reach delay offset jitter == oPPS(0) .PPS.0 l 14 16 3770.0000.000 0.001 *LOCAL(0).LOCL. 5 l 93 6420.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 EXTERNAL SERVER .INIT. 16 u- 25600.0000.000 0.000 Good. But why is the reach of the LOCAL clock 2 and not 377? The reach bit cycles up until it is 0, then the LOCAL clock is no longer reference clock, the PPS status changes to x ___ 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] LOCL clock reachability not 377?
On 2014-07-29, A C agcarver+...@acarver.net wrote: On 2014-07-29 11:33, William Unruh wrote: On 2014-07-29, Rob nom...@example.com wrote: The reasoning is that once the time is locked to PPS, it should remain close enough for the local clock to be trusted as an absolute time source (this system is rarely rebooted). It should do that even if the external clocks disconnect. But I do not know if in your setup your system refuses to use the ATOM if the external clocks disconnect-- that would be stupid, but ATOM always stops when the prefer peers die even if there are other peers available but not marked prefer. I'm still running an older development version (4.2.7p270) that I modified to remove all the prefer code so that the selection algorithm continues to run normally without shutting down the ATOM driver as peers come and go. If all the peers die then ATOM will stop, too since there's no more selected clock. Which is of course very silly, since once you get within .5 sec of the correct time, pps is more than capable of keeping the system on time (to microseconds-- it to 100 better than that .5 sec. It is like Thowing out a calender because it does not indicate with millenium you are in. Ie, once ATOM has been selected, it should remain selected, unless it also gets switched of for a few hours, or there is a disagreement between ATOM and some other selected clock source by more than a second. Modifying the code also gave me the opportunity to decouple the minpoll/maxpoll pinng that happens between the local refclocks and external servers[1] -- the suggested configurations for many refclocks have maxpolls that conflict to the operational etiquette for Internet servers plus it prevents the automatic scaling of the poll time to those servers. [1] ATOM's own documentation suggest maxpoll of 4 to 6 to keep the clock synced to PPS. But that pins everything else to the same value unless a minpoll is set on the other servers. However, once minpoll is set, the combination of the pinning by ATOM plus the forced required minpoll means the external servers never change polling period nor do they get the opportunity to start at the short 64s polling interval during initial daemon startup and then ramp to some comfortable value in the 1000 second range. Is that really right? I would have expected each clock source to have its own minpoll/maxpoll, independent of any other source. Are you sure that is not the case? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-29 12:46, William Unruh wrote: On 2014-07-29, A C agcarver+...@acarver.net wrote: On 2014-07-29 11:33, William Unruh wrote: [1] ATOM's own documentation suggest maxpoll of 4 to 6 to keep the clock synced to PPS. But that pins everything else to the same value unless a minpoll is set on the other servers. However, once minpoll is set, the combination of the pinning by ATOM plus the forced required minpoll means the external servers never change polling period nor do they get the opportunity to start at the short 64s polling interval during initial daemon startup and then ramp to some comfortable value in the 1000 second range. Is that really right? I would have expected each clock source to have its own minpoll/maxpoll, independent of any other source. Are you sure that is not the case? Check the source code, it's in there. It pins the maxpoll for all sources and also won't let the poll time climb or drop. I had to pull that part out so I wouldn't hammer outside servers while still using my local PPS source. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
mike cook michael.c...@sfr.fr wrote: Rob, Looks like a bug anterior to your version. I see the same issue with version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local clock or not, and whether or not there are other active server associations. One for Harlen if it has not already been flagged. Tue Jul 29 21:32:48 CEST 2014 remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 25 6410.0000.000 0.008 o127.127.22.1.PPS1. 0 l8 1610.0000.002 0.008 ... remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 300 64 200.0000.000 0.008 o127.127.22.1.PPS1. 0 l 11 16 3770.0000.004 0.008 remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 437 64 1000.0000.000 0.008 o127.127.22.1.PPS1. 0 l4 16 3770.0000.004 0.008 Ok, good that you see this as well! In the past I often had a LOCL clock because the supplier of a Linux system put that in as a default (we all know about that...), but in those days the reach for the LOCL clock was always 377 or I would have noticed. So this is something that crept in later, or is related to the PPS driver. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
A C agcarver+...@acarver.net wrote: On 2014-07-29 11:33, William Unruh wrote: On 2014-07-29, Rob nom...@example.com wrote: The reasoning is that once the time is locked to PPS, it should remain close enough for the local clock to be trusted as an absolute time source (this system is rarely rebooted). It should do that even if the external clocks disconnect. But I do not know if in your setup your system refuses to use the ATOM if the external clocks disconnect-- that would be stupid, but ATOM always stops when the prefer peers die even if there are other peers available but not marked prefer. I'm still running an older development version (4.2.7p270) that I modified to remove all the prefer code so that the selection algorithm continues to run normally without shutting down the ATOM driver as peers come and go. If all the peers die then ATOM will stop, too since there's no more selected clock. Yes this is where the problem is. The ATOM clock needs to have some way of determining that the PPS pulses are valid, and the kludge to use the existing prefer keyword to indicate a clock that is to be used for that is causing all the trouble. The designer probably believed that any clock that provides PPS would also output some serial stream with less accurate time and also status, and that this would then be marked prefer. When that clock is OK, the PPS is also OK. However, that is broken. Not only do you probably not want to mark that clock prefer (external references are often more accurate than the serial NMEA time, for example), but also you may have two or more ATOM PPS clocks, each with their own status, and there is no way to do that with this method. Also, you may have (I do have) a GPSDO that provides PPS and status info, but no time. So I know when the PPS is valid, but I don't have an NMEA or TSIP or whatever stream to feed to a reference clock driver. What would be required is a parameter for the ATOM clock where one can specify which clock to use as a valid indicator for that PPS, without marking that clock as prefer in the same go, and with the option to specify another indicator (e.g. an SHM segment or other IPC mechanism) where an external program can put valid/not valid information for the PPS pulses without the obligation to specify current time. Then I can configure the ATOM clock with that method and use my external monitoring program to control the PPS valid flag, without messing with external clocks and prefer. Of course I would still list some external servers to initially sync the clock to within a second, and handle the leap second issue. But when they are lost, there should be no reason for the PPS to become invalid at the same time. Modifying the code also gave me the opportunity to decouple the minpoll/maxpoll pinng that happens between the local refclocks and external servers[1] -- the suggested configurations for many refclocks have maxpolls that conflict to the operational etiquette for Internet servers plus it prevents the automatic scaling of the poll time to those servers. [1] ATOM's own documentation suggest maxpoll of 4 to 6 to keep the clock synced to PPS. But that pins everything else to the same value unless a minpoll is set on the other servers. However, once minpoll is set, the combination of the pinning by ATOM plus the forced required minpoll means the external servers never change polling period nor do they get the opportunity to start at the short 64s polling interval during initial daemon startup and then ramp to some comfortable value in the 1000 second range. You are right, that is another issue I encountered. In case you wonder how I lost all external clocks: FILTERING. Lately, I encounter lots of NTP filtering in the internet, making clocks that were previously reachable, suddenly unreachable. Often this filtering occurs only for 123-123 traffic. There really should be an option in ntpd to specify source port for outgoing NTP queries! I could work around the filters by using the NAT facilities in the Linux kernel to translate the source port to 12300. That should be possible inside ntpd, for clarity. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-29 14:46, Rob wrote: mike cook michael.c...@sfr.fr wrote: Rob, Looks like a bug anterior to your version. I see the same issue with version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local clock or not, and whether or not there are other active server associations. One for Harlen if it has not already been flagged. Tue Jul 29 21:32:48 CEST 2014 remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 25 6410.0000.000 0.008 o127.127.22.1.PPS1. 0 l8 1610.0000.002 0.008 ... remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 300 64 200.0000.000 0.008 o127.127.22.1.PPS1. 0 l 11 16 3770.0000.004 0.008 remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 5 l 437 64 1000.0000.000 0.008 o127.127.22.1.PPS1. 0 l4 16 3770.0000.004 0.008 Ok, good that you see this as well! In the past I often had a LOCL clock because the supplier of a Linux system put that in as a default (we all know about that...), but in those days the reach for the LOCL clock was always 377 or I would have noticed. So this is something that crept in later, or is related to the PPS driver. See http://www.eecis.udel.edu/~mills/ntp/html/prefer.html or equivalent for other releases. One of the issues is that you always need more candidates than falsetickers to form a majority clique (see http://www.eecis.udel.edu/~mills/ntp/html/select.html). As I discovered recently under similar circumstances, offline servers are considered falsetickers, and if you have insufficient other candidates, or fewer than 3, nothing gets selected. Is there any reason you could not specify a pool as backups to keep the numbers up? -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: As I discovered recently under similar circumstances, offline servers are considered falsetickers, and if you have insufficient other candidates, or fewer than 3, nothing gets selected. I don't think I'm seeing what you're seeing but I could be confused. I believe I mentioned the same thing last time around on this topic. ntpd --version;ntpq -pn ntpd 4.2.7p440@1.2483-o Tue Apr 22 11:51:47 UTC 2014 (6) remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l28 3770.000 -0.002 0.004 *127.127.1.0 .LOCL. 12 l 65800.0000.000 0.004 192.168.0.210 .GPS.1 u 22 32 3771.304 -0.080 0.028 or just using LOCL ... remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l58 3770.000 -0.005 0.008 *127.127.1.0 .LOCL. 12 l 608 2000.0000.000 0.008 naturally you need to let NTP discipline your clock and a cold start requires something to set it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On 2014-07-29 21:32, Paul wrote: On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: As I discovered recently under similar circumstances, offline servers are considered falsetickers, and if you have insufficient other candidates, or fewer than 3, nothing gets selected. I don't think I'm seeing what you're seeing but I could be confused. I believe I mentioned the same thing last time around on this topic. Default for minsane is 3, if that is where you are confused. Not seen this topic mentioned in the last year or more. ntpd --version;ntpq -pn ntpd 4.2.7p440@1.2483-o Tue Apr 22 11:51:47 UTC 2014 (6) remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l28 3770.000 -0.002 0.004 *127.127.1.0 .LOCL. 12 l 65800.0000.000 0.004 192.168.0.210 .GPS.1 u 22 32 3771.304 -0.080 0.028 or just using LOCL ... remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l58 3770.000 -0.005 0.008 *127.127.1.0 .LOCL. 12 l 608 2000.0000.000 0.008 naturally you need to let NTP discipline your clock and a cold start requires something to set it. These statuses show the same issue with local clock reach, implying if reach stays at zero, sync will be lost and PPS become a falseticker without anything to number seconds for too long. Read the thread about the OP's config and problems. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
