NTP - poor reach after 20 hours

bingo600

Offset & Jitter is terrible too.

Are the packets sent by Pigdin

/Bingo

johnpoz

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?

farmerjohn

@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.

johnpoz

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 s

And 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..

farmerjohn

@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?

johnpoz

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

bingo600

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

johnpoz

^ yeah this a normal sort of status you should be seeing.

edit: That is some really low delays.. nice!

bingo600

@johnpoz

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

johnpoz

yeah those are some really nice low delays - have a nice internet connection ;)

farmerjohn

@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

Cool_Corona

bingo600

@cool_corona

There's quite a bit of jitter on your selected peer.
It' only won because it's a Stratum 1.

/Bingo

farmerjohn

@bingo600 subject of thread is 'poor' reach not 'porn' reach.

farmerjohn

@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

Cool_Corona

A couple of the connections we have.

Cool_Corona

Try changing pools

Changed mine from dk, se, no to 0,1,2,3.europe.pool.ntp.org

It bettered the jitter quite considerably.

farmerjohn

@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

johnpoz

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 = 377

Your 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..

farmerjohn

@johnpoz
I enabled the two logging options. here are the last 15 - not sure if 'unreachable' lines are a concern or normal.

[2.5.1-RELEASE][admin@pfsense.home]/var/log: cat ntpd.log | tail -15
Apr 16 11:45:37 pfsense ntpd[76193]: Soliciting pool server 142.147.92.5
Apr 16 11:45:41 pfsense ntpd[76193]: 69.89.207.99 101a 8a sys_peer
Apr 16 11:45:41 pfsense ntpd[76193]: 45.79.51.42 0014 84 reachable
Apr 16 11:46:44 pfsense ntpd[76193]: Soliciting pool server 209.50.63.74
Apr 16 11:47:52 pfsense ntpd[76193]: Soliciting pool server 142.147.92.5
Apr 16 11:49:02 pfsense ntpd[76193]: Soliciting pool server 75.76.123.222
Apr 16 11:49:02 pfsense ntpd[76193]: 75.76.123.222 0011 81 mobilize assoc 33714
Apr 16 11:49:03 pfsense ntpd[76193]: Soliciting pool server 184.105.182.7
Apr 16 11:49:03 pfsense ntpd[76193]: 75.76.123.222 0014 84 reachable
Apr 16 11:50:12 pfsense ntpd[76193]: Soliciting pool server 172.86.181.78
Apr 16 11:51:18 pfsense ntpd[76193]: Soliciting pool server 72.14.181.128
Apr 16 11:52:25 pfsense ntpd[76193]: Soliciting pool server 213.32.40.221
Apr 16 11:52:38 pfsense ntpd[76193]: 216.177.181.129 0014 84 reachable
Apr 16 11:54:29 pfsense ntpd[76193]: 69.89.207.99 0613 83 unreachable
Apr 16 11:55:52 pfsense ntpd[76193]: 45.79.51.42 0013 83 unreachable