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
--
