ntp

WORK IN PROGRESS

The NIST leapsecond file

The file is available available at ftp://time.nist.gov/pub/ as well as ftp://tycho.usno.navy.mil/pub/ntp/

Difference between ntp and ptp

Hardware timestamping

Special Hardware (FPGA-Based)

Commodity Hardware

  • Intel 82580 -- The NIC I'm most familiar with that supports general hw timestamping is the Intel 82580 Gigabit Ethernet Controller. It can timestamp all RX packets in hardware, but only PTP TX packets.
  • Intel i340
  • Neterion X3110/X3120

The current Intel controllers supporting IEEE 1588 are the Intel® 82574, 82576, and 82580 Gigabit Ethernet Controllers, the Intel® 82599 10 Gigabit Ethernet Controller, and Intel® Ethernet Controller I350

My own NTP-Server

RaspberryNtpOptimization

Two other things that I have changed were the cpu_scaling and the serial latency:

  • echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  • setserial /dev/ttyAMA0 low_latency

It appears that the Ethernet latency on the Pi is fairly large, but it can be reduced at a slight cost in performance. To do this, edit your:

/boot/cmdline.txt and add:

smsc95xx.turbo_mode=0 (or smsc95xx.turbo_mode=N ??) along with all the other parameters that are being set.

This disables a feature of the Ethernet controller that tries to pack multiple received frames into a single USB transfer. In order to do this, the controller waits after receiving a frame (in the hope of receiving another frame) before passing any data back to the host. Setting turbo_mode to 0 reduced a ping RTT (Round Trip Time) from 500-600 µs down to 300-350 µs.

befor
root@raspberrypi:/boot# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_NMEA(0)     .GPS.            0 l    1   16  377    0.000  140.392  29.463
 PPS(0)          .PPS.            0 l    -   16  377    0.000   -1.375   0.049
*ntp1.ntp.servic .PPS.            1 u  510 1024  377    0.775   -2.563   1.636
+ntp1.bff.iv.bfi .PPS.            1 u  827 1024  377    8.559   -2.145   1.633
+ntp3.ntp.servic .PPS.            1 u  227 1024  377    1.449   -1.314   1.630
+ntp3.mgm.zivit. .GPS.            1 u  105 1024  377    7.959   -2.168   1.510
after
root@raspberrypi:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_NMEA(0)     .GPS.            0 l    3   16  377    0.000   94.814 106.070
 PPS(0)          .PPS.            0 l    3   16  377    0.000    0.085   0.004
*ntp1.ntp.servic .PPS.            1 u   19   64  377    0.708    0.110   0.026
-ntp1.bff.iv.bfi .PPS.            1 u   40   64  377    8.244    0.018   0.195
+ntp3.ntp.servic .PPS.            1 u   37   64  377    1.318    0.250   0.272
+ntp3.mgm.zivit. .GPS.            1 u   30   64  377    7.461    0.033   0.068
root@raspberrypi:/var/tmp# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_NMEA(0)     .GPS.            0 l    7   16  377    0.000  385.235  24.709
 PPS(0)          .PPS.            0 l    7   16  377    0.000    0.006   0.004
*ntp1.ntp.servic .PPS.            1 u   49  128  377    0.731    0.022   0.087
-ntp1.bff.iv.bfi .PPS.            1 u  108  128  377    8.208   -0.065   0.845
+ntp3.ntp.servic .PPS.            1 u   64  128  377    1.281    0.231   0.224
+ntp3.mgm.zivit. .GPS.            1 u  118  128  377    7.740    0.067   0.059
root@raspberrypi:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_NMEA(0)     .GPS.            0 l    3   16  377    0.000  219.705  68.095
 PPS(0)          .PPS.            0 l    3   16  377    0.000    0.220   0.019
*ntp1.ntp.servic .PPS.            1 u  414 1024  377    0.760    0.125   1.953
+ntp1.bff.iv.bfi .PPS.            1 u  467 1024  377    8.515   -0.458   2.012
+ntp3.ntp.servic .PPS.            1 u  393 1024  377    1.443   -0.105   1.482
+ntp3.mgm.zivit. .GPS.            1 u  247 1024  377    7.778   -0.257   1.565

WatchInterrupts

  • watch -n1 "cat /proc/interrupts"

MonitorNtpWithGnuplot

cat peerstats.201410 | awk 'function abs(x){return ((x < 0.0) ? -x : x)} {if ($6 < 0.2 && abs($5) < 0.04) print}' > peerstats.201410.2

plot "peerstats.201410.2" using 6:5 with dots

What does .RATE. mean?

# ntpq -p
     remote refid st t when poll reach delay offset jitter
==============================================================================
-ntp1.ntp.servic .RATE. 16 u 956 1024 212 0.534 -0.329 0.014
+ntp1.bff.iv.bfi .PPS. 1 u 587 1024 377 6.340 -0.235 0.016
*ntp3.ntp.servic .RATE. 16 u 696 1024 376 1.010 -0.243 0.073
+ntp3.mgm.zivit. .GPS. 1 u 148 1024 377 6.631 0.094 0.029

Sometimes the ntp-client asks too often the peer time server and answers with a "slow-down"-packet.

In this case you can try to disable iburst and set a maxpoll option or you can disable the limited and kod flags in the restrict command.

Meinberg ntp.conf

#  ***  lantime  ***
# NTP.CONF for GPS167 with UNI ERLANGEN (do not modify)

server  127.127.1.0                  # local clock
fudge   127.127.1.0 stratum 12       # local stratum

server  127.127.8.0 mode 135 prefer  # GPS167 UNI Erlangen with PPS
fudge   127.127.8.0 time1 0.004400     # calibration value
fudge   127.127.8.0 flag2 0  flag3 1
server  127.127.22.0  minpoll 6  maxpoll 6               # ATOM (PPS)
fudge   127.127.22.0 flag2 0  flag3 1
enable stats
statsdir /var/log/
statistics loopstats
driftfile /etc/ntp.drift
server  192.168.111.117 iburst
server  ptbtime1.ptb.de iburst
server  ptbtime2.ptb.de iburst
server  time.uni-konstanz.de iburst
server  134.34.3.19 iburst

The Kiss-of-Death Packet

Ordinarily, packets denied service are simply dropped with no further action except incrementing statistics counters. Sometimes a more proactive response is needed to cause the client to slow down. A special packet has been created for this purpose called the kiss-o'-death (KoD) packet. KoD packets have leap indicator 3, stratum 0 and the reference identifier set to a four-octet ASCII code. At present, only one code RATE is sent by the server if the limited and kod flags of the restrict command are present and either the guard time or MAH time are violated.

A client receiving a KoD packet is expected to slow down; however, no explicit mechanism is specified in the protocol to do this. In the reference implementation, the server sets the poll field of the KoD packet to the greater of (a) the server MAH and (b) client packet poll field. In response to the KoD packet, the client sets the peer poll interval to the maximum of (a) the client MAH and (b) the server packet poll field. This automatically increases the headway for following client packets.

In order to make sure the client notices the KoD packet, the server sets the receive and transmit timestamps to the transmit timestamp of the client packet. Thus, even if the client ignores all except the timestamps, it cannot do any useful time computations. KoD packets themselves are rate limited to no more than one packet per guard time, in order to defend against flood attacks. http://www.eecis.udel.edu/~mills/ntp/html/rate.html