2015-02-17, 21:24
i believe very accurate or let's say extremely precise.
otherwise the calculation for the location of the lightning strokes could not be done.
of course i switched on the NTP server functionality. as with every watch one wants have it running very exactly. even if it is in a way of precision i never can use it. i configured my solaris server to use my system red as stratum 1. additional i configured 2 stratum 1 server near my location in vienna with "noselect". as i know from the past it is always bad if delay and especially jitter is high. and one additional from the location where the time is made ( braunschweig :-) also with "noselect". i also have a DCF77 which has per definition a big systemic error. i adjusted this with the "fudge" statement to be _near_ the GPS signal. when i look i have most of the time a situation like this:
my server takes the time from system red (*192.168.241.190) and has a typically offset between 6 and 8 ms against the others stratum 1. that means that system red is in average 7 ms in the future against the others. unfortunately the "fudge" statement works only for reference clocks and not for the system red i configured in my server which is stratum 2.
i don't know how many of you are using system red as ntp server. any feedback about experience from you about this topic is welcome.
maybe the future brings a possibility to enter an offset for the ntp server functionality. but i know it's not the primary function of this system.
finally i want to say thank you to Egon and others for this great project.
kind regards
hans
--
otherwise the calculation for the location of the lightning strokes could not be done.
of course i switched on the NTP server functionality. as with every watch one wants have it running very exactly. even if it is in a way of precision i never can use it. i configured my solaris server to use my system red as stratum 1. additional i configured 2 stratum 1 server near my location in vienna with "noselect". as i know from the past it is always bad if delay and especially jitter is high. and one additional from the location where the time is made ( braunschweig :-) also with "noselect". i also have a DCF77 which has per definition a big systemic error. i adjusted this with the "fudge" statement to be _near_ the GPS signal. when i look i have most of the time a situation like this:
PHP Code:
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+192.168.241.93 .DCFa. 1 u 62 1024 377 0.743 -0.706 4.345
*192.168.241.190 .GPS. 1 u 365 1024 377 0.917 -0.001 0.139
192.53.103.108 .PTB. 1 u 418 1024 377 46.284 -8.819 0.673
178.189.127.147 .ATOM. 1 u 996 1024 377 21.794 -5.281 0.512
131.130.251.107 .PPS. 1 u 205 1024 377 18.983 -6.134 12.341
my server takes the time from system red (*192.168.241.190) and has a typically offset between 6 and 8 ms against the others stratum 1. that means that system red is in average 7 ms in the future against the others. unfortunately the "fudge" statement works only for reference clocks and not for the system red i configured in my server which is stratum 2.
i don't know how many of you are using system red as ntp server. any feedback about experience from you about this topic is welcome.
maybe the future brings a possibility to enter an offset for the ntp server functionality. but i know it's not the primary function of this system.
finally i want to say thank you to Egon and others for this great project.
kind regards
hans
--