[chrony-users] Time synchronisation over a high-latency packet radio network

[Stuart Longland <stuartl@xxxxxxxxxxxxxxxxxx>]

Hi all,

I've got a problem where I need to provide a time synchronisation
service for small embedded computers whose only link to the outside
world is a slow and high-latency packet radio network.

In the locations where these are utilised:
- there is no cellular mobile coverage
- the devices are deployed deep within state forest with poor line-of-sight
- obviously distances are too great for Ethernet links

The embedded computers, PocketBeagles, do not feature a powered
real-time clock, and so when they boot up, they think the year is 2016.
 The devices are equipped with a MAX3232 dual RS-232 transceiver, with
one port being connected to a AX.25 terminal node controller and the
other to a RFID reader.

The terminal node controller then links to the data port of an amateur
radio transceiver, transmitting between 30-50W of RF on the 144-148MHz
or 430-450MHz radio bands.  The data link has a raw speed of 1200 bits
per second.

I am using `chrony` as it is one of the few NTP client packages that
will allow you to use an alternate port number for the destination server.

I have written a Python script in `asyncio` that binds to port 3123 (so
it can run as an unprivileged user), and on receipt of a NTP message,
takes the 48-byte NTP message, base64-encodes it and transmits that as
an APRS message over the AX.25 packet radio network.  Software at base
intercepts that, opens a new port, decodes the base64 and relays it to
the NTP server… and on receipt of a reply to that port, will base64
encode the response and send that back as an APRS message.

Via this arrangement, I am reliably able to "tunnel" the UDP requests
through the AX.25 network, and so aside from the fact that latency is
measured in seconds and the possibility of packet loss from doubling
(two stations talking at the same time) or other interference, it seems
to work quite well, *if* the time is set vaguely correct on the client
in the first place.

If the time was not pre-set, then `chronyd` would sit there for hours
polling the NTP server… with the poll period starting out at 8 seconds
and eventually expanding to 1024 seconds with seemingly no resolution.

I worked around the problem by hacking up
https://github.com/lettier/ntpclient/ to call `date` with the received
time and running that from `cron`… *then* `chronyd` would wake up and
fine-tune the time, dialling it right in to correct time.

`chronyd` worked beautiful then.  If the clock is years off though,
`chronyd` seems reluctant to do anything about it, assuming that the one
NTP server it can reach is at fault.

Below is my chronyd.conf:
----- BEGIN chronyd.conf -----
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
pool 2.debian.pool.ntp.org iburst

# NTP proxy over APRS
server 127.0.0.1 port 3123 trust maxdelay 10 minpoll 3

# This directive specify the location of the file containing ID/key
pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Uncomment the following line to turn logging on.
log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
#maxupdateskew 100.0

# This directive tells 'chronyd' to parse the 'adjtime' file to find out
if the
# real-time clock keeps local time or UTC. It overrides the 'rtconutc'
directive.
hwclockfile /etc/adjtime

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile'
directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is
larger than
# one second, but only in the first three clock updates.
makestep 1 -1
---- END chronyd.conf -----

and it appears `systemd` starts `chronyd` without arguments.

Are there any ideas people have to help make `chronyd` more trusting
about the time it receives and to set the clock sooner?

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.