[ntp:questions] Help: fudge time2 value for NMEA driver

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Mon Oct 31 20:03:08 UTC 2016


On 2016-10-30 11:29, ogre up wrote:
> Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have
> strange offset value reported by ntpq -p.
>
> Some basic infomation about my setup:
> OS: CentOS 6.5 + 2.6.34.10 kernel (compiled with pps support)
> NTP: 4.2.8 at p8 (with NEMA and ATOM clock driver enabled)
> Time ref: Garmin gps 18 (outputs GPRMC + GPGGA @ 4800bps)
> signal of pps and NMEA data from gps module capture by an osc looks like
> this:
> [see osc.jpg in attachments]
>
> /etc/ntp.conf:
> # use GPRMC sentence only
> server 127.127.20.0 mode 1 minpoll 3 maxpoll 4 iburst prefer
> fudge  127.127.20.0 fudge flag1 0 time2 0.213
> server 127.127.22.0
> fudge  127.127.22.0 fudge flag2 1 flag3 1
> tos mindist 0.10 # required, or both peer will be falseticker
>
> "time2 0.216" calculated as follows:
> pps pulse width is set to 100ms, so the leading edge marks the valid
> second.
> GPRMC (69 bytes) came before GPGGA (80 bytes) in NMEA data burst, so time
> span from pps to end of GPRMC = 380 - (1/4800 * 10 * 1000 * 80) = 213 ms.
>
> However, output of ntpq -pn shows 127.127.20.0 still got a large offset
> value:
>      remote           refid      st t when poll reach   delay   offsetjitter
> ==============================================================================
> *127.127.20.0    .GPS.            0 l    1    8  377    0.000  -115.021.120
> o127.127.22.0    .PPS.            0 l   56   64  377    0.000    0.0400.020

> Are these normal? Should I use "fudge flag 2" for 127.20.22.0?
>
> Sorry for my English and any suggestion will be appreciated.

Presuming a Garmin 18LVC wired to power and a serial port as you have PPS,
you get better results using the built-in NMEA PPS support as follows:

symlink /dev/pps0 as /dev/gpspps0, possibly using udev if used by CentOS,
set NMEA flag1 1 flag3 1, and drop PPS driver .22.0; add a startup script
to send Garmin startup commands to:

- output only $GPRMC as others slow down the Garmin and prevent proper
   PPS handling in the NMEA driver;

- reduce PPS length to minimum (20ms?);

- set speed to 9600bps, to reduce I/O and offset time;

set corresponding mode 17, and set time2 to 0.500 - as long as it is large
enough to account for the Garmin message output delay 400ms+ NMEA will use
the PPS timestamp instead of the end of line character time.

If you want to set an accurate time2, start with it at 0, run it for a day,
average the peerstats offset, try that value, and see if it helps or not.

Consistency can be improved by setting your system to always run at its
maximum standard clock speed without any boosts or power saving features
in a start up script; start ntpd with high realtime CPU and I/O priorities;
and pin ntpd to your highest numbered processor, in the ntp startup script
e.g. set max value from:
	/sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_available_frequencies
in both:
	/sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_min_freq
	/sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_max_freq
and the appropriate entry from:
	/sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_available_governors
normally performance into:
	/sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_governor
set ntpd priorities and affinity:
	start-stop-daemon --procsched rr:20 --iosched real-time:4 ...
	taskset -apc $CPU $PID

It also helps to speed up acquisition and timing output if you can preload
your position estimate, and latest almanac, ephemeris, or Extended
Prediction Orbit data downloads to the Garmin in your GPS setup startup
script, although there is some support for some modules via interactive
Garmin Windows programs, info on this is sparse, although widely supported
and documented for all other commercial, and even many cheap Asian modules.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


More information about the questions mailing list