[ntp:questions] Start of new GPS 1024 week epoch

Rob nomail at example.com
Mon Aug 26 16:16:46 UTC 2013


Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> Rob wrote:
>> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>>> Rob wrote:
>>>> Aha, ok...   that is a solution, but I think it is a good idea to draw
>>>> a new SHM specification that adds a lot of functionality like described
>>>> in the mailing list article, and make it the prime reference clock interface
>>>> for ntpd.   ntpd can then focus on the main task: the network support and
>>>> the sacred loop, while those pesky drivers can be kept separate.
>>>
>>> I absolutely agree, and, as requested by Harlan, I've just opened a
>>> bugzilla issue for this, so this can be tracked more easily:
>>> http://bugs.ntp.org/2470
>>
>> Nice.  Maybe a separate bug could be opened (if there isn't already one)
>> suggesting the use of such a better SHM interface as a mechanism to
>> separate the other drivers from ntpd.
>
> I don't think there is a need to remove other existing drivers from 
> ntpd. If you don't want or don't need the built-in drivers you just 
> don't have to use them, and you can even compile ntpd without them, and 
> use the SHM interface exclusively.

I got the impression that David Mills' opinion is that the program has
grown too large and that the 40 drivers are an unfortunate contribution
to that size.  So I thought it would be a good plan to remove those
drivers and shrink down ntpd.

> There are other drivers beside the ones handling NMEA sentences from a 
> variety of GPS receivers, which work perfectly for their applications. 
> If you use a built-in driver then the advantage is that ntpd can just 
> get the time from the refclock. There's no need for another daemon or 
> service to be running in parallel to provide ntpd's SHM interface with 
> timestamps from the refclock.

Of course, but when the mechanism to start those daemons is well
streamlined (they may be started from ntpd while it parses the config
and sees they are needed), you can slim down ntpd without disadvantage.
Modern systems are designed to handle hundreds of processes without
problem.

Of course, there is also an advantage to not changing anything that
is working well.

>> I agree with all that, but I think it is better to do the communication
>> between the timing source and ntpd with only information that the timing
>> source has available (in the case of a PPS driver: the offset between
>> the PPS pulses and the nearest second tick in the system), and not be
>> forced to add information that the source cannot provide.
>> ntpd is in a better position to evaluate the provided offset from the
>> PPS and the absolute time in other sources (like the serial datastream
>> but also the information from network servers) and find the best
>> calculated offset.
>> Now gpsd has to do that with limited information and risk of mistakes.
>> (gpsd does not get information about other sources from ntpd, but only
>> looks at the serial datastream and the system clock)
>
> Hm. There must be some place on either side of the SHM segment where the 
> PPS timestamp is related to the reference time.
>
> So this could be done by ntpd or by the program that feeds the SHM 
> segment. In simple cases it is more straightforward to do this in ntpd, 
> since there's only a single routine required.
>
> On the other hand, if a program like gpsd tries to take care of 
> peculiarities of different types of GPS receivers it might be better to 
> let gpsd handled this and just forward "normalized" time stamps to ntpd.

When I added time support to gpsd, I decided to use two SHM segments.
The first presents the time received from the GPS receiver's serial
connection.  The second presents the time derived from the PPS pulses
(if any).  I saw that some existing drivers in ntpd managed to combine
those two functions in a single driver line, but I could not see a way
to do that via SHM without having to code "decision" logic in gpsd on
what source of time is best.  And I think only ntpd should make such
decisions.

It is now left to ntpd to do with the serial time data what it wants
(it usually has such a large offset that it is considered an outlier
by ntpd, but when there is no internet connection it may be the only
source of absolute time), and to use the PPS time to finetune the
system clock.  As gpsd does not know the true offset of the serial time
relative to UTC, I hardcoded some maximal offset between serial time
and system time.  When the offset is below that value, the PPS time
is presented as "valid" and with the absolute seconds derived from the
serial time.  I think this is required to avoid the case where the
system clock locks one second early or late, e.g. when the offset
of serial time is much larger than half a second.  And that has happened.

It would be better when decisions like that would be entirely left to
ntpd, because ntpd may have other sources of time and may see that
the serial time offset is too large but a couple of internet time sources
are OK.  gpsd does not know about that.  However, in a case like that
the PPS time will not be enabled and will not be available to ntpd.



More information about the questions mailing list