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 127.127.28.0 prefer # this is for a non-pps reference fudge 127.127.28.0 time1 0.420 refid GPS server 127.127.28.1 # prefer if PPS is working fudge 127.127.28.1 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 220.127.116.11 2 u 28 64 7 34.027 -24.421 6.790 -jefferson.mattw 18.104.22.168 3 u 25 64 17 80.645 -30.243 8.527 +you.dontlike.us 22.214.171.124 3 u 24 64 17 13.073 -25.993 8.616 javanese.kjsl.c .STEP. 16 - - 512 0 0.000 0.000 0.000 +w1-wdc.ipv4.got 10.0.77.54 4 u 21 64 17 10.738 -28.668 8.759 -126.96.36.199 188.8.131.52 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