NTP - poor reach after 20 hours
-
Is this normal? shouldn't the reach be better than this?
ntpq -pcrv remote refid st t when poll reach delay offset jitter ============================================================================== 0.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 1.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 2.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 3.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 +ntp3.junkemailf 216.218.254.202 2 u 71m 512 200 61.825 -1.997 0.500 -tock.chi1.ntfo. 206.55.64.77 3 u 65m 512 200 20.087 +7.651 3.635 +12.167.151.1 66.85.78.80 3 u 65m 512 200 41.281 -0.723 1.975 associd=0 status=0628 leap_none, sync_ntp, 2 events, 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=69.791, rootdisp=163.214, refid=45.79.111.167, reftime=e422ad63.ed822f77 Thu, Apr 15 2021 8:17:39.927, clock=e422c2e7.13bf3518 Thu, Apr 15 2021 9:49:27.077, peer=61202, tc=9, mintc=3, offset=-0.670054, frequency=+37.707, sys_jitter=2.656898, clk_jitter=1.141, clk_wander=0.065 -
Yeah reach should be 377
You could do the math on a 200 to figure out what packets you have missed in the last 8
https://www.linuxjournal.com/article/6812
that they are all the same, would assume you had some sort of blip/bump/glitch where you were having connectivity issues for a small bit.
Are you saying it never goes over 200? Did you maybe just fill up your pipe or something.. Any sort of say saturation of your connection could cause reach issues..
-
@johnpoz the reach does vary, but most of the time it is 1-3 packets out of 8.
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 1.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 2.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 3.us.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 tock.chi1.ntfo. 206.55.64.77 3 u 92 512 1 20.009 +10.665 6.826 *12.167.151.1 66.85.78.80 3 u 712 512 2 43.632 +1.343 1.403 +clock.fmt.he.ne .CDMA. 1 u 671 512 6 61.980 +0.363 2.513 206-55-191-142. .PPS. 1 u 166 512 3 27.886 +0.876 1.838 -
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.
