0

Ehilà everybody!

I've this problem:

I'm serving ntp (On my Laptop for now ) with GPSD, using an old GPS-Sirf/NMEA module of the company I work for.

Let's forget about Ntpd.. as soon as I start gpsd, although date and time are correct in gpsmon, if I run an ntpshmmon I have a negative time ( about -69 years in seconds ) in the column tagged as "Real" which I assume to be the clock information of my SHM ( While de column "Clock" is actually the received information )

If I change module and use an U-blox everything it's ok and the SHM clock return to be +46 years. Is there a way to manage the GPS exchange of information with NTP? Or to configure GPS without knowing exactly what GPS module is?

Sorry if my question is some kind of airy-fairy... I hope somebody have had my same problem and can detect the clue...

Thx! :)

FL

Francesco Zanel
  • 23
  • 1
  • 4

1 Answers1

1

The first rule is: Don't Panic.

Try inserting tinker panic 0 into your /etc/ntp.conf

ntpd's reaction depends on the difference between the system clock and the reference time.

For a tiny offset ntpd will adjust the local clock as usual; for small and larger offsets, ntpd will reject the reference time for a while. In the latter case the operation system's clock will continue with the last corrections effective while the new reference time is being rejected. After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew). Huge offsets are rejected, and ntpd will terminate itself, believing something very strange must have happened. (Citation)

Setting panic to zero keeps ntpd from strange thoughts presented by large offsets.

We use one that looks like

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

tinker panic 0

# Specify one or more NTP servers.
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.420 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid GPS1

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

# Use Ubuntu's ntp server as a fallback.
server ntp.ubuntu.com

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient
Nodak
  • 929
  • 1
  • 8
  • 14
  • Thanks for your answer! The Tinker panic is very useful!! But for now I've still the problem... I noticed that the synchronization works properly with old release of GPSD ( 2.37 ) and have this bug with the newest.. – Francesco Zanel Apr 04 '16 at 14:15
  • I see now. Sorry, I thought it was just the range that was the problem. Looking at the time differentials it looks like the Epoch time is fubar (+46 years from 1/1/1970, and total 32 bit time ~ 69 years), or isn't getting picked up. The folks who wrote the application might want to know... https://lists.nongnu.org/mailman/listinfo/gpsd-users Good luck. – Nodak Apr 06 '16 at 04:36