Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • ntpsec ntpsec
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 58
    • Issues 58
    • List
    • Boards
    • Service Desk
    • Milestones
    • Requirements
  • Merge requests 23
    • Merge requests 23
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • NTPsecNTPsec
  • ntpsecntpsec
  • Issues
  • #57
Closed
Open
Created May 09, 2016 by Gary E. Miller@garyedmundsmiller💬Maintainer

Refclock GPSD_JSON, bad NMEA time

There is an undocumented GPSD_JSON (refclock #46 (closed)) mode that exposes the base data better than the documented mode.

The configuration is documented, sort of, in refclock_gpsdjson.c. Here is my config:

# gpsd JSON
server 127.127.46.0 minpoll 4 maxpoll 4
fudge 127.127.46.0 time1 0.142
server 127.127.46.128 minpoll 4 maxpoll 4
fudge 127.127.46.128  time1 0.001500

For comparison, I have the very same GPS using driver #28 (closed), configured this way:

# for gpsd
server 127.127.28.0 minpoll 4 maxpoll 4 noselect
fudge 127.127.28.0 time1 0.142  refid GPS

# for PPS and gpsd
server 127.127.28.1 minpoll 4 maxpoll 4
fudge 127.127.28.1 time1 0.001500 refid GPS1

Notice the identical fudges on both SHM and GPSD_JSON

ntpq -p should report (near) identical jitters and offsets, yet:

catbert:/usr/local/src/NTP/ntpsec# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-clepsydra.hpl.h .GPS.            1 u   22   64  377   26.265   -0.691   9.610
-204.152.184.72  .GPS.            1 u   61   64  377   28.276   -1.959  10.440
 nist.netservice .ACTS.           1 u  757 1024    0   59.583    0.894   0.000
-spidey.rellim.c .GPS1.           1 s   35   64  376    0.166   -0.495   0.078
 SHM(0)          .GPS.            0 l    3   16  377    0.000   10.279   2.409
+SHM(1)          .GPS1.           0 l    2   16  377    0.000    0.794   0.437
*SHM(2)          .SHM.            0 l   16   16  377    0.000   -0.461   0.046
xGPSD_JSON(0)    .GPSD.           0 l   16   16  377    0.000  -131.43   2.225
+GPSD_JSON(128)  .GPSD.           0 l   14   16  377    0.000    0.700   0.461

It looks like the 140 milliSec time1 fudge is being ignored.

Nothing new here, the bug has existed since the dawn of GPSD_JSON, ad was previously reported to the NTPD project.

So, in short, the bug is that GPSD_JSON driver is using semi-random NMEA time to base PPS on. When the error exceeds 500 milliSec that could cause the PPS to be associated with the wrong second.

[Edited to use new driver nomenclature]

Edited Aug 17, 2017 by Eric S. Raymond
Assignee
Assign to
Time tracking