On Sunday 28 February 2010 19.15.41 Ralph Smith wrote: > Summary is that you are in good shape. More comments below.
Fine :-) > > 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. I agree, no problem now when I see how it works. > > 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. The frequency offset is always the same, very stable. The offset is changing, but almost always within the 125 ns. This is probably where I expected to see a result to be more stable. But your explanation as well as the source code makes it quite clear what is possible to archive, problem is as usual to know where to find the details :-) > 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. Yes, I also have the TAPR Clock-block. I use http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm as source for 10MHz, PPS and GPS-data. > > 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. It's OK, I understand that it will not make the result better. But as long as it does not make it less accurate I am curios to give it a try. Can you give me some hints of how to do it? I guess I have to compile gpsd on the computer where I build the CF? But how do I make it appear in the nanobsd image? > Ralph /Göran _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
