What is Reach in NTP?
A conversation on the PlanePlotter group resulted in this note from Dan Henry, for which many thanks.
Thank you David - you just helped me to better understand something.
I have read the official definitions of "reach" many times, and I understand the octal/binary comparisons. I always knew that 377 was best, but never fully understood exactly what the binary values meant until your simple explanation.
I understand that 377 means 8 successful connections, but did not
understand the significance of octal=377 to binary=11111111 until you described it that
way. The official description of octal display, bit-masking, and 8-bit shift registers just never clicked in my brain, until I read it in the very simple way you described it above.
For the non-programmers, compare the definition here:
The column reach shows if a reference time source could be reached at the last polling intervals, i.e. data could be read from the reference time source, and the reference time source was synchronized. The value must be interpreted as an 8 bit shift register whose contents is for historical reasons displayed as octal values. If the NTP daemon has just been started, the value is 0. Each time a query was successful a '1' is shifted in from the right, so after the daemon has been started the sequence of reach numbers is 0, 1, 3, 7, 17, 37, 77, 177, 377. The maximum value 377 means that the eight last queries were completed successfully.
Now read David's much easier to understand version here:
"Secondly, after about 10 minutes running all the "reach" figures should "377" (binary 11111111) showing 8 successful connections."
I suspect I'm not the first person to finally figure this out, so here is an example of how the reach octal value can change just because of one single lost response:
Reach Binary Interpretation 377 11111111 Normal. Last 8 connections all good. 376 11111110 Last connection was bad. 375 11111101 The one previous bad connection is now sliding left. .. .. The bad connection continues to slide left. .. .. The bad connection continues to slide left. 177 01111111 Later it will look like this before sliding off to the left. 377 11111111 Finally the one single bad connection is gone from the history.
Notice how the reach = 177 value looks really bad, but it is still just one single lost connection out of the last 8 attempts. The reach = 177 is actually much better than the reach = 376, since it happened longer ago.
Thank you David. Your simple explanation finally clicked for me and my rambling here and examples might help it click for others as well. Learning and better understanding things is always fun!
A normal response to "ntpq -pn"
DJT: I stole this from a previous post - here you can see that I'm using four local NTP servers (192.168.0.n) and the UK "pool" server.
If any of your "reach" values are not 377, suspect that you (or your family, or your neighbour?) are using your internet connection heavily, and it's possible that the NTP packets are being lost or dropped by your ISP. If any of the delay values are high suspect they might be on a trans-Atlantic path.
Octal numbers
For those not used to using octal (0-7) numbering systems, it might help to show how to use a
Windows-10 calculator to display the value in binary.
Using Windows 10 calculator to convert octal to binary:
- Start calculator app.
- Change "Standard" mode in top left to "Programmer" mode.
- Select "OCT" for octal input on the left side.
- Enter octal value. 375 for this example
- Look at left side "BIN" binary value 1111 1101
Acknowledgement
Dan Henry notes: Feel free to use, edit, and improve it any way you like.