Add NTP-server/client implementation #1977
Conversation
Signed-off-by: DL6ER <[email protected]>
|
Note that the failed spellcheck will be fixed by #1962 |
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
1 similar comment
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Signed-off-by: DL6ER <[email protected]>
|
Conflicts have been resolved. |
Signed-off-by: DL6ER <[email protected]>
|
Planning to add actual clock setting capability, converting to draft |
…gned 64 bit and double computations as mandated by RFC 5905 (page 28) Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
…error during synchronization Signed-off-by: DL6ER <[email protected]>
|
Ready for review |
Signed-off-by: DL6ER <[email protected]>
NTP service is always offered given no other NTP server is running on the same host (and port 123 is already taken)
Absolutely, this is implemented in this PR as well 🙂
|
There was a problem hiding this comment.
I played with this PR and while trying to figure out why ntpdate is complaining here from a client, I noticed there are no logs of ntp queries in FTL.log. Maybe you should add some log_debug() that can help identifying issues.
chrko@ThinkPad-X230:~$ ntpdate -vdq 10.0.1.24
3 Jun 21:42:19 ntpdate[32031]: ntpdate [email protected] Wed Feb 16 17:13:02 UTC 2022 (1)
Looking for host 10.0.1.24 and service ntp
10.0.1.24 reversed to pi.hole
host found : pi.hole
transmit(10.0.1.24)
receive(10.0.1.24)
10.0.1.24: Server dropped: server has gone too long without sync
server 10.0.1.24, port 123
stratum 2, precision -20, leap 00, trust 000
refid [76.79.67.76], root delay 0.000000, root dispersion 0.000000
reference time: (no time)
originate timestamp: ea089b1b.87cc1871 Mon, Jun 3 2024 21:42:19.530
transmit timestamp: ea089b1b.847b2f76 Mon, Jun 3 2024 21:42:19.517
delay 0.02666, dispersion 0.00000, offset -0.001330
3 Jun 21:42:19 ntpdate[32031]: no server suitable for synchronization found
|
Where does the server part get its time from? Is it just using the hosts current time? I did not find a trace where FTL is querying a public NTP server. |
Signed-off-by: DL6ER <[email protected]>
|
When using Additionally with the |
|
Not exactly sure what you mean, let me try a few things here: -> no logging to -> everything that is logged to Mind that the shown PID differs from the usual FTL process as NTP workers fork to achieve parallelism and avoid blocking if multiple queries arrive at the same time. The reason that everything that is being logged is the server also explains why you haven't seen any RTC setting. When the client is run from within your FTL process (to automatically sync the clock in the background), everything will be logged to |
|
NB: I was now running three days without |
…ng the internal NTP synchronization method. This ensures FTL can import the real most recent 24 hours data of history after a restart on a system lacking a real hardware clock Signed-off-by: DL6ER <[email protected]>
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Signed-off-by: DL6ER <[email protected]>
|
Conflicts have been resolved. |
Ok, this explains my questions about the logging. |
There was a problem hiding this comment.
nanopi@nanopi:~$ pihole-FTL ntp --update
....
Gradually adjusting system time by -135 us
Error NTP client: Failed to adjust time during NTP sync: Insufficient permissions
add_message(type=13, message=Failed to adjust time during NTP sync: Insufficient permissions) - SQL error step DELETE: attempt to write a readonly database
Error while trying to close database: database is locked
log_ntp_message(): Failed to add message to database
We should check for sufficient permissions early and fail gracefully.
|
Regarding your last commit: should we change the startup order to check first for the correct time and then import the queries - this could maybe avoid a restart if the time was off to far. |
Signed-off-by: DL6ER <[email protected]>
…d to the mean with a value of 0.0ms deviation, i.e., reducing any existing real time difference Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
…chronization Signed-off-by: DL6ER <[email protected]>
Ah, you mean concerning the database, yes. The most recent commits made this:
The idea proposed here is to start the resolver and import queries only once the first NTP synchronization finished. NTP synchronization can take everything between 4 seconds (minimum when everything works) to 40 seconds (when all eight attempts time out after five seconds each). I implemented this now. Before NTP synchronization finished, the web interface will look like The reason is that all the main graphs aren't updated very often. We need to make a change to the web interface to force reloading the large graphs if the total queries number jumps significantly. My suggestions would be a jump of a factor 2 but at least 100 in absolute numbers. To avoid reloading often once we go from 2 to 4 to 8, ... queries. |
Signed-off-by: DL6ER <[email protected]>
My idea was more about Can you add the detail log of what queries are imported after the import again? Currently it is not much of a use to see details of zero imported queries and no details after the import. |
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
…m disk Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
What does this implement/fix?
Pi-hole's FTL features a full-blown DHCP server that may be used in cases where changing the DNS server of router's internal DHCP servers isn't possible or where greater flexibility is required. The DHCP server is primarily responsible for assigning IP addresses to devices on a network. It can also provide additional configuration information to these devices, such as the addresses of NTP (Network Time Protocol) servers.
NTP is used to synchronize the clocks of computers over a network. Accurate timekeeping is crucial for most modern features.
Why should FTL also offer NTP service:
Simplicity: By providing both DHCP and NTP services, FTL can handle both IP address allocation and time synchronization. This resembles the functionality found in many routers that offer DHCP service.
Efficiency: When a device connects to the network, it can query the Pi-hole for time synchronization making this a very fast (sub-millisecond) synchronization compared to each device individually using online services which are several milliseconds away.
Consistency: By providing NTP services, the DHCP server can ensure that all devices on the network are using the same time source. This can help to prevent inconsistencies. (even when this shouldn't be an issue, usually)
Related issue or feature (if applicable): N/A
Pull request in docs with documentation (if applicable): N/A
By submitting this pull request, I confirm the following:
git rebase)Checklist:
developmentalbranch.