On Saturday 27 October 2007, Dennis Hilberg, Jr. wrote: > Chuck wrote: > > hmm... this is what i have so far from messing around. this keeps the offset > > for the gps clock in reasonable range or else it is skewed off by 230ms or so > > and there is always an X by it. i suppose it doesnt matter since the pulse > > (gps1) is always * and is usually within 100 us at worst, 5us at best. > > > > there seems to be a considerable change from poll to poll. it never settles > > down into a nice small range hardly varying as i expected it to do. > > > > server 127.127.28.0 minpoll 4 maxpoll 4 > > fudge 127.127.28.0 time1 -0.200 refid GPS > > > > server 127.127.28.1 minpoll 4 maxpoll 4 prefer > > fudge 127.127.28.1 refid GPS1 > > > > > >> -- > >> Simon Arlott > > I had a similar discussion on the list recently about the GPS 18 LVC. Here > is what Rob Janssen had to say about gpsd: > > Rob wrote: > > The message-based time (SHM(0)) is very inaccurate because of > deficiencies > in most GPS receivers and their comms protocols. It is > completely unclear > what time the timestamp in the message refers to, and > usually it jitters > > wildly. > > The PPS output pulse is accurate, and the message-based time is only > > required to bring the local clock well within one second, at which time > > the PPS should take over. > > Indeed, the whole operation is much more reliable when you have a couple > > of references for NTP to choose from. > > I have a GPS 18 LVC on Linux, and use the PPS output only, via the shmpps > driver from http://time.qnan.org/#driver-shm . When I tried gpsd, it > introduced a few more us in the jitter and noise variables, and the offset > was less consistent than with shmpps. With shmpps, I routinely show 1us > noise and jitter, and +-4us offset. >
i cant use that driver. it requires kernel pps patch which i do not have installed. in my initial searches they appeared to have stopped supporting the patch. however, just as i was writing this, i looked at one more reference which gave me a link to a site that has current patches so i am going to be a bit busy setting up a pps kernel which i understand is the best way to go. > Not that it really matters anyway, as serving time over Ethernet degrades > accuracy to the low millisecond range. > > Also, since I was going to have a few internet servers in my ntp.conf for > sanity checks anyway, it really defeated the purpose of getting time from a > local refclock. Might as well get the time from the internet servers and > get rid of the ugly GPS time. > > -- > Dennis Hilberg, Jr. [EMAIL PROTECTED] > NTP Server Information: http://saturn.dennishilberg.com/ntp.php > _______________________________________________ > timekeepers mailing list > [email protected] > https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers > -- Chuck "...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. " The Book of John, chapter 1, page 1, and end of book _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
