[ntp:questions] Performance of the shared-memory reference clock
The shared-memory reference clock was modified (ntp-4.2.5p138) to collect data each second, rather than once per polling interval. What would be the impact of this modification on how accurately I can estimate the current time from a given GPS? If my system requirements specify that I have to use a version of NTP that predates this modification, can I attain the same accuracy from my GPS? Is the limitation that it will take me longer to synchronize to my GPS? Or does the increased polling interval prevent me from attaining the same degree of accuracy in my estimation of the current time? I do have both a pulse-per-second signal and a time-of-day message coming from my gps. The pulse-per-second will be designated as the prefer instance of the shared-memory reference clock. The time stamp for the pulse-per-second will not be passed to NTP until NTP has locked on to the time stamp coming from the time-of-day message. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
David J Taylor wrote: The reach = 0 suggests that the signals from the GPS are not being seen. I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings k...@sonic.net wrote in message news:4b8580e5$0$1616$742ec...@news.sonic.net... [] I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. -K Kelsey, at least you now have a reach of 377 for the GPS! The offset of -300ms suggests to me that you could be syncing on the wrong edge of the PPS signal. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
In article 4b8580e5$0$1616$742ec...@news.sonic.net, Kelsey Cummings k...@sonic.net writes: I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 The NMEA driver is a bit strange. It processes two sources of time. One is the text on the serial port. The other is the PPS signal. I think it has to get close enough on the text mode before the PPS processing kicks in. How about turning off the PPS fudge flag so you know you are using the text mode. Then watch it for a while and add a fudge time2 to get it reasonably close. When that works, turn the PPS back on. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: David J Taylor wrote: The reach = 0 suggests that the signals from the GPS are not being seen. I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. -K I'm guessing you aren't seeing pps. My notes from last year might have been understandable then but best I can decode from them now is: # ntp.conf gps-18x-LVC # gps0 - /dev/tty00 # pps0 - /dev/tty00 server 127.127.20.0 mode 1 prefer # NMEA $GPRMC That was giving offset of about 70us. No LED, just using pps direct to serial DCD. I'm still suspicious cmos ttl out from the 18x-LVC might not be good at driving rs232 as it requires at least 3mA/0.7V pulldown. ATOM driver and pps to serial DCD gave offset 10us Last check was with pps of my 18x-LVC direct to NACK of parallel port without any extra components. #ntp.conf # mknod pps0 164 0 /dev/pps0 tos mindist 0.4 # I could reduce this now server 127.127.20.0 mode 1 prefer fudge 127.127.20.0 time1 0.651 refid GPSb server 127.127.22.0 minpoll 4 maxpoll 6 fudge 127.127.22.0 refid PPSb flag3 1 server serv1 server serv2 server serv3 On a good day above cfg was giving offset = 0.000, jitter = 0.002. NMEA offset/jitter are then very erratic in order of 10s of ms. Note for above I needed fudge time1 and/or tos mindist otherwise NMEA was deselected. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Kelsey Cummings wrote: David J Taylor wrote: The reach = 0 suggests that the signals from the GPS are not being seen. I'm not sure why it lost sync but I went ahead and upgraded to 4.2.7p5 from the ntp-dev port. I'm still seeing high offset and variable jitter. == xGPS_NMEA(1) .GPS. 0 l 45 64 3770.000 -311.36 75.859 -time.sr207.200.81.. 2 u 348 512 3770.6430.977 2.984 *clock.sjc.he .CDMA. 1 u 362 512 3776.348 -2.584 0.289 Or: http://kgc.users.sonic.net/ntp_127_127_20_1-day.png The initial spike was the last restart. # Garmin GPS 18 LVC server 127.127.20.1mode 0 prefer fudge 127.127.20.1flag1 1 Does the GPS_NEMA driver actually make use of the PPS signal (currently wired to DCD on serial port) at all or does it just use the GPS sentences? I'm guessing you aren't seeing pps. My notes from last year might have been understandable then but best I can decode from them is # ntp.conf # gps0 - /dev/tty00 # pps0 - /dev/tty00 server 127.127.20.0 mode 1 prefer # NMEA $GPRMC That was giving offset of about 70us. ATOM driver and pps to serial DCD gave offset 10us I'm wired up following http://www.satsignal.eu/ntp/GPS-interface-2.png except that I used a NPN transistor to drive the PPS led so it wouldn't load the PPS signal. I'm not sure that's a good idea since rs232 is current driven/voltage triggered with a relative low input resistance depending on spec of interface. Having an LED+series resistor load might give a better pullup. Having said that, I can't remember what interface circuit if any I was using last year. Last check was with pps of my 18x-LVC direct to NACK of parallel port without any extra components. #ntp.conf # mknod pps0 164 0 /dev/pps0 tos mindist 0.4 # I could reduce this now server 127.127.20.0 mode 1 prefer fudge 127.127.20.0 time1 0.651 refid GPSb server 127.127.22.0 minpoll 4 maxpoll 6 fudge 127.127.22.0 refid PPSb flag3 1 server serv1 server serv2 server serv3 On a good day above cfg was giving offset = 0.000, jitter = 0.002. NMEA offset/jitter are then very erratic in order of 10s of ms. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS_NEMA, but high offset and jitter?
Hal Murray wrote: How about turning off the PPS fudge flag so you know you are using the text mode. Then watch it for a while and add a fudge time2 to get it reasonably close. When that works, turn the PPS back on. I added time2 to zero out the offset and things looked good for about an hour. Then the offset jumps 55ms and the GPS deselected. An updated graph http://kgc.users.sonic.net/ntp_127_127_20_1-day.png -K ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
