Summary is that you are in good shape. More comments below. On Feb 28, 2010, at 5:36 AM, Goran Sandin wrote:
> On Sunday 28 February 2010 01.12.14 Ralph Smith wrote: >> On Feb 27, 2010, at 2:25 PM, Goran Sandin wrote: >>> I use this tool http://www.satsignal.eu/software/net.htm#NTPmonitor to >>> check the result. >>> >>> The result is not in line with my expectations so I think something is >>> not quite right. > > It might have been my expectations that was a little bit off... It took much > longer than I had expected for ntpd to reach a small offset. NTP convergence times are often discussed, with some people being surprised or dismayed with the convergence speed. Personally, I have no problem with it as long as you know what to expect. Also, keep in mind that ntp is designed to deal with distributing time across jittery network links. > ntptime now (18 hours after selecting the PPS as source) show: > > # ntptime > ntp_gettime() returns code 0 (OK) > time cf34b8f6.fb361508 Sun, Feb 28 2010 9:42:14.981, (.981294987), > maximum error 5534 us, estimated error 15 us, TAI offset 0 > ntp_adjtime() returns code 0 (OK) > modes 0x0 (), > offset 0.021 us, frequency -0.040 ppm, interval 1 s, > maximum error 5534 us, estimated error 15 us, > status 0x2001 (PLL,NANO), > time constant 4, precision 0.001 us, tolerance 496 ppm, > > The ntp_adjtime() - offset is still trying to get better, but it seems to be > stable at values below 0.1 us. This indicates that you are spot on. The offset returned by ntp_adjtime() of 0.021 us is well within the 125 ns resolution of the timestamping capability of the timer. Have you replaced the clock chip with a clock derived from a precision frequency source? The frequency offset of 0.040 ppm would indicate that. That is what mine indicates, and is due to the slight difference between the clock rate presented and the rate that FreeBSD uses. The sysctl variable machdep.elan_freq gives a clue: wendell# sysctl machdep.elan_freq machdep.elan_freq: 33333332 wendell# This value is the nearest multiple of 4 to the clock rate. I use the TAPR clock block, which generates a frequency of 33,333,333.33.... Hz, which differs by 1.333... Hz, of the -0.040 ppm. As an experiment I drove the clock block with the correct frequency to get 33333332 Hz and that value went to 0.000 as expected. >>> If I compare with a normal PC (running FreeBSD 7.1) which is synchronized >>> against stratum 2 servers over Internet, the performance I get from >>> net4501 is not any better than this PC. >>> >>> The NTPmonitor program show following result: >>> >>> An Internet Stratum1 server | my PC | net4501 >>> >>> Precision: 2^-29s 2^-19s 2^-16s >>> >>> Dispersion: 2ms ~30ms 0ms >> >> The precision values shown are to be expected, and isn't anything to really >> get excited about, and is a function of the machine architecture. From >> <http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm> we read "In NTP >> precision is determined automatically, and it is measured as a power of >> two. For example when ntpq -c rl prints precision=-16, the precision is >> about 15 microseconds (2^-16 s)." > > OK. I thought that the precision was something that was measured from remote > and lower value was better. > > Is 15 us "right" for net4501, or does it indicate that something in my > configurations should be changed? 15 us is right. That value indicated for jitter is the lower bound due to the precision discussed above. Your actual jitter is much below that. > >>> Both the PC and net4501 show a huge offset error of 1s about 11 times in >>> 2 hours. The Internet Stratum1 server does not seem to have this error. > > I solved this one. It seems to be a Windows-"feature". I was using host names > in the config file for NTPmonitor. The server on internet of course had a > real > name that could be found by dns-lookup. My internal machines was found since > the were listed in 'lmhosts'. > > After I changed the config file for NTPmonitor to use ip-addresses for my > internal machines instead of host names, the very periodic 1 second offset > has > disappeared. DNS timeouts strike in unexpected places. >> Can't help much until we know what peers and refclocks you have configured. >> Also, make sure that you have the following in your kernel configuration. >> options CPU_ELAN >> options CPU_SOEKRIS >> options HZ=150 >> options CPU_ELAN_PPS > > I have those, or rather I used HZ=200. > > febo.com says HZ=1000 should be used, but also had a description of how > things > were related. My PPS signal is 25.6ms wide. So I thought that 200Hz would > give > me 5ms polling and that it should be good enough margin to the 25ms width I > have for the PPS. That's fine. The HZ=150 is a minimum. > > febo.com also says you should include 'option GEOM_VOL', but your config file > did not. I did not include this option in the kernel. That has to do with disk volume management, and maybe I should look and see if I need this, but I'm working fine without it. > >>> My feeling is that my net4501 server does not really use the PPS signal. >>> How do I check if the ntpd daemon actually use the PPS? >> >> What are you using to drive the PPS signal? ntpq -p will tell you if ntp is >> using the pps. This all depends on course on what drivers you configure >> it to use: my system is currently showing: >> >> wendell# ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> ========================================================================== >> ==== +ntp.cox.net .GPS. 1 u 1594 1024 366 28.771 2.371 >> 0.545 *SHM(0) .GPS. 0 l 15 16 377 0.000 >> 4.976 0.231 oPPS(0) .PPS. 0 l 12 16 377 >> 0.000 0.000 0.015 wendell# >> >> The "o" in the first column tells me that ntp is synchronizing with the >> PPS. Offset is less than 1 microsecond. >> >>> Or rather, how do I know the the precision of the PPS signal is >>> transferred into the ntpd daemon? >>> >>> (I can see with ntpq -p that the PPS row from the config file is >>> selected) >> >> Showing what ntpq -p gives you would help. > > # ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > +GPS_NMEA(0) .GPS. 0 l 12 16 377 0.000 -47.458 15.063 > oPPS(0) .PPS. 0 l 11 16 377 0.000 0.000 0.015 > > As I already mentioned, I could see that the PPS was selected here. > > I use this one: http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm > as > source for both 10MHz and NMEA-data. Your PPS is selected, and you are in good shape. Your jitter is actually much better than the 15 us indicated. The indicated value is a minimum, and is related to the precision value already discussed. > > The offset for the GPS source is changing constantly. This is probably > because > the output from the gps receiver does not have the same number of lines > between each reported $GPRMC line. You are also limited by serial port latency and jitter. > > A cycle looks like this: > > $GPRMC,221617,A,57**.****,N,012**.****,E,0.000,355.2,211209,1.6,E*79 > $PRWIZCH,06,0,02,2,03,0,05,7,15,0,07,7,28,7,13,7,10,7,08,7,19,0,21,2*46 > $GPGGA,221618,57**.****,N,012**.****,E,1,06,0.89,6.0,M,40.1,M,,*79 > $GPGSA,A,3,05,07,28,13,10,08,,,,,,,1.55,0.89,1.26*04 > $GPGSV,3,1,12,08,77,156,51,05,60,253,46,10,60,217,50,07,50,070,49*7D > $GPGSV,3,2,12,28,22,157,42,15,19,281,00,13,16,101,43,03,12,041,00*74 > $GPGSV,3,3,12,06,11,030,00,21,11,338,00,19,05,065,00,02,02,223,00*79 > $GPRMC,221618,A,57**.****,N,012**.****,E,0.000,355.2,211209,1.6,E*76 > $PRWIZCH,06,0,02,2,03,0,05,7,15,0,07,7,28,7,13,7,10,7,08,7,19,0,21,2*46 > $GPGGA,221619,57**.****,N,012**.****,E,1,06,0.89,6.0,M,40.1,M,,*78 > $GPGSA,A,3,05,07,28,13,10,08,,,,,,,1.55,0.89,1.26*04 > > Since fractional seconds are not reported, this is probably the reason for > the > figure in the ntpq -p output for the GPS source. I am not sure yet if this is > a problem or not, more than what I need to use in ntp.conf to make it work. I > need to do more tests with restarting ntpd to see if it is able to find the > correct time and change to PPS all the times. I had some problem with initial > tests. This is not a problem. The GPS signal has much more jitter, but ntpd is using the precision of the PPS. >> >> That depends on what you are trying to use as a reference. I used gpsd as a >> driver for my Trimble Thunderbolt, until I wrote tboltd, a much simpler >> program, but added a few features I need. What is your reference clock? > > Can I use gpsd in between the rs-232 port and ntpd? You can if you want. You would then configure ntpd to use the shared memory driver rather than the NMEA driver. The only reason to do this is if you want to use some of the features of gpsd to share and monitor the gps information. It won't give you any more accuracy than the NMEA driver you are currently using. > I guess it would be possible to send requests for gps-info from another > computer to net4501? Exactly. > Any ideas of how to configure this? If you want to pursue this it's fairly straightforward. Ralph _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
