Problems with timesyncd / ntp on WSL2 / 22.04

[bimmerdriver]

I posted about this in Ask Ubuntu a few days ago, but there hasn't been any reply, so I thought I would try here.

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, resynchronizing
Apr 23 19:14:54 kaveri fr24feed[2512813]: [time][i]Synchronizing time via NTP
Apr 23 19:14:54 kaveri fr24feed[2512813]: [time][i]Time synchronized correctly, offset -0.070 seconds, drift +0.000 seconds/minute
Apr 23 19:14:56 kaveri fr24feed[2512813]: [feed][i]sent 7,0 AC
Apr 23 19:15:02 kaveri fr24feed[2512813]: [feed][i]sent 5,0 AC
Apr 23 19:15:07 kaveri fr24feed[2512813]: [feed][i]sent 6,0 AC
Apr 23 19:15:08 kaveri fr24feed[2512813]: [time][w]Time jumped forward by 1.47s, resynchronizing
Apr 23 19:15:09 kaveri fr24feed[2512813]: [time][i]Synchronizing time via NTP
Apr 23 19:15:09 kaveri fr24feed[2512813]: [time][i]Time synchronized correctly, offset -0.080 seconds, drift -0.000 seconds/minute
Apr 23 19:15:11 kaveri fr24feed[2512813]: [feed][i]sent 6,0 AC
Apr 23 19:15:16 kaveri fr24feed[2512813]: [feed][i]sent 5,0 AC
Apr 23 19:15:21 kaveri fr24feed[2512813]: [feed][i]sent 5,0 AC

At the time I copied the log, the offset was relatively small, but it varies and 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.org
FallbackNTP=ntp.ubuntu.com
RootDistanceMaxSec=5
PollIntervalMinSec=16
PollIntervalMaxSec=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-timesyncd

Notice: 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.org
server 162.159.200.1, stratum 3, offset -0.234421, delay 0.02872
server 103.144.177.88, stratum 2, offset -0.255933, delay 0.08658
server 173.183.146.26, stratum 2, offset -0.273642, delay 0.04372
server 198.50.174.203, stratum 2, offset -0.295076, delay 0.09995
23 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 understand there can be issues synchronizing the system time in virtual environments, but I'm hoping someone that knows about timesyncd and ntpd can help me sort this out.

[bimmerdriver]

Am I the only person having this problem?