====== ntp ======
DO NOT EDIT - THIS FILE IS FOR HISTORIC REVIEW
* [[sysadmin:enterprisetimeserver|EnterpriseTimeServer]]
* [[sysadmin:easydistributeandbalancewithpool|EasyDistributeAndBalanceWithPool]]
===== Difference between ntp and ptp =====
* https://www.eecis.udel.edu/~mills/ptp.html
* http://www.fsmlabs.com/news/2012/06/28/choosing-between-ptp-and-ntp.html
* http://www.ntop.org/pf_ring/who-really-needs-sub-microsecond-packet-timestamps/
* http://vyodaiken.com/tag/timekeeper/
* http://www.thetradingmesh.com/pg/blog/mike/read/38896/beyond-latency-utilizing-ultra-accurate-network-timing-in-hft-systems
===== Hardware timestamping =====
Special Hardware (FPGA-Based)
* Silicom -- 10 Gigabit Time Stamping Adapters/Capturing http://www.silicom-usa.com/10_Gigabit_Time_Stamp_Server_Adapter
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
===== CalibrateYourOwnStratum1 =====
* http://lists.ntp.org/pipermail/questions/2013-September/036165.html
* https://lists.bufferbloat.net/pipermail/thumbgps-devel/2012-March/000109.html
===== [[sysadmin:raspberrygpsntpserver|RaspberryGpsNtpServer]] =====
* http://ntpi.openchaos.org/pps_pi/
* http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/
* http://mythopoeic.org/pi-ntp/
* http://satsignal.eu/ntp/Raspberry-Pi-NTP.html
* HAB Supplies
* http://ava.upuaut.net/store/index.php?route=product/product&path=59_60&product_id=95
* http://ava.upuaut.net/store/index.php?route=product/product&path=59_60&product_id=117
* http://ava.upuaut.net/?p=726
* http://ava.upuaut.net/?p=600
* Adafruit
* http://www.adafruit.com/products/2324
* https://learn.adafruit.com/adafruit-ultimate-gps-on-the-raspberry-pi/introduction
* selfmade
* http://www.ip-symcon.de/forum/threads/24960-Raspberry-Pi-GPS-amp-RTC-Time-Module
* RTC Modul. Der verwendete DS3231
* GlobalTop Technology Inc. Gmm-g3 GNSS Module
===== 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
* http://lists.gnu.org/archive/html/gpsd-dev/2013-10/msg00158.html
* http://www.ijs.si/time/
===== 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.
- 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