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 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 wrote: > Rob schrieb: >> A C 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 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 wrote: > On 2014-07-31, Martin Burnicki 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 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 wrote: > William Unruh wrote: >> On 2014-07-31, Martin Burnicki 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 wrote: > On 2014-07-31, Rob wrote: >> William Unruh wrote: >>> On 2014-07-31, Martin Burnicki 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 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 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 wrote: > William Unruh wrote: >> On 2014-07-31, Rob wrote: >>> William Unruh wrote: On 2014-07-31, Martin Burnicki 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 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 wrote: > William Unruh 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 wrote: > On 2014-07-31, Rob wrote: >> William Unruh 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), * a
Re: [ntp:questions] LOCL clock reachability not 377?
William Unruh 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 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 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
