Hello Alica, On 27-04-16 10:24, Alica wrote: > Recently I managed to add a Garmin 18x LVC GPS receiver to my pool server, > which (sometimes) can achieve microsecond level error.
Cool :-) > Sample ntpq -p > 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 "Nearby" clients will definitely get the better time. The pool DNS servers try to return "nearby" NTP servers to the clients. > 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. Now, your server is a good choice for other NTP pool server operators who operate at stratum 2 or 3. > 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? Partly. Your clients get better time and you add another stratum 1 in your area that other pool server operators can configure. This is always good! :-) "The pool" just provides time "AS IS". There are absolutely NO guarantees about the accuracy. For daily use (catching trains, be in time for appointment, etc.) and for logging with 1 second resolution, an accuracy of 0.1 second is good enough. See the additional notes on http://www.pool.ntp.org/en/use.html and the link on that page to http://www.pool.ntp.org/tos.html The monitor of the pool checks A) if a server returns valid time at all and B) if the time is within about 0.1 second of the time of the monitor itself. If it is, your score increases (towards the max score of 20). The only purpose of the monitor is to make the binary decision: should this pool server be included in the pool system, or not. You should not use the monitor as a performance monitor on the millisecond level. However, it is nice that the details of the monitoring data are available ;-) So, as long as your server has a score of 20, it is good enough. Clients of the pool end up with a random "nearby" NTP server, that can be your high accuracy server, or the low accuracy (+/-50 ms) server of your neighbour. So, clients of the pool SHOULD NEVER count on pool servers providing such high accuracy! If they end up at your server, your high accuracy is just a bonus. > 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... Providing 'better' time may attract people to configure your server directly with your IP instead of the pool. In the end, your better time may become the reason you are forced to take your server offline... At the moment NTP pool clients in Taiwan will benefit the most from *more* local NTP servers in the pool. Perhaps you know someone to translate the www.pool.ntp.org pages to Taiwanese? This might help others in Taiwan to join the pool as well. Kind regards, Arnold _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
