[ntp:hackers] NTP Release Candidate 4.2.8p1-RC1 Released
juergen.perlinger at t-online.de
Thu Jan 29 19:05:41 UTC 2015
On 01/28/2015 11:25 PM, Gary E. Miller wrote:
> Yo All!
> On Mon, 26 Jan 2015 16:44:51 -0800
> "Gary E. Miller" <gem at rellim.com> wrote:
>> On Sun, 25 Jan 2015 02:30:12 +0000
>> NTP Public Services Project <webmaster at ntp.org> wrote:
>>> NTP Release Candidate 4.2.8p1-RC1 is now available for download.
>> I can not get the gpsdjson refclock to do anything.
> Hal Murray has suggested this is an ntpd bug. Any progress on this?
No, since nobody could give me a hint where that bug should actually be,
and I cannot reproduce it. Just to be sure, some details of my system:
gpsd: 3.11 (revision 3.11)
Linux 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15 22:27:29 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
> I looked at the GPSD_JSON code. Two issues jump out at me.
> 1. The use of EPT to guess time precision is totally bogus. It should
> be removed.
> Time error in TPV is totally dominated by local effects such as
> serial port rate, NMEA variable sentence length, interrupt latency,
The time error of TPV is irrelevant. There is no received-at time stamp
in TPV, and the TCP transmission delay makes the receive time stamp of
NTPD useless for anything but consistency checks between TPV and PPS
messages on the side of NTPD.
> Time error in PPS is totally dominated by port type (USB or direct serial)
> and by GPS model.
> I would suggest that precision be computed from observed jitter.
The EPT gives definitely the lower bound for the error. The PPS phase
jitter can be measured, but there's still no way to estimate or measure
a systematic delay -- it has to be fudged away. For sure, under normal
conditions the PPS jitter will dominate the EPT error. But when the EPT
goes beyond 10usec, it might dominate the jitter. (This clearly
indicates some trouble with the receiver, of course.)
Any suggestions how to combine them? arithmetic sum, geometric mean,
geometric sum, maximum, ...?
BTW, the SHM clock that is fed by GPSD with the PPS data says
'precision=-20'. Which amounts to 1usec. Does the GPSD SHM feed provide
a proper jitter evaluation for precision estimation? If yes, accept my
apologies. I might borrow ideas from your source code, though. Just
*ideas*, since NTP's copyright and GPL are mutually exclusive...
> 2. Flipping between TPV and PPS time is not a good idea.
> The precisions are wildly different, yet they will flip flop silently.
> It removes the ability for ntp.conf to prefer local PPS time but not
> prefer local TPV time.
> I would suggest that some way to separate TPV and PPS time is needed.
I disagree. Separating the PPS signal from the serial data is IMHO evil,
because they come from the same source and belong together. Also the
driver does *not* flip between the PPS and the TPV time stamps: It
combines the phase information obtained from the PPS pulse with the full
time stamp from the TPV data to get the absolute time stamp at the time
of the PPS signal. And that's exactly the reason why the driver refuses
to work if only TPV data is available: There is no time stamp for the
reception time, and there's additional delay between NTPD and GPSD, so
the receive time stamps of NTPD are useless for the time correction.
I might become convinced that operating on PPS alone could be useful,
but any GPS device that can provide a PPS signal can surely provide a
time stamp for TPV, can't it?
Splitting TPV and PPS into separate channels as it is done with the SHM
clock units makes it impossible for NTPD to correlate those two, and
poor serial timing can lead to a situation were both clocks are marked
as false tickers because they disagree too much to be useful. (Having
enough other good time sources will likely throw out just the serial
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
> gem at rellim.com Tel:+1(541)382-8588
> hackers mailing list
> hackers at lists.ntp.org
More information about the hackers