Getting time from gpsd

One concern with bufferbloat is that we would like to analyze the current performance of ntp’s filtering system for ‘getting good time’, and also be able to more directly compare the performance of the internet at the edge to other sampling boxes.

This concept we call ‘the cosmic background bufferbloat detector’

A way to do that is to integrate ntp and a set of monitoring tools with a non-network based timed source, such as gps.

We have got a setup where gpsd can be used to feed time data into a cerowrt box. We are not at the point where we can actually process that data, and we have an issue in that getting hyper-accurate time requires PPS support which so as we can tell, 100% of all gpses no longer provide… but we’re getting there. Regrettably the jitter we get without PPS support is kind of poor.

To configure gps as a time source…

# Get a supported gps

# Locate it near a window that can ‘see’ enough sats to get a lock

# install gpsd on a recent cerowrt

opkg update
opkg install gpsd
opkg install cgps # this is optional - you can use this to monitor gpsd on the router itself
opkg install kmod kmod-usb-serial-ftdi # note - some gpses use kmod-usb-serial-pl2303
# edit /etc/config/gps and enable listen_globally (and then you can use cgps from anywhere on the network, even over ipv6)

# Add it as a network time source to /etc/ntp.conf and enable stats collection

statsdir /tmp/ntpstats/

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

server prefer # this is for a non-pps reference
fudge time1 0.420 refid GPS
server # prefer if PPS is working
fudge refid GPS1

# Edit /etc/init.d/ntp and add the following lines near the top

mkdir -p /tmp/ntpstats
chown ntp.ntp /tmp/ntpstats

# Restart ntp, restart gpsd

/etc/init.d/ntpd restart
/etc/init.d/gpsd restart

There will be two ways to see if it is working. The first is to run cgps to see if you are getting time, and the second is to look at ntpq to see if ntp considers it valid. It will take many seconds before it will do so.

A valid connection will look something like this, where reach is non-zero.

ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
xSHM(0)          .GPS.            0 l    7   64  377    0.000  -9584.2 187.194
 SHM(1)          .GPS1.           0 l    -   64    0    0.000    0.000   0.000
 shipka.bufferbl .STEP.          16 -    -  512    0    0.000    0.000   0.000
*montblanc.arbor    2 u   28   64    7   34.027  -24.421   6.790
-jefferson.mattw    3 u   25   64   17   80.645  -30.243   8.527      3 u   24   64   17   13.073  -25.993   8.616
 javanese.kjsl.c .STEP.          16 -    -  512    0    0.000    0.000   0.000       4 u   21   64   17   10.738  -28.668   8.759
-   2 u   20   64   17   53.232  -33.752   8.709
 data0213-1-pt.t .STEP.          16 -    -  512    0    0.000    0.000   0.000

This setup logs data to /tmp/ntpstats which will need to be uploaded and cleaned out

To edit this page, submit a pull request to the Github repository.
RSS feed

Recent News & Articles

Mar 12, 2017 Wiki page
Make-Wifi-Fast Project
Mar 10, 2017 Wiki page
What Can I Do About Bufferbloat?
Feb 10, 2017 Wiki page
More about Bufferbloat
Dec 27, 2016 Wiki page
RRUL Chart Explanation

Find us elsewhere

Bufferbloat Mailing Lists
#bufferbloat on Twitter
Google+ group
Archived Bufferbloat pages from the Wayback Machine


Comcast Research Innovation Fund
Nlnet Foundation
Shuttleworth Foundation

Bufferbloat Related Projects

Congestion Control Blog
Lede Project (OpenWrt)
Flent Network Test Suite
The Cake shaper

Network Performance Related Resources

Jim Gettys' Blog - The chairman of the Fjord
Toke's Blog - Karlstad University's work on bloat
Voip Users Conference - Weekly Videoconference mostly about voip
Candelatech - A wifi testing company that "gets it".