NTP - poor reach after 20 hours
-
Yeah that is not uncommon if your heavy use of your internet connection, or just peering problems..
I am in the middle of a video conference for work, and had been saturating my pipe before that with downloads.. So mine is prob not best example currently.
And I just updated to 21.02.2 last night via a clean install, etc..
You have an active peer, so you should be syncing time... I would just keep an eye on it.. Will do the same on mine, etc. But yeah when everything is fine.. you would want 377 for all of them..
-
Offset & Jitter is terrible too.
Are the packets sent by Pigdin
/Bingo
-
20 hours is not really a long time when it comes to ntp ;)
Mine after the clean install has a pretty big offset its still working through... Seeing some steps in the log for ntp..
I would prob give it a few days.. Then take a look again.. That is what I am doing with mine..
Give it time to settle down..
Is this a new instance of pfsense? Has recently been rebooted, etc.. Or has it been up for days arleady?
-
@johnpoz pfsense has been up for two weeks, but changed NTP to four pool servers from five individual servers from this NTP server list yesterday. I'll wait a few more days to see how it settles in.
-
You prob don't need more than 1 pool ;)
Yeah I am keeping an eye mind as well, since this is a clean install.. I am not sure if anything changed with the ntp client in this update, etc.
Will follow back in this in a few days.. I am seeing the same thing where reach is just not constant 377.. But also seeing the steps happening the log.. Which will refresh the reach count, etc.
example:
Apr 15 10:46:10 ntpd 42851 0.0.0.0 0615 05 clock_sync Apr 15 10:46:09 ntpd 42851 0.0.0.0 061c 0c clock_step +0.475341 sAnd offset is horrible currently..
Prob doesn't help that I just also updated and rebooted my local ntp server ;) But yeah ntp can take a while to setting down..
-
@johnpoz said in NTP - poor reach after 20 hours:
You prob don't need more than 1 pool ;)
shoud I go ahead and delete the other 3 pools that I have and just use 0.us.pool.ntp.org?
-
Well you should prob use the pfsense pool ;)
The ntp pool allows for vendors to get their own pool names.. And users using pools using the vendors devices should use them... I haven't gotten around to changing mine - doing it now ;)
0.pfsense.pool.ntp.org
for example..
Just changed mine
here is info on the vendor pools
https://www.pool.ntp.org/en/vendors.html -
This is my linux server
And i haven't even sync'ed it up to my Tbolt or Samsung or ....
Just using inet peers./Bingo
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== -n1.taur.dk .PPS. 1 u 501 1024 377 7.190 0.022 0.841 +80.71.132.103 ( .GPS. 1 u 868 1024 377 1.821 0.268 0.135 *mmo2.ntp.se .PPS. 1 u 971 1024 377 1.972 0.206 0.078 +78.156.103.10 217.198.219.102 2 u 77 1024 377 7.466 0.240 0.247 +mail.roostervan 212.99.225.86 2 u 16 1024 377 2.453 0.278 0.100 -time.cloudflare 10.20.10.78 3 u 1008 1024 377 10.140 0.042 0.113 -
^ yeah this a normal sort of status you should be seeing.
edit: That is some really low delays.. nice!
-
My pfSense
I use pfSense pool for pfSense.
But selected servers for my Linux.
n1.taur.dk is a friend of mine (also a time-nut) , his server is always "spot on"
My linux usually switches between n1.taur & the swedish one./Bingo
-
yeah those are some really nice low delays - have a nice internet connection ;)
-
@johnpoz
switched over to pfsense.pool 90 min. ago. Here is status so far:[2.5.0-RELEASE][admin@pfsense.home]/var/log: ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 +0.000 0.000 time.nullrouten 132.163.97.1 2 u 713 256 344 62.225 +0.955 0.504 +tick.nde.unlv.e 98.150.140.243 2 u 390 128 204 71.450 -7.756 2.534 +165.227.106.11 200.98.196.212 2 u 673 128 240 40.571 -0.168 3.267 *vps1.n1.ca 216.218.192.202 2 u 981 128 200 69.463 +1.543 2.424 -
-
There's quite a bit of jitter on your selected peer.
It' only won because it's a Stratum 1./Bingo
-
@bingo600 subject of thread is 'poor' reach not 'porn' reach.
-
@johnpoz
i updated from 2.5.0 to 2.5.1. Here is NTP status after 90 minutes after reboot. Hopefully the Scandinavian guys won't try and shame me again with their impressive NTP output.[2.5.1-RELEASE][admin@pfsense.home]/var/log: ntpq -pcrv remote refid st t when poll reach delay offset jitter ============================================================================== 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 +0.000 0.000 +unifi.versadns. 71.66.197.233 2 u 632 128 120 42.354 -2.973 1.580 *clock.nyc.he.ne .CDMA. 1 u 453 128 144 37.191 +1.439 1.048 associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, version="ntpd 4.2.8p15@1.3728-o Fri Feb 5 22:07:56 UTC 2021 (1)", processor="amd64", system="FreeBSD/12.2-STABLE", leap=00, stratum=2, precision=-21, rootdelay=37.191, rootdisp=476.256, refid=209.51.161.238, reftime=e4233dba.ae57b7eb Thu, Apr 15 2021 18:33:30.681, clock=e42344a7.e24f1d1b Thu, Apr 15 2021 19:03:03.884, peer=60391, tc=7, mintc=3, offset=+1.048514, frequency=+38.158, sys_jitter=4.679301, clk_jitter=1.975, clk_wander=0.060 -
A couple of the connections we have.
-
Try changing pools
Changed mine from dk, se, no to 0,1,2,3.europe.pool.ntp.org
It bettered the jitter quite considerably.
-
@cool_corona
I'll try going back to multiple pool servers (.us.pool.ntp.org) - hopefully that will improve my current situation (status after 19 hours):[2.5.1-RELEASE][admin@pfsense.home]/var/log: ntpq -pcrv remote refid st t when poll reach delay offset jitter ============================================================================== 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 +0.000 0.000 +tock.sol.net 206.55.64.77 3 u 41m 512 20 37.120 +1.937 1.621 -4.53.160.75 (ns 75.76.123.222 3 u 1722 512 70 26.891 +3.313 1.226 *frigg.fancube.c 107.46.198.112 2 u 1581 512 44 43.347 +3.275 2.363 associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, version="ntpd 4.2.8p15@1.3728-o Fri Feb 5 22:07:56 UTC 2021 (1)", processor="amd64", system="FreeBSD/12.2-STABLE", leap=00, stratum=3, precision=-21, rootdelay=49.680, rootdisp=77.172, refid=154.16.245.246, reftime=e4240ee1.afd0e2c4 Fri, Apr 16 2021 9:25:53.686, clock=e424150e.f3e02c84 Fri, Apr 16 2021 9:52:14.952, peer=60404, tc=9, mintc=3, offset=+1.958787, frequency=+37.805, sys_jitter=1.230244, clk_jitter=3.129, clk_wander=0.225 -
Make sure your logging your ntp, in the ntp settings.
And look for if ntp is seeing a spike and or resetting for other reasons. Your reaches should be 377, or maybe 1 packet missed now and then, or even a couple..
Those are horrible reach values.. And to be honest, the numbers don't even seem right.. Unless ntp is restarting or you missing a lot of packets..
You shouldn't see numbers like that, unless ntp has reset/restarted and is just starting... Or your loosing a lot of packets in a row..
20 for example, means that you have just restarted and you got 1 packet out of the last 5
10000 = 20 octal
So you have missed the last 4 packets after you got one, and before that you didn't have any.. Or 3 before that was missed 00010000
You really should never see a 20 as it starts up, because it wouldn't count up like that if your getting responses..
Your counts should be
1 = 1
11 = 3
111 = 7
1111 = 17
11111 = 37
111111 = 77
1111111 = 177
11111111 = 377Your reach values are pointing to a lot of unanswered queries..
your 44 value for example would be this for the last 8 packets..
00100100
So your only getting 1 out of every 3 queries?
70 = 00111000
So you got 3 in a row, and then last 3 nothing..
