Announcement

Collapse
No announcement yet.

Questions about flightradar24 NTP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Questions about flightradar24 NTP

    Since I set up the computer, I noticed messages in the fr24feed log about NTP that didn't make sense.

    For example:

    Code:
    Feb 22 12:16:13 kaveri fr24feed[133332]: [time][e]Time jumped backward by -37.38s, resynchronizing
    Feb 22 12:16:13 kaveri fr24feed[133332]: [time][i]Synchronizing time via NTP
    Feb 22 12:16:13 kaveri fr24feed[133332]: [time][e]Time synchronized, offset -0.005 seconds, drift +0.463 seconds/minute​
    ...
    Feb 22 12:16:22 kaveri fr24feed[133332]: [time][i]Synchronizing time via NTP
    Feb 22 12:16:22 kaveri fr24feed[133332]: [time][e]Time synchronized, offset -37.374 seconds, drift -0.007 seconds/minute​
    I was wondering why there are such large time jumps, so I looked into it.

    I found that by default, Ubuntu 22.04 installs without NTP enabled. Maybe this is due to WSL. I'm not sure.

    Since my router, pfsense, is an NTP server, I enabled Ubuntu to use it.

    I was surprised by the result, which is the following:

    Code:
    Mar 10 14:28:48 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:28:54 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:29:00 kaveri fr24feed[7811]: [feed][i]sent 3,0 AC
    Mar 10 14:29:05 kaveri fr24feed[7811]: [feed][i]sent 3,0 AC
    Mar 10 14:29:10 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:29:16 kaveri fr24feed[7811]: [feed][i]sent 3,0 AC
    Mar 10 14:29:15 kaveri fr24feed[7811]: [time][e]Time jumped backward by -2.49s, resynchronizing
    Mar 10 14:29:15 kaveri fr24feed[7811]: [time][i]Synchronizing time via NTP
    Mar 10 14:29:16 kaveri fr24feed[7811]: [time][i]Time synchronized correctly, offset -0.019 seconds, drift +0.000 seconds/minute
    Mar 10 14:29:18 kaveri fr24feed[7811]: [feed][i]sent 3,0 AC
    Mar 10 14:29:24 kaveri fr24feed[7811]: [feed][i]sent 3,0 AC
    Mar 10 14:29:29 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:29:35 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:29:40 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:29:45 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:29:45 kaveri fr24feed[7811]: [time][e]Time jumped backward by -2.49s, resynchronizing
    Mar 10 14:29:45 kaveri fr24feed[7811]: [time][i]Synchronizing time via NTP
    Mar 10 14:29:46 kaveri fr24feed[7811]: [time][i]Time synchronized correctly, offset -0.030 seconds, drift -0.000 seconds/minute
    Mar 10 14:29:48 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:29:53 kaveri fr24feed[7811]: [feed][i]sent 3,0 AC
    Mar 10 14:29:59 kaveri fr24feed[7811]: [feed][i]sent 3,0 AC
    Mar 10 14:30:04 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:30:09 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC
    Mar 10 14:30:15 kaveri fr24feed[7811]: [feed][i]sent 4,0 AC​
    Every 30 seconds, fr24feed notices that the time jumped backward by ~2.5 seconds and it "corrects" the time. Over and over...

    Apparently, the NTP server that fr24feed is using disagrees with my NTP server by 2.5 seconds. This is very strange.

    Here is the NTP pool that my router is using to provide NTP on my network:

    pfSense NTP.png

    You can see that there is even a stratum 1 server in the pool and there is practically no offset or jitter.

    Based on this, it appears that the flightradar24 NTP server is off by 2.5 seconds.

    I'm wondering if anyone else has noticed this.

    What's even more strange is that since my computer started having this NTP battle with flightradar24, it has stayed connected, although it's too early to tell if this is just temporary or it this might be related to it disconnecting every night and then reconnecting the next day.

    The same computer has been feeding to flightaware continuously, including MLAT, for 6 days straight. The only problem is that there are occasional messages in the log about the time being unstable, which isn't surprising.

  • #2
    Thinking about this further, I would not be in the least bit surprised if the synchronization error is caused by latency between the flightradar24 server and fr24feed on the client. If that's the case, then their implementation of "NTP" is completely broken. The only proper implementation is for every client to synchronize directly with an NTP pool.

    Would someone with a factory image please check to see if NTP is being used to synchronize the time? If so, please provide details on the NTP pool.

    Comment


    • #3
      It uses pool.ntp. as with many years of complaints about it.

      Posts not to be taken as official support representation - Just a helpful uploader who tinkers

      Comment


      • #4
        Originally posted by Oblivian View Post
        It uses pool.ntp. as with many years of complaints about it.

        https://www.google.com/search?q=foru...obile&ie=UTF-8
        Thank you for your reply. I looked at some of those links. Now it makes more sense why the time is so messed up.

        Comment


        • #5
          Code:
          $ strings /usr/bin/fr24feed | grep ntp | grep -v ntptr
          [B]{:d}.pool.ntp.org[/B]
          ntp-server
          ntp_queries
          ntpclient.cpp
          _ZNK9libcommon9NTPClient23get_ntp_queries_counterEv​
          There still appears to be a reference to the global ntp pool in the fr24feed binary, which is disconcerting, since it was pointed out years ago that this is a highly disapproved practice.

          I see also the string ntp-server, which I tried to use by inserting the address of my router (which is also an ntp server) in the statement ntp-server="ip address" in /etc/fr24feed.ini. It didn't synchronize after several attempts, which is strange, because the same address is working fine for timesyncd.

          BTW, since I enabled timesyncd to use ntp, fr24feed has stayed connected to the server continuously (almost 60 hours).

          What is best practice for ntp with fr24feed?

          Comment


          • #6
            If you're looking for an "official" answer I'd suggest going to to https://www.flightradar24.com/contact-us and choosing the Data sharer / Feeding data / Other options...

            Comment

            Working...
            X