[ntp:questions] Loop Frequency and Offset
Hi guys! I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs too fast or slow (positive offset in loopstats is fast or slow?). tick# tail -10 /var/log/ntp/loopstats 55829 66814.311 0.10871 185.398 0.03540 0.002317 4 55829 66831.312 0.10025 185.398 0.00984 0.002167 4 55829 66847.312 0.11242 185.398 0.01303 0.002027 4 55829 66862.313 0.11571 185.398 0.00625 0.001896 4 55829 66877.313 0.10833 185.398 0.00990 0.001774 4 55829 66893.323 0.11386 185.398 0.00724 0.001659 4 55829 66909.314 0.10876 185.398 0.00574 0.001552 4 55829 66927.314 0.11263 185.398 0.00620 0.001452 4 55829 66942.315 0.11355 185.398 0.00402 0.001358 4 55829 66957.315 0.10197 185.398 0.01026 0.001270 4 The frequency is too high it seems. Since this is a software clock can this be changed to get a lower frequency and thus a smaller offset? In another machine I am getting (also FreeBSD 7.4): tock# tail -10 /var/log/ntp/loopstats 55829 66540.886 -0.00472 46.597 0.00364 0.011080 6 55829 66604.886 0.02199 46.597 0.00287 0.010364 6 55829 8.886 0.04014 46.616 0.00245 0.011887 6 55829 66732.886 0.05470 46.616 0.00269 0.09 6 55829 66796.886 0.06189 46.616 0.00227 0.010401 6 55829 66860.886 0.05828 46.616 0.00176 0.009730 6 55829 66924.886 0.03394 46.645 0.02087 0.013579 6 55829 66988.887 0.01509 46.645 0.00211 0.012702 6 55829 67052.887 -0.00924 46.645 0.00173 0.011882 6 55829 67116.887 -0.03216 46.645 0.00390 0.04 6 Here a much lower frequency and a smaller offset at each reset interval? Any pointers? Thanks!! Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
Miguel Gonçalves wrote: I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs too fast or slow (positive offset in loopstats is fast or slow?). Neither. A constant sign on an offset is an indication that something is broken, either the algorithm, or the static frquency error exceeds 500ppm. Offsets should be normally distributed around 0. Well, maybe not a normal distribution, but certainly they should be both sides of zero. The frequency is too high it seems. Since this is a software clock can this be changed to get a lower frequency and thus a smaller offset? tickadj can be used to make 100ppm steps, but if the clock is out by more then 500ppm, something is broken, and it would be better to fix it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
2011/9/25 Miguel Gonçalves : > I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs > too fast or slow (positive offset in loopstats is fast or slow?). ntpd's offset and the frequency compensation are both reported as corrections to the local clock to bring it into alignment with the source(s). So a positive offset means the clock is behind correct, and a positive frequency correction means the clock runs slower than correct. > tick# tail -10 /var/log/ntp/loopstats > 55829 66814.311 0.10871 185.398 0.03540 0.002317 4 > 55829 66831.312 0.10025 185.398 0.00984 0.002167 4 > 55829 66847.312 0.11242 185.398 0.01303 0.002027 4 > 55829 66862.313 0.11571 185.398 0.00625 0.001896 4 > 55829 66877.313 0.10833 185.398 0.00990 0.001774 4 > 55829 66893.323 0.11386 185.398 0.00724 0.001659 4 > 55829 66909.314 0.10876 185.398 0.00574 0.001552 4 > 55829 66927.314 0.11263 185.398 0.00620 0.001452 4 > 55829 66942.315 0.11355 185.398 0.00402 0.001358 4 > 55829 66957.315 0.10197 185.398 0.01026 0.001270 4 > > The frequency is too high it seems. Since this is a software clock can this > be changed to get a lower frequency and thus a smaller offset? As David Wooley noted, you should be able to use tickadj to bump the software clock frequency by 100 PPM. That's invisible to ntpd, so after tickadj, delete your driftfile and restart ntpd. Make sure the measured drift is indeed closer to zero. > In another machine I am getting (also FreeBSD 7.4): > > tock# tail -10 /var/log/ntp/loopstats > 55829 66540.886 -0.00472 46.597 0.00364 0.011080 6 > 55829 66604.886 0.02199 46.597 0.00287 0.010364 6 > 55829 8.886 0.04014 46.616 0.00245 0.011887 6 > 55829 66732.886 0.05470 46.616 0.00269 0.09 6 > 55829 66796.886 0.06189 46.616 0.00227 0.010401 6 > 55829 66860.886 0.05828 46.616 0.00176 0.009730 6 > 55829 66924.886 0.03394 46.645 0.02087 0.013579 6 > 55829 66988.887 0.01509 46.645 0.00211 0.012702 6 > 55829 67052.887 -0.00924 46.645 0.00173 0.011882 6 > 55829 67116.887 -0.03216 46.645 0.00390 0.04 6 > > Here a much lower frequency and a smaller offset at each reset interval? More notable to me: The frequency compensation is varying. What version(s) of ntpd are the two machines running? On the first one, given the loopstats covers less than 300 seconds and the frequency appears locked, I'm guessing you sampled during initial offset convergence. That's new for 4.2.7 and runs for the first 300 seconds (by default) after the frequency compensation is loaded from driftfile or measured. During that period, the frequency compensation is locked while ntpd attempts to slew away the initial offset until less than 500 usec remains, or the 300s limit elapses. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
2011/9/25 Dave Hart : > 2011/9/25 Miguel Gonçalves : > >> tick# tail -10 /var/log/ntp/loopstats >> 55829 66814.311 0.10871 185.398 0.03540 0.002317 4 >> 55829 66831.312 0.10025 185.398 0.00984 0.002167 4 >> 55829 66847.312 0.11242 185.398 0.01303 0.002027 4 >> 55829 66862.313 0.11571 185.398 0.00625 0.001896 4 >> 55829 66877.313 0.10833 185.398 0.00990 0.001774 4 >> 55829 66893.323 0.11386 185.398 0.00724 0.001659 4 >> 55829 66909.314 0.10876 185.398 0.00574 0.001552 4 >> 55829 66927.314 0.11263 185.398 0.00620 0.001452 4 >> 55829 66942.315 0.11355 185.398 0.00402 0.001358 4 >> 55829 66957.315 0.10197 185.398 0.01026 0.001270 4 >> > More notable to me: The frequency compensation is varying. What > version(s) of ntpd are the two machines running? On the first one, > given the loopstats covers less than 300 seconds and the frequency > appears locked, I'm guessing you sampled during initial offset > convergence. That's new for 4.2.7 and runs for the first 300 seconds > (by default) after the frequency compensation is loaded from driftfile > or measured. During that period, the frequency compensation is locked > while ntpd attempts to slew away the initial offset until less than > 500 usec remains, or the 300s limit elapses. Nice theory, Dave, but you overlooked that all those offsets are within 500 usec of zero (in fact within +10 to +12 usec), which would trigger the end of initial offset convergence and unclamping the frequency compensation. I'd suggest starting with the tickadj correction, and testing again to see if the offsets are staying on one side of zero. I'm still curious about the ntpd versions involved. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
[Sorry for such a long message] Hi David! On 25 September 2011 20:55, David Woolley wrote: > Miguel Gonçalves wrote: > >> >> I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs >> too fast or slow (positive offset in loopstats is fast or slow?). >> > > Neither. A constant sign on an offset is an indication that something is > broken, either the algorithm, or the static frquency error exceeds 500ppm. > Offsets should be normally distributed around 0. Well, maybe not a normal > distribution, but certainly they should be both sides of zero. OK. Understood. I fiddled with the machdep.tsc_freq sysctl variable it it seems to work the other way around. I am a bit confused. Please see bellow... > The frequency is too high it seems. Since this is a software clock can >> this >> be changed to get a lower frequency and thus a smaller offset? >> > > tickadj can be used to make 100ppm steps, but if the clock is out by more > then 500ppm, something is broken, and it would be better to fix it. > On FreeBSD I followed the recommendation in http://www.ntp.org/ntpfaq/NTP-s-trbl-general.htm#Q-CORRECT-TICK and changed the machdep.tsc_freq sysctl variable like this (I am documenting it here for the future reference of others who might have this problem). So... I was getting around 180 ppm frequency offset in /etc/ntp.drift and this value also appeared in loopstats file. I checked the machdep.tsc_freq value (this is estimated at boot but can be changed after the boot completes): tick# sysctl machdep.tsc_freq machdep.tsc_freq: 498053689 Now... if the clock is running 180 ppm fast (I assumed slower and the result was the opposite i.e. it ran even faster) I have to decrease the frequency by 180 ppm: 498053689 - (498053689 * 180/100) = 497964040 After removing ntp.drift file and restarting NTP loopstats was still showing 0.800 ppm so I repeated the above and now I am getting this: tick# tail -20 /var/log/ntp/loopstats ; ntpq -p; ntptime 55830 48124.307 -0.00867 0.029 0.02503 0.001010 10 55830 48141.308 -0.01511 0.029 0.00601 0.000945 10 55830 48157.308 -0.01360 0.029 0.00484 0.000884 10 55830 48175.324 -0.02170 0.029 0.00774 0.000827 10 55830 48192.309 -0.01375 0.029 0.00879 0.000774 10 55830 48209.315 -0.01562 0.029 0.01097 0.000724 10 55830 48224.315 -0.01839 0.019 0.00600 0.003492 10 55830 48241.315 -0.02042 0.019 0.00817 0.003266 10 55830 48258.316 -0.01567 0.019 0.00626 0.003055 10 55830 48276.311 -0.01146 0.019 0.02616 0.002858 10 55830 48292.307 -0.01464 0.019 0.00878 0.002674 10 55830 48308.312 -0.01022 0.019 0.00612 0.002501 10 55830 48323.313 -0.01218 0.019 0.00489 0.002339 10 55830 48341.309 -0.00421 0.019 0.01017 0.002188 10 55830 48358.313 -0.00492 0.019 0.00612 0.002047 10 55830 48375.309 -0.00457 0.019 0.00274 0.001915 10 55830 48390.309 -0.01434 0.019 0.00865 0.001791 10 55830 48408.311 0.00191 0.019 0.00716 0.001675 10 55830 48424.310 -0.00543 0.019 0.01052 0.001567 10 55830 48441.311 0.00400 0.019 0.01109 0.001466 10 remote refid st t when poll reach delay offset jitter == *GPS_NMEA(0) .GPS.0 l 14 16 3770.0000.000 0.004 -ntp-p1.obspm.fr .TS-3. 1 u 857 1024 377 54.3762.222 0.454 -ptbtime1.ptb.de .PTB.1 u 500 1024 377 74.4640.559 0.360 +ntp.inrim.it.CTD.1 u 839 1024 367 68.0390.313 0.428 -ntp1.oma.be .PPS.1 u 860 1024 377 60.4204.012 1.877 -canon.inria.fr .GPSi. 1 u 872 1024 377 53.5071.039 2.830 +time.fu-berlin. .PPS.1 u 875 1024 373 73.133 -0.095 1.109 -chronos.csr.net .GPS.1 u 507 1024 377 87.641 -3.010 0.317 -ntp1.nl.uu.net .PPS.1 u 835 1024 377 67.4850.926 1.646 ntp_gettime() returns code 0 (OK) time d22afc47.a990c06c Mon, Sep 26 2011 13:27:35.662, (.662365031), maximum error 7501 us, estimated error 1 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -0.502 us, frequency 0.019 ppm, interval 256 s, maximum error 7501 us, estimated error 1 us, status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO), time constant 10, precision 0.001 us, tolerance 496 ppm, pps frequency 0.019 ppm, stability 0.008 ppm, jitter 1.124 us, intervals 249, jitter exceeded 282, stability exceeded 1, errors 4. In the other machine (tock) I did the same and I getting now this: tock# tail -20 /var/log/ntp/loopstats ; ntpq -p; ntptime 55830 48250.451 -0.01296 -0.094 0.00888 0.002944 4 55830 48266.451 -0.00905 -0.094 0.00182 0.002754 4 55830 48282.451 -0.00794 -0.094 0.00212 0.002576 4 55830 48298.452 -0.00449 -0.094 0.00207 0.002410 4 55830 48314.451 0.00281 -0.094 0.00215 0.002
Re: [ntp:questions] Loop Frequency and Offset
Hi Dave! 2011/9/26 Dave Hart > 2011/9/25 Miguel Gonçalves : > > I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs > > too fast or slow (positive offset in loopstats is fast or slow?). > > ntpd's offset and the frequency compensation are both reported as > corrections to the local clock to bring it into alignment with the > source(s). So a positive offset means the clock is behind correct, > and a positive frequency correction means the clock runs slower than > correct. > Thanks for all your support to reach a solution for this problem! I found out that 180 ppm were the result of the CPU running too fast because if I increased the CPU frequency by 180 ppm I would get a even higher offset. Am I wrong? It seems I solved the problem as I showed in my previous post. Funny thing is that this machine has been running like this (180 ppm) since July and it never complained... Obviously I always found odd 10 us offsets but for NTP it was good enough. > > > tick# tail -10 /var/log/ntp/loopstats > > 55829 66814.311 0.10871 185.398 0.03540 0.002317 4 > > 55829 66831.312 0.10025 185.398 0.00984 0.002167 4 > > 55829 66847.312 0.11242 185.398 0.01303 0.002027 4 > > 55829 66862.313 0.11571 185.398 0.00625 0.001896 4 > > 55829 66877.313 0.10833 185.398 0.00990 0.001774 4 > > 55829 66893.323 0.11386 185.398 0.00724 0.001659 4 > > 55829 66909.314 0.10876 185.398 0.00574 0.001552 4 > > 55829 66927.314 0.11263 185.398 0.00620 0.001452 4 > > 55829 66942.315 0.11355 185.398 0.00402 0.001358 4 > > 55829 66957.315 0.10197 185.398 0.01026 0.001270 4 > > > > The frequency is too high it seems. Since this is a software clock can > this > > be changed to get a lower frequency and thus a smaller offset? > > As David Wooley noted, you should be able to use tickadj to bump the > software clock frequency by 100 PPM. That's invisible to ntpd, so > after tickadj, delete your driftfile and restart ntpd. Make sure the > measured drift is indeed closer to zero. > Did it and I am getting tick# tail -5 /var/log/ntp/loopstats ; ntpq -p ; ntptime 55830 48740.318 0.00172 0.027 0.01288 0.001534 10 55830 48755.315 -0.00731 0.027 0.00809 0.001435 10 55830 48771.315 -0.00563 0.027 0.00713 0.001342 10 55830 48788.310 -0.00651 0.027 0.01134 0.001255 10 55830 48805.310 -0.00303 0.027 0.00432 0.001174 10 Is 0.027 good enough or should I wait for it to stabilise and reduce it? The machine is not loaded (not money wise of course :-)) and sits in a temperature controlled room (20 ºC). > > In another machine I am getting (also FreeBSD 7.4): > > > > tock# tail -10 /var/log/ntp/loopstats > > 55829 66540.886 -0.00472 46.597 0.00364 0.011080 6 > > 55829 66604.886 0.02199 46.597 0.00287 0.010364 6 > > 55829 8.886 0.04014 46.616 0.00245 0.011887 6 > > 55829 66732.886 0.05470 46.616 0.00269 0.09 6 > > 55829 66796.886 0.06189 46.616 0.00227 0.010401 6 > > 55829 66860.886 0.05828 46.616 0.00176 0.009730 6 > > 55829 66924.886 0.03394 46.645 0.02087 0.013579 6 > > 55829 66988.887 0.01509 46.645 0.00211 0.012702 6 > > 55829 67052.887 -0.00924 46.645 0.00173 0.011882 6 > > 55829 67116.887 -0.03216 46.645 0.00390 0.04 6 > > > > Here a much lower frequency and a smaller offset at each reset interval? > > More notable to me: The frequency compensation is varying. What > version(s) of ntpd are the two machines running? On the first one, > given the loopstats covers less than 300 seconds and the frequency > appears locked, I'm guessing you sampled during initial offset > convergence. That's new for 4.2.7 and runs for the first 300 seconds > (by default) after the frequency compensation is loaded from driftfile > or measured. During that period, the frequency compensation is locked > while ntpd attempts to slew away the initial offset until less than > 500 usec remains, or the 300s limit elapses. > The first one is running NTP 4.2.4p5 (180 ppm previosly) and the second one (46 ppm) is running 4.2.6p3. Thanks for your help! Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
2011/9/26 Dave Hart > 2011/9/25 Dave Hart : > > 2011/9/25 Miguel Gonçalves : > > > >> tick# tail -10 /var/log/ntp/loopstats > >> 55829 66927.314 0.11263 185.398 0.00620 0.001452 4 > >> 55829 66942.315 0.11355 185.398 0.00402 0.001358 4 > >> 55829 66957.315 0.10197 185.398 0.01026 0.001270 4 > Nice theory, Dave, but you overlooked that all those offsets are > within 500 usec of zero (in fact within +10 to +12 usec), which would > trigger the end of initial offset convergence and unclamping the > frequency compensation. > What is a typical offset of the loop without using special oscillators? Is less than 1 us achievable? Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
Miguel Gonçalves wrote: What is a typical offset of the loop without using special oscillators? Is less than 1 us achievable? Depends on the network or reference clock, and the resolution to which the local clock can be read. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
On 9/26/2011 9:41 AM, Miguel Gonçalves wrote: 2011/9/26 Dave Hart 2011/9/25 Dave Hart: 2011/9/25 Miguel Gonçalves: tick# tail -10 /var/log/ntp/loopstats 55829 66927.314 0.11263 185.398 0.00620 0.001452 4 55829 66942.315 0.11355 185.398 0.00402 0.001358 4 55829 66957.315 0.10197 185.398 0.01026 0.001270 4 Nice theory, Dave, but you overlooked that all those offsets are within 500 usec of zero (in fact within +10 to +12 usec), which would trigger the end of initial offset convergence and unclamping the frequency compensation. What is a typical offset of the loop without using special oscillators? Is less than 1 us achievable? I don't believe that accuracy of 1 microsecond , or less, is obtainable without without installing a GPS Timing Receiver or an atomic clock of some sort. Your chances of obtaining 1 microsecond accuracy using clocks on the internet is just about nil! OTOH very few people actually need microsecond accuracy for anything other than "bragging rights"! Would you really care if you missed the first 75 microseconds of your favorite TV program? I didn't think so! The telephone companies, wired or wireless, rely on extremely precise timing. Radio astronomers really care about nanoseconds. I'm sure that a few others care about the nanoseconds. Those who do need the nanoseconds generally have the specialized equipment and know how required. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
Hi Richard! On 26 September 2011 22:39, Richard B. Gilbert wrote: > > What is a typical offset of the loop without using special oscillators? Is >> less than 1 us achievable? >> > > I don't believe that accuracy of 1 microsecond , or less, is obtainable > without without installing a GPS Timing Receiver or an atomic clock of some > sort. > I have a Motorola Oncore UT+ that I'll be testing soon. I've just averaged the position of the antenna during 72 hours. Besides correcting the CPU clock frequency what can I do to improve the performance? The machines I have at the moment are showing worse than 1 us performance perhaps because I am not using GPS timing receivers. Your chances of obtaining 1 microsecond accuracy using clocks on the > internet is just about nil! OTOH very few people actually need > microsecond accuracy for anything other than "bragging rights"! > I know... :-) My cable connection is really bad for NTP... I can't get better than 3 us. That is why I have 2 stratum 1 GPS receivers onsite. Would you really care if you missed the first 75 microseconds of your > favorite TV program? I didn't think so! > This is mainly a personal project and if it goes as intended it will be the first public stratum 1 available in my country. It is sad but even our National Observatory doesn't care much about time as a public service... Take a look at one of their stratum 2 public servers: tick# ntpq -p ntp02.oal.ul.pt remote refid st t when poll reach delay offset jitter == +ntp01.oal.ul.pt .GPS.1 u 235 512 3775.139 -0.158 0.566 ntp03.oal.ul.pt .INIT. 16 u- 102400.0000.000 0.000 ntp04.oal.ul.pt 194.117.9.1382 u 444 512 3770.376 -0.518 0.040 +ntp05.oal.ul.pt .GPS.1 u 255 512 3770.3180.163 0.064 *ntp06.oal.ul.pt .IRIG. 1 u 483 512 3770.3030.169 0.072 160 us offsets?? Now, take a look at my VoIP server from which all the desk phones in my company synchronize time: tick# ntpq -pn asterisk remote refid st t when poll reach delay offset jitter == +10.0.2.10 .GPS.1 u7 16 3770.1910.001 0.004 *10.0.2.9.GPS.1 u 16 16 3770.187 -0.002 0.005 :-) For me this is a good stratum 2 server :-) > The telephone companies, wired or wireless, rely on extremely precise > timing. Radio astronomers really care about nanoseconds. I'm sure that a > few others care about the nanoseconds. Those who do need the nanoseconds > generally have the specialized equipment and know how required. And I care about microseconds just as a proof of concept, as a personal challenge. I've built two stratum 1 servers to be used in my company and saved thousands of dollars. Obviously Symmetricoms and Meinbergs have bells and whistles that ease administration but in the end they just provide time service. My two boxes do the same for a fraction of the cost. I was just wondering if there's anywhere else I should look at in order to improve performance. Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
Just a small correction... 2011/9/27 Miguel Gonçalves > > Your chances of obtaining 1 microsecond accuracy using clocks on the >> internet is just about nil! OTOH very few people actually need >> microsecond accuracy for anything other than "bragging rights"! >> > > I know... :-) My cable connection is really bad for NTP... I can't get > better than 3 us. That is why I have 2 stratum 1 GPS receivers onsite. > I meant 3 ms of course! Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
2011/9/26 Miguel Gonçalves : > 2011/9/26 Dave Hart >> 2011/9/25 Miguel Gonçalves : >> > I have a machine running FreeBSD 7.4 and it seems that the CPU clock >> > runs >> > too fast or slow (positive offset in loopstats is fast or slow?). >> >> ntpd's offset and the frequency compensation are both reported as >> corrections to the local clock to bring it into alignment with the >> source(s). So a positive offset means the clock is behind correct, >> and a positive frequency correction means the clock runs slower than >> correct. > > Thanks for all your support to reach a solution for this problem! > > I found out that 180 ppm were the result of the CPU running too fast because > if I increased the CPU frequency by 180 ppm I would get a even higher > offset. Am I wrong? It seems I solved the problem as I showed in my previous > post. I think you're simply confused. The FreeBSD sysctl you modified isn't adjusting the TSC frequency. It's adjusting FreeBSD's estimate of the TSC frequency. I stand by my understanding that a positive frequency compensation reported by ntpd means the clock's uncompensated rate is slow. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
On 2011-09-26, Miguel Gon?alves wrote: > Hi Richard! > > On 26 September 2011 22:39, Richard B. Gilbert wrote: >> >> What is a typical offset of the loop without using special oscillators? Is >>> less than 1 us achievable? >>> >> >> I don't believe that accuracy of 1 microsecond , or less, is obtainable >> without without installing a GPS Timing Receiver or an atomic clock of some >> sort. >> > > I have a Motorola Oncore UT+ that I'll be testing soon. I've just averaged > the position of the antenna during 72 hours. > > Besides correcting the CPU clock frequency what can I do to improve the > performance? The machines I have at the moment are showing worse than 1 us > performance perhaps because I am not using GPS timing receivers. Any(?) gps receiver which has PPS output does better than 1us. Any network does much worse than 1 us ( more like 10s of us to hundreds). > > Your chances of obtaining 1 microsecond accuracy using clocks on the >> internet is just about nil! OTOH very few people actually need >> microsecond accuracy for anything other than "bragging rights"! >> > > I know... :-) My cable connection is really bad for NTP... I can't get > better than 3 us. That is why I have 2 stratum 1 GPS receivers onsite. You will NOT bet 3us from any network connection. Are you sure you are not confusing microseconds (us) with milliseconds (ms)? And even with a high accuracy timing receiver you will not get better than ab out 1us because of hardware interrupt latencies and variability, etc (and thermal wandering of your computer clock) unless you have some very specialised hardware. > > Would you really care if you missed the first 75 microseconds of your >> favorite TV program? I didn't think so! >> > > This is mainly a personal project and if it goes as intended it will be the > first public stratum 1 available in my country. It is sad but even our > National Observatory doesn't care much about time as a public service... > Take a look at one of their stratum 2 public servers: > > tick# ntpq -p ntp02.oal.ul.pt > remote refid st t when poll reach delay offset > jitter >== > +ntp01.oal.ul.pt .GPS.1 u 235 512 3775.139 -0.158 > 0.566 > ntp03.oal.ul.pt .INIT. 16 u- 102400.0000.000 > 0.000 > ntp04.oal.ul.pt 194.117.9.1382 u 444 512 3770.376 -0.518 > 0.040 > +ntp05.oal.ul.pt .GPS.1 u 255 512 3770.3180.163 > 0.064 > *ntp06.oal.ul.pt .IRIG. 1 u 483 512 3770.3030.169 > 0.072 > > 160 us offsets?? Now, take a look at my VoIP server from which all the desk > phones in my company synchronize time: > > tick# ntpq -pn asterisk > remote refid st t when poll reach delay offset > jitter >== > +10.0.2.10 .GPS.1 u7 16 3770.1910.001 > 0.004 > *10.0.2.9.GPS.1 u 16 16 3770.187 -0.002 > 0.005 > >:-) For me this is a good stratum 2 server :-) > > >> The telephone companies, wired or wireless, rely on extremely precise >> timing. Radio astronomers really care about nanoseconds. I'm sure that a >> few others care about the nanoseconds. Those who do need the nanoseconds >> generally have the specialized equipment and know how required. > > > And I care about microseconds just as a proof of concept, as a personal > challenge. I've built two stratum 1 servers to be used in my company and > saved thousands of dollars. Obviously Symmetricoms and Meinbergs have bells > and whistles that ease administration but in the end they just provide time > service. My two boxes do the same for a fraction of the cost. > > I was just wondering if there's anywhere else I should look at in order to > improve performance. > > Cheers, > Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
In article , David Woolley writes: >Miguel Gon=E7alves wrote: >> What is a typical offset of the loop without using special oscillators? >> Is less than 1 us achievable? >Depends on the network or reference clock, and the resolution to which >the local clock can be read. It also depends upon the stability of the local oscillator. Inexpensive oscillators (as used in PCs or most servers) are quite temperature sensitive. The temperature in your box will probably change as the load on the system changes or the room temperature changes. In fact, you can use a PC running ntpd as a thermometer. This is good work and a fun read: NTP temperature compensation Mark Martinec, 2001-01-08 http://www.ijs.si/time/temp-compensation/ -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
Richard B. Gilbert wrote: I don't believe that accuracy of 1 microsecond , or less, is obtainable without without installing a GPS Timing Receiver or an atomic clock of some sort. He asked for an offset of 1 microsecond (presumably RMS or 90 percentile?), not an accuracy of 1 microsecond. If you ignore systematic errors, an offset of 1 microsecond corresponds to an accuracy in the low 100s of nanoseconds. However, without special instrumentation of both hardware and software, he won't be able to measure the systematic error, so an RMS offset in the one microsecond region could be associated with a rather larger systematic error. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
Miguel Gonçalves wrote: Besides correcting the CPU clock frequency what can I do to improve the Applying a static correction to the clock frequency only helps if the static error is close to or greater than 500ppm. However, if that is the case, the right thing to do is to replace the motherboard, with a better one as it is likely that the clock is unstable as well as having a high static error. performance? The machines I have at the moment are showing worse than 1 us performance perhaps because I am not using GPS timing receivers. Make sure the system is only used as a time server. Keep its temperature very constant. Disable any form of power management (in particular variable clock rates). Disable spread spectrum clocks. Calibrate the systematic error by outputting a hardware pulse within the kernel at a precisely known system clock time and using hardware to measure the offset from the PPS input pulse. You will need to also output the system time at which you did this, but that needn't be in real time. Do not try to do this on the second. I know... :-) My cable connection is really bad for NTP... I can't get better than 3 us. That is why I have 2 stratum 1 GPS receivers onsite. Reading that as 3ms. The time you serve will have that sort of jitter in, it so there is little point in being accurate to better than about 100 microseconds of jitter/wander. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
On 27 September 2011 01:29, unruh wrote: > Any(?) gps receiver which has PPS output does better than 1us. Any > network does much worse than 1 us ( more like 10s of us to hundreds). > I might be wrong but checking for instance the Garmin 18 LVC specifications (http://www8.garmin.com/products/gps18oem/spec.html) I do not see better than 1 us accuracy. > > I know... :-) My cable connection is really bad for NTP... I can't get > > better than 3 us. That is why I have 2 stratum 1 GPS receivers onsite. > > You will NOT bet 3us from any network connection. > Are you sure you are not confusing microseconds (us) with milliseconds > (ms)? > I don't mix ms and us... I wasn't BETTING on anything... :-) It was a typo of course (errare humanum est). > And even with a high accuracy timing receiver you will not get better > than ab out 1us because of hardware interrupt latencies and variability, > etc (and thermal wandering of your computer clock) unless you have some > very specialised hardware. > 1 us is OK for me. Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
On 27 September 2011 10:35, David Woolley wrote: > Applying a static correction to the clock frequency only helps if the > static error is close to or greater than 500ppm. However, if that is the > case, the right thing to do is to replace the motherboard, with a better one > as it is likely that the clock is unstable as well as having a high static > error. One had 180 ppm sand the other 46 ppm without fiddling with machdep.tsc_freq sysctl variable. After the correction I am getting -0.041 ppm for the first and -0.045 ppm for the second. > > performance? The machines I have at the moment are showing worse than 1 us >> performance perhaps because I am not using GPS timing receivers. >> > > Make sure the system is only used as a time server. Keep its temperature > very constant. Disable any form of power management (in particular variable > clock rates). Disable spread spectrum clocks. > Embedded machines running NanoBSD and they don't do anything else besides running NTP. They sit in a temperature controlled room at 20 ºC. Power management has been disabled. I checked the BIOS and did not see any reference to spectrum clocks. > Calibrate the systematic error by outputting a hardware pulse within the > kernel at a precisely known system clock time and using hardware to measure > the offset from the PPS input pulse. You will need to also output the > system time at which you did this, but that needn't be in real time. > > Do not try to do this on the second. Makes sense... I'll investigate a way of doing this. > > I know... :-) My cable connection is really bad for NTP... I can't get >> better than 3 us. That is why I have 2 stratum 1 GPS receivers onsite. >> > > Reading that as 3ms. The time you serve will have that sort of jitter in, > it so there is little point in being accurate to better than about 100 > microseconds of jitter/wander. You read well :-) Cheers, Miguel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
On Mon, Sep 26, 2011 at 02:29:42PM +0100, Miguel Gonçalves wrote: > So... I was getting around 180 ppm frequency offset in /etc/ntp.drift and > this value also appeared in loopstats file. > > I checked the machdep.tsc_freq value (this is estimated at boot but can be > changed after the boot completes): > > tick# sysctl machdep.tsc_freq > machdep.tsc_freq: 498053689 > > Now... if the clock is running 180 ppm fast (I assumed slower and the result > was the opposite i.e. it ran even faster) I have to decrease the frequency > by 180 ppm: > > 498053689 - (498053689 * 180/100) = 497964040 Just a minor correction (but I've seen others do that too). The value in driftfile is how much the system clock has to be sped up to match UTC, not how much the clock is slower than UTC. The error is tiny at such small values, but if you want to invert it accurately, you need to divide it by 1.000180 instead of multiply by 0.999820. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
On Tue, Sep 27, 2011 at 10:20:57AM +0100, David Woolley wrote: > Richard B. Gilbert wrote: > > > > >I don't believe that accuracy of 1 microsecond , or less, is > >obtainable without without installing a GPS Timing Receiver or an > >atomic clock of some sort. > > He asked for an offset of 1 microsecond (presumably RMS or 90 > percentile?), not an accuracy of 1 microsecond. > > If you ignore systematic errors, an offset of 1 microsecond > corresponds to an accuracy in the low 100s of nanoseconds. Only if the loop is tracking frequency changes well. If you see in the loopstats log long runs of offsets with the same sing, the actual error is probably closer to the reported offset. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
On 2011-09-27, Miguel Gon?alves wrote: > One had 180 ppm sand the other 46 ppm without fiddling with machdep.tsc_freq > sysctl variable. After the correction I am getting -0.041 ppm for the first > and -0.045 ppm for the second. > > > Embedded machines running NanoBSD and they don't do anything else besides > running NTP. They sit in a temperature controlled room at 20 ?C. Power > management has been disabled. I checked the BIOS and did not see any > reference to spectrum clocks. > Miguel: There are a lot of links off of the leapsecond.com of home made methods that improve clock stability. I am using one of these PC clock crystal replacement boards in my Intel Atom. http://www.leapsecond.com/ptti2003/index.htm http://www.tapr.org/~n8ur/Clock-Block_Manual.pdf Installation is meant for someone with better than average soldering skills. This device replaces your motherboard clock crystal with something that is more stable. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Loop Frequency and Offset
2011/9/27 Miguel Gonçalves : > 2011/9/27 Dave Hart >> >> I think you're simply confused. The FreeBSD sysctl you modified isn't >> adjusting the TSC frequency. It's adjusting FreeBSD's estimate of the >> TSC frequency. I stand by my understanding that a positive frequency >> compensation reported by ntpd means the clock's uncompensated rate is >> slow. > > Dear Dave, > > As you hold an ntp.org mail account I will trust you. But, why did the > frequency adjustment in loopstats reduced drastically when I changed the > sysctl variable? I assumed NTP did not see the sysctl variable. I don't suggest you take my word for it, but reason it yourself. Your system clock is implemented on top of the TSC. Your earlier emails seemed to indicate you believed your sysctl adjustment was resulting in your TSC rate being changed to match, however, the knob you turned instead adjusted the system's estimate of how many beats of TSC equate to 1 SI second, while the TSC's actual rate is unchanged. Decreasing the TSC frequency estimate sysctl means FreeBSD will run its UTC clock faster, as fewer TSC beats are required from the fixed-rate TSC for each SI second advanced. As I would expect, speeding up a system clock which is running slower than UTC to close to UTC's rate meant ntpd needed a less-positive frequency compensation (drift). > Anyway, can I let the variable stay as is and let NTP do the adjustment? Yes. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
