Problems with timesyncd / ntp on WSL2 / 22.04

I'm running Ubuntu 22.04 LTS on Windows 10 / WSL2. I'm using bash, not the desktop.

I'm using the computer to run an ADS-B receiver to upload aircraft positions to flightradar24 and flightaware. The flightradar24 software is having a conflict with timesyncd to maintain the system time.

Here is the log from flightradar24:

Apr 23 19:14:54 kaveri fr24feed[2512813]: [time][w]Time jumped forward by 1.51s, resynchronizingApr 23 19:14:54 kaveri fr24feed[2512813]: [time][i]Synchronizing time via NTPApr 23 19:14:54 kaveri fr24feed[2512813]: [time][i]Time synchronized correctly, offset -0.070 seconds, drift +0.000 seconds/minuteApr 23 19:14:56 kaveri fr24feed[2512813]: [feed][i]sent 7,0 ACApr 23 19:15:02 kaveri fr24feed[2512813]: [feed][i]sent 5,0 ACApr 23 19:15:07 kaveri fr24feed[2512813]: [feed][i]sent 6,0 ACApr 23 19:15:08 kaveri fr24feed[2512813]: [time][w]Time jumped forward by 1.47s, resynchronizingApr 23 19:15:09 kaveri fr24feed[2512813]: [time][i]Synchronizing time via NTPApr 23 19:15:09 kaveri fr24feed[2512813]: [time][i]Time synchronized correctly, offset -0.080 seconds, drift -0.000 seconds/minuteApr 23 19:15:11 kaveri fr24feed[2512813]: [feed][i]sent 6,0 ACApr 23 19:15:16 kaveri fr24feed[2512813]: [feed][i]sent 5,0 ACApr 23 19:15:21 kaveri fr24feed[2512813]: [feed][i]sent 5,0 AC

Currently, the offset is relatively small, but at times it can be 30-40 seconds. I'm also seeing the effects of this in the flightaware software, because it's reporting that the time is unstable. The flightradar24 software is known to have a broken implementation of ntp, possibly because it's trying to set the time centrally, rather than locally.

I've tried to fix this using timesyncd, but I haven't been successful, so I tried to install ntpd. That wasn't successful either.

Originally, timesyncd would not sync to ntp. I had to override the default configuration due to running Ubuntu on wsl2. (I found this override on the internet.)

user@kaveri:/etc/systemd/system/systemd-timesyncd.service.d$ cat override.conf[Unit]ConditionVirtualization=ConditionVirtualization=wsl

The above override enabled timesyncd to start properly and sync to ntp.

Here is the rest of the configuration for timesyncd:

user@kaveri:/etc/systemd$ cat timesyncd.conf[Time]NTP=pool.ntp.orgFallbackNTP=ntp.ubuntu.comRootDistanceMaxSec=5PollIntervalMinSec=16PollIntervalMaxSec=2048

I'm using pool.ntp.org temporarily for testing. I reduced PollIntervalMinSec to 16 so the time would be synchronized more frequently. The flightradar24 software recognizes the time difference and "corrects it" again.

Here is the status of timedatectl:

user@kaveri:/etc/systemd$ timedatectl               Local time: Tue 2024-04-23 21:10:14 PDT           Universal time: Wed 2024-04-24 04:10:14 UTC                 RTC time: Wed 2024-04-24 04:35:58                Time zone: America/Los_Angeles (PDT, -0700)System clock synchronized: yes              NTP service: active          RTC in local TZ: no

According to the output, it's syncing with ntp. (You can also see the RTC is running faster. It runs much faster.) If I repeat this command, I can see the time jumping backward and forward, apparently due to flightradar24 incorrectly setting the time and timesyncd correcting the time.

Here is the status of systemd-timesyncd:

user@kaveri:/etc/systemd$ systemctl status systemd-timesyncd● systemd-timesyncd.service - Network Time Synchronization     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)    Drop-In: /etc/systemd/system/systemd-timesyncd.service.d└─override.conf     Active: active (running) since Mon 2024-04-22 14:08:14 PDT; 1 day 7h ago       Docs: man:systemd-timesyncd.service(8)   Main PID: 2705070 (systemd-timesyn)     Status: "Initial synchronization to time server 162.159.200.123:123 (pool.ntp.org)."      Tasks: 2 (limit: 8887)     Memory: 1.3M     CGroup: /system.slice/systemd-timesyncd.service└─2705070 /lib/systemd/systemd-timesyncdNotice: journal has been rotated since unit was started, output may be incomplete.

Again, this seems to confirm that it's syncing with pool.ntp.org.

Here is the output of ntpdate -q:

user@kaveri:/etc/systemd$ sudo ntpdate -q pool.ntp.orgserver 162.159.200.1, stratum 3, offset -0.234421, delay 0.02872server 103.144.177.88, stratum 2, offset -0.255933, delay 0.08658server 173.183.146.26, stratum 2, offset -0.273642, delay 0.04372server 198.50.174.203, stratum 2, offset -0.295076, delay 0.0999523 Apr 21:12:35 ntpdate[3606934]: adjust time server 173.183.146.26 offset -0.273642 sec

If I understand correctly, the offset of the computer from pool.ntp.org is only ~0.27 seconds.

Here is timedatectl timesync-status:

user@host:/etc/systemd$ timedatectl timesync-status       Server: 162.159.200.123 (pool.ntp.org)Poll interval: 16s (min: 16s; max 34min 8s)         Leap: normal      Version: 4      Stratum: 3    Reference: A45085C    Precision: 1us (-25)Root distance: 17.432ms (max: 5s)       Offset: -8.477243s        Delay: 3.402ms       Jitter: 9.165ms Packet count: 19241    Frequency: +0.000ppm

It's reporting an offset of ~8.4 seconds. This is taken moments after restarting systemd-timesyncd and also after executing ntpdate pool.ntp.org.

Either I'm confused about something or timesyncd is reporting an inconsistent offset from ntpdate. I don't understand how this can be, since they are both using pool.ntp.org.

In order to try and get around this, I attempted to install ntp on the computer. I shut down the flightradar24 and flightaware services so they would not interfere with ntpd syncing the clock. As I said above, the RTC runs much faster than it should (no idea why), so before I started ntpd, I set the time using ntpdate pool.ntp.org and I set the RTC using hwclock -w. Then I immediately started ntpd. It ran for a while, then failed with a message ntpd frequency error -18564 PPM exceeds tolerance 500 PPM. Does this mean the RTC is not accurate enough for ntpd to work properly?

I'm hoping someone that knows about timesyncd and ntpd can help me sort this out.