Am Dienstag, den 07.06.2011, 20:24 +0000 schrieb Rob: > >> > >> 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? > > I think you mean "the pps part..."
No, I meant the gps part... as I looked into the code of gpsd my vague understanding is, that it takes gettimeofday, when a pps arrives, but then does some magic with the gps serial input (in ntpshm.c). I do not really understand, why this is necessary, as I would also like to use this as a pps only solution, where I get a pps from an external source without any gps (and therefore no time from gps). But I will ask this on the gpsd mailing list. > > > > 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 > > This is a bit worrying. It can be that gpsd has guessed the wrong > time to relate to the PPS pulse. > You have to know that the SHM interface cannot transfer raw PPS info. > It can only transfer absolute time, which PPS does not deliver. > Therefore gpsd uses a trick: when a PPS pulse arrives, it checks if > the system clock is close to the seconds mark, and if so it sends > the absolute time of the closest second. When the system clock is far > away from correct time, it could guess the wrong second. > > When I wrote that code, I set a maximum clock error of 400ms before > the PPS SHM interface is "enabled". As long as the clock is outside > that margin, the PPS simply is dead and the GPS SHM interface (SHM(0)) > first has to "pull" the system within that margin. This functionality I have seen in libgps-core... and I guessed it was you reading your name in it :-) > You could try raising the issue on the gpsd developer mailing list, > they are quite active. I will do so. First I have to build an actual version and use that for testing, I guess ;-) Thanks for your great help! BR Steve _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
