VyOS's NTP options currently configure Chrony using the default polling intervals and options.

For one of my uses, I'd really like VyOS's clock to be synced to within ~1 RTT of local hosts. This is actually not that hard with Chrony and GNSS-backed clocks, but it needs Chrony config options that VyOS can't currently generate. Specifically minpoll and maxpoll.

See my research from last year on Chrony accuracy with various polling intervals. With hardware timestamps, a good NIC, and minpoll=1 maxpoll=1 Chrony on my hardware could consistently get within 100 ns of real time, vs 10s or 100s of microseconds with the default settings, depending on the NIC used.

This is useful any time you need to compare logs between devices to determine cause and effect. For my specific case, I'm running a HTTP reverse proxy in a container and exporting OTel traces, so I can trace HTTP requests from when the requests first enter my network. The problem is that VyOS's default Chrony settings leave enough inaccuracy in the clock that traces will appear in the wrong order, with the VyOS trace either starting after the backend(s) have finished or completing before the backends have started. It's not *terrible*, but fixing it only requires 2 small config changes and burns a tiny amount of extra CPU and network bandwidth.

I want to add 4 additional options to service ntp server ...:

• minpoll N. Configure NTP to poll a minimum of every 2^N seconds. Chrony defaults to N=6, os 2^6=64 seconds. Valid values are -7 through 24.
• maxpoll N. Same as minpoll.
• presend N. If it's been more than 2^N seconds since the last poll of this server, then pre-send an extra NTP probe to warm ARP caches, etc, to reduce jitter.
• extfield-f323. Adds the extfield F323 option, which tells Chrony to use an extension field that. gives it a few additional bits of accuracy under some situations.

None of these should be on by default, but they're all useful in some situations. They're all pretty minimal changes to the config and code.