Preferential use of local Stratum 1 NTP server?

[Andreas Warburton]

I have set up a local Stratum 1 NTP server on my LAN, with a GPS receiver chip and active microwave antenna attached. Would there be a way to configure my RPi pfclient v4.1.1 setup so that it preferentially includes my local NTP server when performing time corrections? I've noticed that planefinder makes fairly frequent queries to NTP servers such as x.planefinder.pool.ntp.org.

Also, in addition to feeding to planefinder, I also feed to 6 other organizations, some of which also need reliable system timing for MLAT processing. I believe that planefinder is not the only service that seeks to adjust system time by way of NTP server queries. Has anyone assessed the implications of having multiple feeders separately seeking to condition the same system clock?

Best,
Andreas

 

[Lee Armstrong]

Hello Andreas,

We prefer to keep this to the pool and not anything else. This way it cycles through in case any go bad/drift (including your local Stratum 1 server). Every 15 minutes for a small NTP request/response also I wouldn't say is frequent ;-)

Also we don't touch the system time in any way as yes agreed, there could be some impact there. I can't speak for what the other clients do but we keep ourselves very self contained.

Lee

 

[Andreas Warburton]

Fair enough, and very sensible! Thanks Lee.

 

[wiedehopf]

I also feed to 6 other organizations, some of which also need reliable system timing for MLAT processing

System time only is for approximately knowing when the messages come in maybe more important for ADS-B messages.

For multilateration you actually need a way better clock: The receivers are synchronized via ADS-B messages that reported a position, this is used as common ground to compare the timing of non-ADS-B messages by their receiver-timestamp. (The DVB-T stick / rtl-sdr USB stick has a very precise crystal built in to be able to receive the relevant frequencies)
Also the transfer over USB can take shorter or longer, another reason why the timestamps need to be generated in the receiver.

Anyway on your other point: There is a competitor using the public ntp pools, which is against their guidelines for use. Especially for them and because no "serious" software uses the regional pools anyway i have made these entries in my /etc/hosts file, if you don't have your NTP server on localhost, you obviously can define another IP.

Don't use this for the planefinder NTP pool!

Please do not set a hostname replacement for the plane finder pool entries!

We will be detecting this in the future within the client and stopping access as we cannot guarantee the integrity of them

127.0.0.1       1.oceania.pool.ntp.org
127.0.0.1       1.africa.pool.ntp.org
127.0.0.1       1.north-america.pool.ntp.org
127.0.0.1       1.south-america.pool.ntp.org
127.0.0.1       1.asia.pool.ntp.org
127.0.0.1       1.europe.pool.ntp.org

 

[Andreas Warburton]

Thanks for the tips. I tried your modification in /etc/hosts (yes, pointing to my NTP server at a different LAN IP address), but this rendered the systemd-timesyncd.service dysfunctional. It failed to sync, with "timed out waiting for reply" errors when trying to contact the local NTP server.

In case it's important, I am using Raspbian Stretch, which by default does not use ntpd but rather the timesyncd service under systemd.

Best,
Andreas

 

[wiedehopf]

Thanks for the tips. I tried your modification in /etc/hosts (yes, pointing to my NTP server at a different LAN IP address), but this rendered the systemd-timesyncd.service dysfunctional. It failed to sync, with "timed out waiting for reply" errors when trying to contact the local NTP server.

The target IP is on the left and the hostname you want to redirect is on the right.
My guess: you redirected the other way around?
Or your NTP server doesn't work?

 

[Andreas Warburton]

Instead of the 127.0.0.1 on the left, I used the LAN IP address of my NTP server, running on a different rpi. Other than the different IP, I added the same 6 lines on the right, as you have in your post, to the end of my /etc/hosts file. I've tested that my NTP server works by specifying it in /etc/systemd/timesyncd.conf and monitoring that it is being accessed correctly (using "timedatectl status" and "systemctl status systemd-timesyncd.service"). I've also set it as the first server for my Mac laptop, and monitored the accesses using my network's pihole interface. Finally, I've also tested it using the "Emerald Time" app on my iOS device.

 

[wiedehopf]

Normally /etc/systemd/timesyncd.conf doesn't even have those pools in them, so it wouldn't use them.
The default are the debian time pools.

So i really have no clue why it is not working.
You can just use ping to test the effect of the entries of the host file.
After you put it into the host file can you try pinging your NTP server like so:
ping 1.2.3.4

You could also post the finished hosts file that is not working, apart from that i'm all out of ideas.

 

[Andreas Warburton]

Normally /etc/systemd/timesyncd.conf doesn't even have those pools in them, so it wouldn't use them.
The default are the debian time pools.

So i really have no clue why it is not working.
You can just use ping to test the effect of the entries of the host file.
After you put it into the host file can you try pinging your NTP server like so:
ping 1.2.3.4

You could also post the finished hosts file that is not working, apart from that i'm all out of ideas.

My understanding is that the default Debian time pools are hard wired. I use /etc/systemd/timesyncd.conf to specify my local NTP server for maintenance of the system time. This is independent of my current goal of redirecting one of my feeders' NTP queries to the public pools.

After modifying my /etc/hosts file, ping still works as expected. I've pinged both my NTP host as well as the redirected public pool aliases, and they appear to redirect to the local NTP server as expected. One detail that I read, using "man 5 hosts", is that the aliases should "begin with an alphabetic character" and "end with an alphanumeric character". I note that the aliases for redirection in this case all begin with a number (1), so am wondering if that is the issue? In any case, I'm quite stumped. Here, for reference, are the contents of my edited /etc/hosts file:

127.0.0.1    localhost
::1        localhost ip6-localhost ip6-loopback
ff02::1        ip6-allnodes
ff02::2        ip6-allrouters

127.0.1.1    piaware

192.168.2.239    1.oceania.pool.ntp.org
192.168.2.239    1.africa.pool.ntp.org
192.168.2.239    1.north-america.pool.ntp.org
192.168.2.239    1.south-america.pool.ntp.org
192.168.2.239    1.asia.pool.ntp.org
192.168.2.239    1.europe.pool.ntp.org

Thanks a lot for your help!

 

[wiedehopf]

My understanding is that the default Debian time pools are hard wired. I use /etc/systemd/timesyncd.conf to specify my local NTP server for maintenance of the system time. This is independent of my current goal of redirecting one of my feeders' NTP queries to the public pools.

Oh i know what it could be

When you redirect all the pools your NTP server gets spammed by whatever24-feed, so it probably has some flood protection builtin
That could explain the timeout.
(It contacts all the pools at the same time first with a ping then the ntp stuff, so that is 7 NTP requests which sure could enable a spam protection.)

Just make it easy:
apt-get install ntp
Then you can configure it to use your NTP server.
From localhost it does not employ any rate limiting.
(You could also possibly whitelist the pi if you find what your NTP server is using for that flood protection)

Now it's not guaranteed that this is the problem but i can think of no other way how the hosts file could screw with your NTP server.
Because you can clearly still reach it.

 

[Lee Armstrong]

Please do not set a hostname replacement for the plane finder pool entries!

We will be detecting this in the future within the client and stopping access as we cannot guarantee the integrity of them

 

[wiedehopf]

Please do not set a hostname replacement for the plane finder pool entries!

Not my intention!
As i mentioned in my original post this wasn't aimed at planefinders pool, rather the regional pools being used against the pool policy by a competitor.

I do fully understand the wish to use your own pool and even with the other feed service i would not have resorted to this tactic if they would have fixed their client, but it has not been updated in quite some time.

As this doesn't really relate to planefinder i can remove my posts if you would be more comfortable with that.
Probably shouldn't have brought it up, one person more or less is not going to make a difference even with the regional pools.
In the mean time i've quoted you in my original post and added a note not to use it for the planefinder pool.

 

[Andreas Warburton]

Just to be clear from my side, I too am not seeking to redirect the planefinder pool NTP calls, which appear to be implemented in a reasonable way. It's another feeder's calls to regional public pools that I have now suppressed by redirecting to my own stratum 1 NTP server. Other than the policy contravention to which wiedehopf refers, I find the high frequency of accesses by that feeder irritating due to the log file pollution that results. (On that subject, planefinder's very high rate of DNS queries is similarly frustrating due to the logging saturation, but that is a subject for a different thread -- and we have already been told that planefinder will be fixing this in future.)

Coming back to my implementation of wiedehopf's suggestion, I have now succeeded in getting it to work. The problem was in the configuration of my local NTP server, which had a "limited" flag set in its "restrict" settings in /etc/ntp.conf. With this flag set, the default number of clients is apparently only 3, with the relevant time period defaulting to 3600 seconds. More info here: http://doc.ntp.org/4.1.1/accopt.htm

It was wiedehopf's rate-limiting hypothesis regarding the NTP server side that led me to figure out the underlying problem. Thanks for that!

Cheers,
Andreas

 

[Andreas Warburton]

Just a follow-up on this thread: the changelog for a recent version update of fr24feed appears to address the problem I was having. See here:

# fr24feed changelog
All notable changes to Flightradar24 feeder software will be documented in this file.

The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/).

# [1.0.24-2] - 2019-10-01
## Changed
- Raspberry Pi debian package auto update now scheduled at random time on each receiver.

# [1.0.24-1] - 2019-10-01
## Fixed
- Kinetic receiver support (SBS1,2,3 working again)
## Changed
- Updated NTP synchronisation, custom server now possible with --ntp-server=
- Decoder now uses c-ares for DNS, replaces system ping command for static build

# [1.0.23-8] - 2018-10-11
## Changed
- Larger and configurable timeout for HTTP/HTTPS requests

 

[wiedehopf]

I've tested and it does less NTP queries now as well.
This works fine for me in /etc/fr24feed.ini:

ntp-server="127.0.0.1"

No more NTP queries to the internet on startup, rather using the NTP server that's running locally anyway.