[ntp:questions] ntpd + GPS + PPS + Linux (Ubuntu Lucid)
nomail at example.com
Wed Jun 8 11:28:14 UTC 2011
Stephan Skrodzki <skrodzki at stevekist.de> wrote:
> Am Dienstag, den 07.06.2011, 20:24 +0000 schrieb Rob:
>> >> gpsd plus ntpd does not require any PPS support in the kernel.
>> >> there is no specfic PPS support via SHM but the gpsd just provides a
>> >> pretty accurate clock to ntpd. When your system is not overloaded
>> >> (CPU loading always around or over 1.00) there should be no problem
>> >> with sync
>> > Overload is not the case. After what you wrote, I had a short look at
>> > the gpsd ntpshm code and saw, that the pps shm part also inserts the gps
>> > time from the gps, so: why do I need the gps part of the shm at all?
>> I think you mean "the pps part..."
> No, I meant the gps part... as I looked into the code of gpsd my vague
> understanding is, that it takes gettimeofday, when a pps arrives, but
> then does some magic with the gps serial input (in ntpshm.c). I do not
> really understand, why this is necessary, as I would also like to use
> this as a pps only solution, where I get a pps from an external source
> without any gps (and therefore no time from gps). But I will ask this on
> the gpsd mailing list.
Well, this is possible with the PPS drivers in ntpd, but not with the
SHM interface. There is no possibility in the SHM interface to send
only the "PPS moment" but not the absolute time associated with it.
The PPS drivers in ntpd itself can do this.
Of course when you have only PPS and no GPS receiver connected, you
don't use gpsd. And you will need external servers to give you the
absolute time to within a couple of hundred milliseconds, so the clock
is basically at the right time and is only pulled to the precise
time based on the PPS pulses.
When the time is too far off when you begin pulling with PPS, you may
pull it to the wrong second (+1 or -1) and you would see the problem
of jumping clock once ntpd discovers this.
More information about the questions