Recently I managed to add a Garmin 18x LVC GPS receiver to my pool server,
which (sometimes) can achieve microsecond level error. Sample ntpq -p
follows: (I am too lazy to rebuild ntpd from source to add KPPS support;
hence gpsd SHM is used instead)
remote refid st t when poll reach delay offset
jitter
==============================================================================
-SHM(0) .GPS. 0 l 36 64 377 0.000 -505.65
19.344
*SHM(1) .PPS. 0 l 36 64 377 0.000 0.002
0.010
-118-163-81-62.H 192.168.0.2 2 u 64 64 377 3.551 0.508
1.242
+211-22-103-157. .IRIG. 1 u 2 64 337 3.524 0.995
0.170
-118-163-81-61.H 192.168.0.3 2 u 43 64 377 3.605 0.697
1.412
-118-163-81-63.H 192.168.0.3 2 u 50 64 377 3.748 0.696
3.394
-211-22-103-158. 192.168.0.2 2 u 56 64 377 3.417 0.557
0.497
+223.255.185.2 .MRS. 1 u 48 64 261 26.167 0.391
0.838
-ntp-a3.nict.go. .NICT. 1 u 65 64 377 34.078 0.222
0.234
However from the pool monitoring server located beyond the Pacific, my
server have shown no difference between previous stratum >=2 (sync from
other ntp servers) and stratum 1 (current local PPS) config. Before the
switch:
1461699958,"2016-04-26 19:45:58",0.00496721267700195,1,16.8,0
1461698830,"2016-04-26 19:27:10",-0.00330531597137451,1,16.6,0
1461697739,"2016-04-26 19:08:59",-0.00324296951293945,1,16.5,0
1461696684,"2016-04-26 18:51:24",0.00187623500823975,1,16.3,0
1461695614,"2016-04-26 18:33:34",-0.00148475170135498,1,16.1,0
1461694537,"2016-04-26 18:15:37",0.0015261173248291,1,15.9,0
1461693447,"2016-04-26 17:57:27",0.00410068035125732,1,15.7,0
1461692342,"2016-04-26 17:39:02",0.001556396484375,1,15.4,0
1461691241,"2016-04-26 17:20:41",0.00130021572113037,1,15.2,0
1461690130,"2016-04-26 17:02:10",-0.000460147857666016,1,14.9,0
1461689025,"2016-04-26 16:43:45",0.00134515762329102,1,14.7,0
1461687916,"2016-04-26 16:25:16",0.00343143939971924,1,14.4,0
1461686821,"2016-04-26 16:07:01",0.00000810623168945312,1,14.1,0
After the switch @ 4-26 20:00 (4/27 04:00 in UTC+8) plus 4 hours for
stabilize:
1461729306,"2016-04-27 03:55:06",-0.000715017318725586,1,19.2,0
1461728181,"2016-04-27 03:36:21",0.00240159034729004,1,19.1,0
1461727059,"2016-04-27 03:17:39",0.00314462184906006,1,19.1,0
1461725927,"2016-04-27 02:58:47",0.00316357612609863,1,19,0
1461724798,"2016-04-27 02:39:58",-0.00300896167755127,1,19,0
1461723656,"2016-04-27 02:20:56",0.00312268733978271,1,18.9,0
1461722510,"2016-04-27 02:01:50",0.00125288963317871,1,18.9,0
1461721355,"2016-04-27 01:42:35",-0.00106370449066162,1,18.8,0
1461720269,"2016-04-27 01:24:29",0.00255942344665527,1,18.7,0
1461719130,"2016-04-27 01:05:30",0.00122308731079102,1,18.7,0
1461717970,"2016-04-27 00:46:10",0.00256168842315674,1,18.6,0
1461716868,"2016-04-27 00:27:48",0.00213003158569336,1,18.5,0
1461715746,"2016-04-27 00:09:06",-0.00528824329376221,1,18.4,0
There is still millisecond level offset. Seems like the trans-Pacific
latency can easily degrade the accuracy benefit from PPS signal. So there
is no real reason for a pool server to acquire PPS signal and microsecond
accuracy, because the pool clients won't see the difference after all. Am I
correct?
==
Serving avearge 11.5M people (23M Taiwanese population with only 2 IPv4
pool servers online) is very challenging for my 15yr+ old (Celeron 1GHz
from 2000) pool server. The incoming requests have never lower than 3k
packets/sec, with peak over 7k packets/sec...
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
