[External Email] Re: Question about internal 'private' servers

[ntpsec at anastrophe.com]

On 7/22/2024 10:08 AM, Dave Hall via users wrote:
> On my secondaries, I have:
>
>     driftfile /var/lib/ntpsec/ntp.drift
>     leapfile /usr/share/zoneinfo/leap-seconds.list
>     statistics loopstats peerstats clockstats
>     filegen loopstats file loopstats type day enable
>     filegen peerstats file peerstats type day enable
>     filegen clockstats file clockstats type day enable
>     tos maxclock 11
>     tos minclock 4 minsane 3
>     pool ntp-core.cs.binghamton.edu <http://ntp-core.cs.binghamton.edu>
>     iburst
>
>     server primary1.x.x.x iburst
>
>     server primary2.x.x.x iburst
>
>     restrict default kod nomodify nopeer noquery limited
>     restrict 127.0.0.1
>     restrict ::1
>

You might consider re-ordering your file to have your own primaries first; 
my understanding, potentially flawed,
is that ntp.conf is read 'in order' on startup, so having the 'pool' entry 
first means it will be checked before the others on startup. Pool entries 
randomly incur a lot of DNS lookup overhead on startup (in my experience). 
Another of my potentially flawed understandings is that while three 
sources is required, four sources is optimal. You might throw in a 
reasonably reliable individual stratum two server to your mix. While it's 
terribly larded-up with ancient and dead server listings, 
https://support.ntp.org/Servers/StratumTwoTimeServers is an otherwise good 
resource for that.

Also set minpoll/maxpoll for the primary lines to query those more frequently.

On one of my lan devices that queries my own GPS disciplined timeserver 
(also on the lan), I use this:

server 192.168.1.10             minpoll 3 maxpoll 10 iburst
server clock.sjc.he.net         minpoll 6 maxpoll 10 iburst # San Jose 
216.218.254.202
server timekeeper.delphij.net   minpoll 6 maxpoll 10 iburst # Fremont 
64.62.153.210
server dmz2.la-archdiocese.net  minpoll 6 maxpoll 10 iburst # Los Angeles 
205.161.200.3

Obviously you'd use more geographically adjacent sources.

Whether any of this advice would resolve the problem, I dunno. Good luck.

-- 
Paul Theodoropoulos
www.anastrophe.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20240722/065ae6fe/attachment.htm>