Re: [ntp:questions] Speed of ntp convergence
The key seems to be the lines: etemp = min(mu, (u_long)ULOGTOD(sys_poll)); dtemp = 4 * CLOCK_PLL * ULOGTOD(sys_poll); plladj = fp_offset * etemp / (dtemp * dtemp); Ie if we assume that the etemp is determined by the poll interval, we have plladj=fp_offset /(16*CLOCK_PLL^2*(Sys poll time) That is a huge time scale. Surely CLOCK_PLL should only come in there to the first power (at most), not squared. Unruh [EMAIL PROTECTED] writes: Just another data point on the behaviour of ntp. My ntp went down ( due to something removing the ntp user from the password file). When I brought it back up again, the time was out and I think the drift file was out. I have three sources-- a stratum 2 nearby server, a distant stratum 1 server and a gps refclock with a PPS. The PPS is setup to drive the refclock_shm driver. The refclock has a poll of 4 (pollinterval of 16), and both the other are default ( minref 6 maxref 10) I brought the system back up at 54770 78683.101 (the ntp log file date and time) The way the PPS works is that it waits about 5 min until it is sure that ntp has the time from the other servers to within 250ms. It then switches on the shm driver. The refclock started out with an offset of about 150ms , which increased to 280ms and was eventually (about 6 min later) reset to zero offset because I was running with the -g for ntp. This was also the point at which the PPS shm kicked in. However the drift rate was clearly off, because the offset then gradually increased until at 82555 (3878 sec after the start or about 1hr) it was 52ms off (the maximum offset) . By the end of the day ( 86400 or about 7700sec or 2 hrs) it was still 19ms offset from the PPS zero time. An hour later, it was still 7ms off, another hour, 2.6ms and another hour later, still 1.2 ms off. Ie, only after about 6 hours was it within a ms of the correct time. Now, usually this PPS controls the time to within about 2us (not ms, usec) but it is apparently going to take over 10 hours to get there. That is of course completely rediculous. The shm poll interval is 16 sec and even if ntp throws away 7/8 that would give a max time between data points of about 128sec or 2 min. Thus ntp should have a time constant of about 4 min. Instead the time constant is about an hour. It would seem that the time constant is selected as far longer than the longest poll inteval. ( the poll interval during this time on the other two source was 64 sec, or poll interval of 6). Within the first minute, I could by hand determine the offset and slope of the CPU clock to withing a few usec not msec or tens of msec. and the slope to better than 1PPM. But never mind my concern about the markovian system feedback system ntp uses. That argument I am sure everyone is tired of. What concerns me is the long (1hr) time constant of the feedback loop, about 200 times longer than the poll interval. Ie, it does not seem to me that ntp is fulfilling its design criteria. Here after 5.5 hours after startup is the ouput of ntpq -p string[root]ntpq -p remote refid st t when poll reach delay offset jitter == +tick.usask.ca .GPS.1 u 18 64 377 44.9251.455 4.252 +ntp.ubc.ca 140.142.16.342 u 44 64 3430.6720.260 0.767 *SHM(0) .PPS.0 l1 16 3770.0001.136 0.023 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] ntptime says that clock is unsynchronized
Hello, I'm trying to analyze a failure scenario that occurs on a server and client in my network. First my server, which only synchronizes to the system clock: # ntpq -p remote refid st t when poll reach delay offset jitter == *LOCAL(0)LOCAL(0)10 l 10 16 3770.000 0.000 0.001 I *know* that it should have more upstream peers, but that is beside the point I hope. My client synchronizes to that server just fine: # ntpq -p remote refid st t when poll reach delay offset jitter == LOCAL(0)LOCAL(0)12 l7 16 3770.000 0.000 0.001 *192.168.1.4 LOCAL(0)11 u 22 64 3770.118 41.432 0.524 But when I run ntptime on the server, I get this: # ntptime ntp_gettime() returns code 5 (ERROR) time ccbd930d.7cfa6000 Thu, Nov 6 2008 16:00:13.488, (.488195), maximum error 16384000 us, estimated error 16 us ntp_adjtime() returns code 5 (ERROR) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 4 s, maximum error 16384000 us, estimated error 16 us, status 0x41 (PLL,UNSYNC), time constant 0, precision 1.000 us, tolerance 512 ppm, pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. Why the errors? Return code 5 means that the clock is unsynchronized but I see no reason for that to happen. It is perfectly synchronized to the system clock. Maximum error is 16384000 which I think is some default value? ntptime on the client looks much healthier: # ntptime ntp_gettime() returns code 0 (OK) time ccbd93a3.42335000 Thu, Nov 6 2008 16:02:43.258, (.258595), maximum error 6263312 us, estimated error 16 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency -18.108 ppm, interval 4 s, maximum error 6263312 us, estimated error 16 us, status 0x1 (PLL), time constant 0, precision 1.000 us, tolerance 512 ppm, pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. The system appears to work fine at the moment, but why the strange ntptime output? Thanks in advance. Please let me know if you need more information. -- mvh Björn ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate synchronization often fails
Thanks Steve for your answer I have changed my conf file with your advices. Indeed, ntpd takes less time to synchronize at the beginning with the minipoll instruction. But I still have failed synchronizations. So, I am going to try the last snapshot dev. Thanks a lot. Yoann. 2008/11/6 Steve Kostecke [EMAIL PROTECTED] On 2008-11-06, Yoann Fages [EMAIL PROTECTED] wrote: I am trying to set up a ntp server on an embedded linux platform. My platform will be connected to a switch (not connected to internet) and all clients will synchronize their clock with my platform local clock. The synchronization quality is directly related to the stability of the clock on your platform. I have downloaded and install ntpd, set up a conf file (ntp.conf) on my platform: Assuming that you are using a stable release of NTP from www.ntp.org ... conf file: server 127.127.1.0 Ntpd will take a bit under 4 minutes to synchronize to the local clock if you use that server line. You may reduce this time to a bit under 60 seconds by appending 'minpoll 4' to that server line. fudge 127.127.1.0 stratum 3 refid AmT3 You should set the statum to something higher (i.e. 10, or more) just in case this private network is connected to a public network. logfile /var/log/ntp.log restrict default notrap nopeer nomodify restrict 192.168.0.0 mask 255.255.0.0 Those restrict lines are not affecting the issue you have raised. But why do you feel that they are neccessary? On my platform I launch ntpd -c ntp.conf. On a linux PC connected to the switch, I launch: ntpdate -b -v server_ip_@ Most of the time, I get this error message: ntpdate : no server suitable for synchronization found, but sometimes the synchronization is OK. You have to wait for ntpd on your platform to synchronize to the localclock. What can I do to always have a synchronization? Speed up synchronization as shown above. Or use an NTP-dev snapshot; it accepts the Undisciplined Local Clock after the first poll. Or modify the source to suit your needs. Or consider other solutions such as timed, or rdate (on the clients) + inetd (on the platform). -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
