Am Mittwoch, den 01.06.2011, 16:35 +0000 schrieb Rob: > > I am trying since some time to attach a SkyTraq Based GPS receiver to a > > serial port + pps which "basically" works fine by using gpsd 2.92 and > > ntpd 4.2.4p8.
> > a) can I use PPS there without the PPSAPI? I do not really want to build > > a new kernel... having a short look it seems that there is no PPS > > support for the SHM interface (anymore?)? > > gpsd plus ntpd does not require any PPS support in the kernel. > there is no specfic PPS support via SHM but the gpsd just provides a > pretty accurate clock to ntpd. When your system is not overloaded > (CPU loading always around or over 1.00) there should be no problem > with sync Overload is not the case. After what you wrote, I had a short look at the gpsd ntpshm code and saw, that the pps shm part also inserts the gps time from the gps, so: why do I need the gps part of the shm at all? > > b) could somebody hint me to a working ntp.conf for nmea gps + pps and > > no external ntp servers? > > # SHM clock, requires running gpsd > server 127.127.28.0 minpoll 4 > fudge 127.127.28.0 refid GPS > > server 127.127.28.1 minpoll 4 prefer > fudge 127.127.28.1 refid PPS this does not really work for me and leads to time resets every few days... my unlucky guess is, that this is more related to gpsd than to ntp. What confuses me is the following behaviour with only server 127.127.28.1 minpoll 4 maxpoll 4 prefer fudge 127.127.28.1 refid PPS from syslog: Jun 5 03:10:46 na-stephan ntpd[8583]: no servers reachable Jun 5 03:11:02 na-stephan ntpd[8583]: synchronized to SHM(1), stratum 0 Jun 5 03:11:19 na-stephan ntpd[8583]: time reset -0.999972 s Jun 5 03:12:29 na-stephan ntpd[8583]: synchronized to SHM(1), stratum 0 from while true ; do echo `date +%Y%m%d-%H%M%S: ` `ntpq -p | tail -1` >> ntpq_20110601.txt ; sleep 10 ; done (in the time around the above...) 20110605-031017: *SHM(1) .PPS. 0 l 3 16 377 0.000 -999.97 0.013 20110605-031027: *SHM(1) .PPS. 0 l 13 16 377 0.000 -999.97 0.013 20110605-031037: *SHM(1) .PPS. 0 l 8 16 377 0.000 -999.95 0.022 20110605-031047: SHM(1) .PPS. 0 l 1 16 377 0.000 0.036 1000.00 20110605-031057: SHM(1) .PPS. 0 l 11 16 377 0.000 0.036 1000.00 20110605-031107: *SHM(1) .PPS. 0 l 5 16 377 0.000 -999.97 377.967 20110605-031117: *SHM(1) .PPS. 0 l 15 16 377 0.000 -999.97 377.967 20110605-031126: SHM(1) .PPS. 0 l 7 16 0 0.000 0.000 0.001 20110605-031136: SHM(1) .PPS. 0 l 1 16 1 0.000 0.027 0.001 20110605-031146: SHM(1) .PPS. 0 l 11 16 1 0.000 0.027 0.001 20110605-031156: SHM(1) .PPS. 0 l 3 16 3 0.000 0.033 0.006 20110605-031206: SHM(1) .PPS. 0 l 13 16 3 0.000 0.033 0.006 20110605-031216: SHM(1) .PPS. 0 l 5 16 7 0.000 0.032 0.004 20110605-031226: SHM(1) .PPS. 0 l 15 16 7 0.000 0.032 0.004 20110605-031236: *SHM(1) .PPS. 0 l 7 16 17 0.000 0.022 0.009 20110605-031246: *SHM(1) .PPS. 0 l - 16 37 0.000 -0.005 0.034 20110605-031256: *SHM(1) .PPS. 0 l 10 16 37 0.000 -0.005 0.034 20110605-031306: *SHM(1) .PPS. 0 l 5 16 77 0.000 0.011 0.018 strange.. I think I have to find out, what makes gpsd "flipping over"... it does not happen often... sometimes after days... _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
