-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2020-01-10 at 19:55 -0000, Dave Howorth wrote:
On 10/01/2020 19.47, James Knott wrote: | On 2020-01-10 01:28 PM, Carlos E. R. wrote:
|>> number, such as 0., 1., 2., or 3. before pool.ntp.org. |> |> You can specify country. |> | | Pool.ntp.org will connect to servers according to where you are. | If I ping those addresses, I'll generally see servers in the | Toronto, Ontario area, which is where I live.
Me, I specify a dozen servers, on Spain, Portugal, France... etc. The daemon will choose which to actually use.
Why do you seem to care so much about your clock source? In the worst case, your PC/device will run on its internal clock and will slowly drift. Not a major problem.
Once upon a time I worked with a telco setting up an ATM network in London. Their time source was in a rack with five slots. Slot 1 was a GPS card. Slot 2 (backup) was a GPS card. Slot 3 (backup's backup etc) was a GPS card. Slot 4 was a GPS card. Slot 5 was an atomic clock.
I worked with a telco startup, and their reference clock, if purchased, was a quartz xtal inside an oven (to keep at a precise constant temperature, so no random drift). Pretty expensive. Design prior to GPS. Machine (5ESS) did not have any internet connection. I don't know if they added that later (GPS clock). At the time I knew those details, their clock was a simple quartz (default) and we set it up with a simple "date" command in unix :-D I suppose later they did something, but I did not get to know.
What they most cared about was keeping the same time as everybody else.
Same as me.
Only in extremis did they care about keeping something working. But the requirements for timekeeping in an ATM network are orders of magnitude above what I need, or any other mortal as far as I can see. My ntp.conf has what I think is the default:
server 0.opensuse.pool.ntp.org iburst server 1.opensuse.pool.ntp.org iburst server 2.opensuse.pool.ntp.org iburst server 3.opensuse.pool.ntp.org iburst
And I have more because I have seen servers of the pool in Spain, usually volunteers, to fail. And have four of them fail simultaneously, which is why I define more. Because I have seen many fail. The daemon is clever enough to decide and choose. Look: Isengard:~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 28d 64 0 0.000 0.000 0.000 #hora.ngn.rima-t 172.20.47.7 5 u 155 1024 377 13.202 1.309 0.466 <-- My ISP, I think - -Telcontar.valin 85.199.*.* 2 u 88 1024 377 0.321 -2.098 0.457 <-- My desktop machine - -ntp.redimadrid. 193.147.*.* 2 u 531 1024 377 13.275 -0.082 0.234 - -scott.red.uv.es 66.78.*.* 2 u 181 1024 377 22.782 -0.025 0.536 - -bjaaland.red.uv 66.78.*.* 2 u 164 1024 377 22.760 -0.089 0.630 +162.159.*.* 10.40.*.* 3 u 1025 1024 377 12.061 -1.148 0.539 +23.141.*.*.b 212.51.*.* 2 u 645 1024 377 38.604 -0.156 0.625 - -dedibox.demonge 145.238.*.* 2 u 89 1024 375 30.542 0.482 0.697 #electra.pinklem 192.36.*.* 2 u 152 1024 377 40.157 -3.077 0.363 #smtp.irtech.ch 162.23.*.* 2 u 253 1024 377 48.507 -3.071 0.496 - -ns3.stoneartpro 193.52.*.* 2 u 246 1024 377 26.988 -0.341 0.504 *194.80.*.* .GPS. 1 u 14 64 377 54.970 -1.153 0.078 - -178.255.*.* 194.80.*.* 2 u 45 1024 377 17.523 1.163 0.587 Isengard:~ # ^ | \-- code Code Message T Description 0 sel_reject discarded as not valid (TEST10-TEST13) 1 sel_falsetick x discarded by intersection algorithm 2 sel_excess . discarded by table overflow (not used) 3 sel_outlyer - discarded by the cluster algorithm 4 sel_candidate + included by the combine algorithm 5 sel_backup # backup (more than tos maxclock sources) 6 sel_sys.peer * system peer 7 sel_pps.peer o PPS peer (when the prefer peer is valid) As you can see, several are put as backup (#). Six are discarded (-); that's a high percent. The daemon is clever :-) Interestingly, the desktop machine refuses (-) my server machine: "discarded by the cluster algorithm". remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 10h 64 0 0.000 0.000 0.000 - -Isengard.valino 194.80.*.* 2 u 865 1024 377 0.303 2.111 0.399 Also interestingly, the IP reported for the LAN peer is different in both machines: Telcontar.valin 85.199.*.* Isengard.valino 194.80.*.* which were the external IPs at the time of startup, I guess. The daemon is not clever here, does not update the IPs. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhjz5Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVxjQAn3uUJGBAv/cD5gRU4zPe xAXRdAn4AJ9m2Uv2SMrhMKlgwp3/ps5uvPn8Tg== =6UZn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org