NTP Servers

Multicast Server

we dont talk to strangers

except to our lan

and upstream

Localhost users could be allowed to interrogate the ntp server more closely.

ntpd may needs to be instructed to stay away from interfaces that are ports in bridges and aggregates.

And only use the ones we want

Multicast server

ntpd can operate as unicast server for any permitting restriction, an additional directive is used to produce autonomous multicasts sent out of the specified interface, with the source IPv6 address of that interface.

Although extra lines might be added to send from other interfaces, it is neater to decide on a primary source interface, specified here, and copy to others with smcroute

If autokey is configured, instead:

Client directives

Recently it has been possible to add mostly any ntp.conf file rule whilst ntpd is running. This is most useful to add client lines as these require a connection to the associated server to be live to work.

Using a script from NetworkManager dispatcher directory, or dhcp client, to prod ntpd when the interface is ready

ntpdc wants to open /dev/tty to get your password, but it can be tricked with expect.

  1. PASSWORD=$(grep ^8 /var/lib/ntp/ntp.keys | cut -f3)
  2. /usr/bin/expect -c $' spawn ntpdc -c "keyid 8" -c ":config multicastclient ff05:101%${IFACE}"; expect "MD5 Password:"; send "'${PASSWORD}'\r"; expect "done!" ' > /dev/null

Change multicastclient ff05:101%${IFACE} to a line like pool ntp.example for a unicast client

GPSD client

Example for option gsm card

Though it does not need a sim card in it for the gps receiver to work, ModemManager might not like that idea so it has to be activated manually.


Can try activating via gpsdctl add /dev/ttyHS1 or manually

  1. #!/bin/sh
  2. # date --utc "+AT_OGCLK=\"%g/%m/%d,%H:%M:%S\""
  3. if test "`cat /sys/class/tty/${1##/dev/}/hsotype`" = "GPS"
  4. then
  5. for N in /dev/ttyHS?
  6. do
  7. if test "$N" = "/dev/ttyHS?"
  8. then
  9. break
  10. fi
  11. if test "`cat /sys/class/tty/${N##/dev/}/hsotype`" = "GPS Control"
  12. then
  13. if test "$2" = "ACTIVATE"
  14. then
  15. /usr/sbin/chat -V -f /etc/gpsd/gps-up.chat -T `date --utc +"\"%g/%m/%d,%H:%M:%S\""` <$N >$N
  16. fi
  17. if test "$2" = "DEACTIVATE"
  18. then
  19. /usr/sbin/chat -V -f /etc/gpsd/gps-down.chat <$N >$N
  20. fi
  21. fi
  22. done
  23. fi


  2. TIMEOUT 10
  3. "" ATZ
  4. OK "AT_OGCLK=\T"
  5. OK "AT_OGPSP=7,1^m"
  6. OK "AT_OGPS=2^m"
  7. OK "AT_OGPSEVT=1^m"
  8. OK ""


  2. TIMEOUT 10
  3. "" ATZ
  4. OK "AT_OGPS=0^m"
  5. OK ""

Extra lines for ntp.conf


ptpd can be used to get more precision and interoperates with ntpd, where ntp can get time from the internet and serve it to sntp stations, and ptpd or ptp4l where supported, can serve to ptp downstreams.

It supports multicasting with raw ethernet and udp modes, and there is provision in windows 10 though that only takes udp for the time being.

Whilst still in beta the only configuration interface is with the registry and some items are barely documented, and discovered by loading ptpprov.dll into notepad, and search utf-16 spaced words!

ChosenMcastIfIpAddr selects the interface via an assigned IPv4 address.

HWTSEnabledIfIpAddr could be for the physical related interface if the mcast one is a virtual bridge.

Other recommendable registry adjustments include RealTimeIsUniversal to treat the system RTC better, and ShowSecondsInSystemClock to exhibit the system improved accuracy after PTP can work!

  3. CurrentControlSet
  4. Services
  5. W32Time
  6. TimeProviders
  7. PtpClient
  1. "PtpMasters"=""
  2. "Enabled"=dword:00000001
  3. "InputProvider"=dword:00000001
  4. "DllName"="%systemroot%\\system32\\ptpprov.dll"
  5. "DelayPollInterval"=dword:00003e80
  6. "AnnounceInterval"=dword:00000fa0
  7. "EnableMulticastRx"=dword:00000001
  8. "ChosenMcastIfIpAddr"=""
  9. "EnableTxMulticastOnly"=dword:00000001
  10. "HWTSEnabledIfIpAddr"=""
  11. "AllowAnyMaster"=dword:00000000
  12. "UseE2ECorrection"=dword:00000001

NtpClient and VMICTimeProvider could be disabled for testing purposes as microsoft suggest, so the system has to use PTP, and apply the powershell rules to open up the firewall for PTP-319 and PTP-320. In normal operation, it is useful to have both NTPClient and PTPClient active, so the system can try to fallback to NTP, if PTP does stop working, rather than just go adrift.

To troubleshoot, wireshark, and a batch.cmd can be used, invoked from an Administrator cmd even when the "user" account is logged in.

  1. pktmon filter remove
  2. pktmon filter add -v 40 -d IPv4 -t 2 -i
  3. pktmon filter list
  4. pktmon start --capture --log-mode real-time

With the tasklist, find the PID associated with the instance of svchost.exe that handles W32Time, and use that with sysinternals procmon64 to have a detailed examination of what is happening.

  1. net stop w32time
  2. del C:\Users\user\Documents\time.log
  3. del C:\Users\user\Documents\time.log_ptpprov
  4. w32tm /debug /enable /file:C:\users\user\documents\time.log /entries:0-300 /size:10000000
  5. net start w32time
  6. tasklist /svc | findstr W32Time

There other log to check is the event viewer, in compmgmt.msc where there is a Time-Service-PTP-Provider that provides 512 as a trying code, 514 for some failure, confirmation that everything is working with a 513 return code.

If the microsoft hybrid ptpd template is taken for master, probably causes are that the ptpd needs to set PTP_TIMESCALE and PTP_UTC_REASONABLE in flags for windows to accept it as a master, and needs to send announces more often than AnnounceInterval of 4 seconds, once a second seems to work.