George R. Kasica wrote: > On Sat, 27 Dec 2008 23:53:49 GMT, Unruh <[email protected]> > wrote: > >> George R. Kasica <[email protected]> writes: >> >>>>>>> sym links from >>>>>>> /dev/gps0 -> /dev/ttyS0 >>>>>>> /dev/pps0 -> /dev/ttyS0 >>>>>>> running the gpsd and the 18LVC off ttyS0 at 4800 baud settings on >>>>>>> 18LVC done as per quan web page docs to set NEMA and PPS auto Off etc. >>>>>>> setserial /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 >>>>>>> spd_normal skip_test low_latency >>>>>>> /usr/sbin/gpsd -b -n /dev/ttyS0 >>>>>>> ./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c >>>> Ah, you are NOT running the kernel PPS. You are running the shm refclock >>>> using the timing of the serial port driver. >>> Correct. Getting the pps patch to work here with the rpm based kernels >>> for Fedora Core 9 has proven to be problematic. Has anyone got any >>> pointers or managed to get this working? >> Why do it? There is nothing wrong with the shm driver. It will discipline >> the clock as well as (better than?) the kernel patch. > OK. That is the type of experience information I need to know. I have > no idea what is good or bad here with this device. Thank you. > >>>>>>> my ntpd.conf looks like: >>>>>>> server 127.127.28.0 minpoll 4 prefer >>>>>>> fudge 127.127.28.0 refid PPS flag3 1 >>>> That is solely the shm refclock driver which is coming off your serial port >>>> interrupt. You do not have the serial nmea data coming in at all to your >>>> system it looks to me. >>> If I switch to the following settings I can seem to get NEMA data but >>> then I lose the PPS function which hurts the accuracy far more. Do you >>> know if shm can somehow allow both with some type of setting - ideally >>> that is what I'm trying to accomplish through the shm driver or >>> something else without hacking the kernel, etc?? >> Have both!. Nothing says you need to use only one or the other. Use the >> shm pps as the preferred but the nmea to get the seconds right. >> The pool servers are then simply as a backup. >> Ie also use 127.127.28.0 as a server. >> >> >>> server 127.127.20.0 minpoll 4 prefer >>> fudge 127.127.20.0 flag3 1 flag2 0 > OK. I've added back the GPS NEMA lines as well as the PPS lines and > thing seem to be working here. Will see how it goes over the next day > or so. This is exactly what I was looking to try to do. > > Again, thank you very much. > > Right now ntpq looks like this (after just a few min restarted @ 1200Z > 12/28/08) I'm assuming things will settle back down over time and I > will once again start to use the local time sources instead of marking > them as false tickers?: > > # ntpq -p > remote refid st t when poll reach delay offset > jitter > ============================================================================== > xGPS_NMEA(0) .GPS. 0 l 16 16 377 0.000 12.677 > 5.862 > xSHM(0) .PPS. 0 l 12 16 377 0.000 8.410 > 93.475 > -eagle-local 192.43.244.18 2 u 99 128 37 0.166 724.868 > 0.714 > -apollo-local 128.233.154.245 2 u 98 128 37 0.215 706.214 > 0.787 > mumnunah.csse.u .INIT. 16 u - 64 0 0.000 0.000 > 0.000 > +tick.usask.ca .GPS. 1 u 97 128 37 105.157 702.859 > 0.756 > *clock.isc.org .GPS. 1 u 95 128 37 63.669 702.671 > 3.087 > -time.nist.gov .ACTS. 1 u 94 128 37 72.814 691.122 > 24.052 > -server.donkeyfl 18.26.4.105 2 u 93 128 37 30.919 706.994 > 22.203 > +ip-72-167-54-20 164.67.62.194 2 u 93 128 37 83.165 702.973 > 137.172 > -ns1.bluebottle. 64.202.112.75 2 u 88 128 37 25.726 712.661 > 3.246
An ntpq "banner" is not much use until at least thirty minutes have elapsed since startup! I question the selection of servers! Round trip delays of 63, 72, 83, and 105 milliseconds seem unreasonable to me! The uncertainty in the time reported by a server may be as great as one half of the round trip delay. This suggests that you should strive to have the lowest possible round trip delays. If the nearest servers are 1000 miles, or more, away from your site, there's not much you can do but not many places are that far away from any NTP server. Note that "network distance" rather than physical distance is what counts here; e.g. if you are in New York, a server in New Jersey that can only be reached by relaying through Los Angeles is, effectively 3000 miles away! The use of ten servers also seems a little extreme. Four, five, and seven are the magic numbers that protect you from the failure of one, two, or three servers; e.g. given seven servers, of which three are "bad" (wrong time or not responding) the remaining four are sufficient to "outvote" the bad servers. Since you have a GPS receiver, three internet servers should be sufficient as backup and a sanity check for the GPS. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
