Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On Thu, Nov 3, 2016 at 11:59 PM, Brian Inglis < brian.ing...@systematicsw.ab.ca> wrote: > > The JLT Fury emulates the HP/Symmetricom/Agilent/Keysight 58503 which is a > newer variant of the venerable HP38xx GPS-DOs, > Sure but this is tne NTP list and if you have a Fury you should use NMEA. The driver is robust and it works with any minimally capable NMEA-like input. This is important because many (most) of the standard drivers are old, cranky and unmaintained. (E.g. the TSIP driver doesn't work on new products, not only that but there's a subtle bug with older products like the Thunderbolt). > Single message output may be required for NMEA PPS handling to work, and > why it > did not work with your Fury or uBlox. > That's a reason to use ATOM+NMEA not a reason to fiddle the NMEA output. > IRC early Fury models > We're drifting here but I didn't see any significant difference in jitter after upgrading the GPS module in my Fury. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On 2016-11-03 19:27, Paul wrote: On Thu, Nov 3, 2016 at 2:27 PM, Brian Inglis wrote: What do your refclock ntp.conf lines look like? I'm not sure why you're asking but: For the reference and edification of the OP. # PPS (ATOM) server 127.127.22.0 minpoll 3 fudge 127.127.22.0 refid GPPS # NMEA @19200 server 127.127.20.0 minpoll 3 mode 65570 prefer fudge 127.127.20.0 time2 0.039 refid FURY To be fair, I should include mine: # NMEA driver #server 127.127.20.?mode 0=all 1=$GPRMC 2=$GPGGA 4=$GPGLL 8=$GPZDA|$GPZDG 256=$PGRMF #server 127.127.20.?mode 0=4800 16=9600 32=19200 48=38400 64=57600 80=115200 bps #server 127.127.20.?mode 128=sub-second receive clockstat 65536=extra clockstats #fudge 127.127.20.?flag1 pps flag2 fall flag3 kern flag4 noll time1 pps-delay time2 \n-offset # RPi, GT MKT 3339, kernel PPS server 127.127.20.0prefer minpoll 4 maxpoll 4 mode 17 # mode 17 == $GPRMC 9600bps fudge 127.127.20.0flag1 1 flag3 1 time2 0.500 # pps kernel \n-offset #fudge 127.127.20.?3339 pps-delay m*cableE-9+receiverE-9s \n-offset 650/9600s=68ms # W10, Garmin 18x LVC, user mode PPS server 127.127.20.2prefer minpoll 4 maxpoll 4 mode 17 # mode 17 == $GPRMC 9600bps fudge 127.127.20.2flag1 1 time2 0.500 # pps \n-offset #fudge 127.127.20.?18x pps-delay 5*18.2E-9+122.2E-9s=213.2ns \n-offset 680/9600s=71ms Also please see driver comments in [time-nuts] NTP refclock JLT Fury: Using the NMEA (like) output is sufficient to number the seconds -- using an HP SCPI driver is an odd choice for non-HP gear. The JLT Fury emulates the HP/Symmetricom/Agilent/Keysight 58503 which is a newer variant of the venerable HP38xx GPS-DOs, and works with compatible software like HP SatStat, Ulrich Bangert's Z38xx, Graham Baxter's GPScon, etc. which can provide functions and displays similar to those provided graphically in Marks Sims' Lady Heather for Trimble Thunderbolt compatibles, if you are more familiar with those than HP or Motorola series. NMEA output is just one command which produces both $GPRMC and $GPGGA messages, with no other selection available, at any requested interval on the serial port. For decent results you also have to switch off output of other messages. That's not my ublox experience although I did arrange that all the output per tick happened in less than a second. Single message output may be required for NMEA PPS handling to work, and why it did not work with your Fury or uBlox. IIRC early Fury models use the Motorola Oncore compatible M12+ timing GPS, and later models use the Motorola/iLotus M12M, compatible with the M12+. JLTs own latest M12M compatible uses the uBlox M8T, so the LEA-6T performance can be on par with the Fury, but the latter uses the available Motorola TRAIM to do PPS sawtooth correction in its uC, and I don't believe that is available for any NTP driver, nor kernel PPS, either as patches or via config parameters. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On Thu, Nov 3, 2016 at 2:27 PM, Brian Inglis < brian.ing...@systematicsw.ab.ca> wrote: > > What do your refclock ntp.conf lines look like? > I'm not sure why you're asking but: # PPS (ATOM) server 127.127.22.0 minpoll 3 fudge 127.127.22.0 refid GPPS # NMEA @19200 server 127.127.20.0 minpoll 3 mode 65570 prefer fudge 127.127.20.0 time2 0.039 refid FURY > Also please see driver comments in [time-nuts] NTP refclock JLT Fury: > Using the NMEA (like) output is sufficient to number the seconds -- using an HP SCPI driver is an odd choice for non-HP gear. > For decent results you also have to switch off output of other messages. > That's not my ublox experience although I did arrange that all the output per tick happened in less than a second. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On 2016-11-03 08:45, ogre up wrote: On Thu, Nov 3, 2016 at 3:03 PM, Brian Inglis wrote: On 2016-11-02 17:51, Paul wrote: On Sun, Oct 30, 2016 at 1:29 PM, ogre up wrote: Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have strange offset value reported by ntpq -p. Your billboard is fine. If you want less jitter in your NMEA sentences you need to buy better hardware. Not necessarily more expensive but better. However it doesn't matter as long as you stay within a few hundred milliseconds of the correct second since the timing is done with PPS and the GPS output is only used to number the seconds. Unfortunately I have no experience with your PPS problem. I prefer using ATOM (PPS) + a GPS specific driver. In the past I've been unhappy using the PPS option in the NMEA driver so I don't bother. Output from a low jitter NMEA compatible GPSDO: remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l28 3770.0000.000 0.002 *127.127.20.0.FURY. 0 l18 3770.000 -0.003 0.011 What do your refclock ntp.conf lines look like? Also please see driver comments in [time-nuts] NTP refclock JLT Fury: https://www.febo.com/pipermail/time-nuts/2013-October/080889.html The uBlox LEA-6T is probably as good as the older M12+ used in the JLT Fury, and has been used for DIY GPS-DOs. With proper GPS antenna, receiver, and system configuration, the results achievable should be comparable, limited by system and NTP performance, compared to the standalone Fury GPS-DO [TO]CXO which will not be affected by temperature. Follow the instructions for timing setup on a uBlox LEA-6T to get the best results; see sections 10 Time Mode Configuration and 11 Timepulse in: https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf#page=37&zoom=auto,0,323.15 You may want to do the setup in uBlox mode at higher speed, especially if you load ALP data from Ublox, before switching to 9600 bps and NMEA output. Once the setup is done properly, it would be worth comparing the performance using the NMEA driver with kernel PPS against the separate PPS/ATOM driver. I just noticed I've made a mistake. My original ntp.conf looks like this: # use GPRMC sentence only server 127.127.20.0 mode 1 minpoll 3 maxpoll 4 iburst prefer fudge 127.127.20.0 fudge flag1 0 time2 0.213 server 127.127.22.0 fudge 127.127.22.0 fudge flag2 1 flag3 1 tos mindist 0.10 # required, or both peer will be falseticker There is an unnecessary "fudge" after .20.0, and .22.0, so options after may not take effect. I will have a try with correct config file and see what happens. In the world of software, nothing is strange; If you do find one, chances are you've make some stupid mistake... For decent results you also have to switch off output of other messages. If you think you have to set tos parameters (dist default range 0.001-1.5s) you need to check your setup, read up the theory behind the parameter setting, do some calculations, then test. With patch antennae, indoors, north-ish window, floor heating vent below, non-timing serial GPS+PPS, I get: * RPi, GT MKT 3339, kernel PPS, NMEA only: remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l 10 16 3770.0000.002 0.001 +W10 .GPS.1 s 16 16 3761.2790.283 83.321 * W10, Garmin 18x, user mode PPS, NMEA only: remote refid st t when poll reach delay offset jitter == *GPS_NMEA(2) .GPS.0 l 10 16 3770.000 -0.006 0.006 -RPi .GPS.1 s4 16 3771.181 -0.236 70.814 [peer jitter due to USB 11N low band wifi - should get a long enet cable sometime to reduce LAN peers' and WAN backups' delay and jitter] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On 2016-11-02 17:51, Paul wrote: On Sun, Oct 30, 2016 at 1:29 PM, ogre up wrote: Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have strange offset value reported by ntpq -p. Your billboard is fine. If you want less jitter in your NMEA sentences you need to buy better hardware. Not necessarily more expensive but better. However it doesn't matter as long as you stay within a few hundred milliseconds of the correct second since the timing is done with PPS and the GPS output is only used to number the seconds. Unfortunately I have no experience with your PPS problem. I prefer using ATOM (PPS) + a GPS specific driver. In the past I've been unhappy using the PPS option in the NMEA driver so I don't bother. Output from a low jitter NMEA compatible GPSDO: remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l28 3770.0000.000 0.002 *127.127.20.0.FURY. 0 l18 3770.000 -0.003 0.011 The uBlox LEA-6T is probably as good as the older M12+ used in the JLT Fury, and has been used for DIY GPS-DOs. With proper GPS antenna, receiver, and system configuration, the results achievable should be comparable, limited by system and NTP performance, compared to the standalone Fury GPS-DO [TO]CXO which will not be affected by temperature. Follow the instructions for timing setup on a uBlox LEA-6T to get the best results; see sections 10 Time Mode Configuration and 11 Timepulse in: https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf#page=37&zoom=auto,0,323.15 You may want to do the setup in uBlox mode at higher speed, especially if you load ALP data from Ublox, before switching to 9600 bps and NMEA output. Once the setup is done properly, it would be worth comparing the performance using the NMEA driver with kernel PPS against the separate PPS/ATOM driver. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On Sun, Oct 30, 2016 at 1:29 PM, ogre up wrote: > Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have > strange offset value reported by ntpq -p. > Your billboard is fine. If you want less jitter in your NMEA sentences you need to buy better hardware. Not necessarily more expensive but better. However it doesn't matter as long as you stay within a few hundred milliseconds of the correct second since the timing is done with PPS and the GPS output is only used to number the seconds. Unfortunately I have no experience with your PPS problem. I prefer using ATOM (PPS) + a GPS specific driver. In the past I've been unhappy using the PPS option in the NMEA driver so I don't bother. Output from a low jitter NMEA compatible GPSDO: remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l28 3770.0000.000 0.002 *127.127.20.0.FURY. 0 l18 3770.000 -0.003 0.011 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On 2016-11-02 10:16, ogre up wrote: The GPS module in use is an ublox LEA-6T, not Garmin GPS 18x, sorry for the mistake. The NTP server runs in an isolated network, GPS is the only time source I can refer to, and 1 millisecond accuracy is good enough for me. Reliable, trustworthy means more to me than performance. So if signal delay measured by oscilloscope and offset reported by ntpq can conform each other, it will bring me great confidence to rely on the server. I upload oscilloscope screenshot at https://cdn.pbrd.co/images/mqRtAxzXq.png, delay between "end of $GPRMC" and "preceding PPS edge" is about 213 ms. I've tested with ntp.conf: server 127.127.20.0 mode 1 minpoll 3 maxpoll 4 iburst prefer fudge 127.127.20.0 flag1 0 server 127.127.22.0 minpoll 3 maxpoll 4 noselect fudge 127.127.22.0 flag2 1 flag3 1 tos mindist 0.05 However, no matter what the value for .22.0 flag2 is (1 or 0), when NTP synchronized to .20.0, offset value of .22.0 is always about 116. Where is this 116 ms come from? It looks like it may be the time from the PPS trailing edge to the \n. As I advised earlier, get the PPS test working normally, then set .22.0 to flag2 0, as you can not control Linux PPS using the leading edge, and switch off the GPS receiver output of the other message, as more than a single message will not be handled well by the NMEA driver. The PPS driver was designed for use with standalone high accuracy PPS sources. Better just use NMEA driver with kernel PPS to achieve accuracy and reliability: PPS was added to the driver to improve handling using the same port, because results using the separate PPS driver were worse. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On 2016-10-31 20:46, ogre up wrote: Brian, thanks for your quick response. On Tue, Nov 1, 2016 at 4:03 AM, Brian Inglis mailto:brian.ing...@systematicsw.ab.ca>> wrote: Presuming a Garmin 18LVC wired to power and a serial port as you have PPS, you get better results using the built-in NMEA PPS support as follows: symlink /dev/pps0 as /dev/gpspps0, possibly using udev if used by CentOS, set NMEA flag1 1 flag3 1, and drop PPS driver .22.0; ... I've measured the delay between "end of $GPRMC sentence" and PPS signal by an oscilloscope (which is about 213 ms), so I intentionally disabled built-in NMEA PPS support and add ATOM driver, expecting NTP would produce same offset value. Since "end of $GPRMC" is 213 ms behind, offset of .20.0 should be +213. You need to measure the time between PPS trigger and end of line character \n, as messages are assumed to relate to the preceding PPS, so you may need to use 787ms. You also need to compensate for serial interrupt, character, and message processing delays, which is why the recommendation is to let the NMEA driver do this by handling the PPS processing internally. - output only $GPRMC as others slow down the Garmin and prevent proper PPS handling in the NMEA driver; - reduce PPS length to minimum (20ms?); - set speed to 9600bps, to reduce I/O and offset time; set corresponding mode 17, and set time2 to 0.500 - as long as it is large enough to account for the Garmin message output delay 400ms+ NMEA will use the PPS timestamp instead of the end of line character time. If you want to set an accurate time2, start with it at 0, run it for a day, average the peerstats offset, try that value, and see if it helps or not. I will try these later. I'm confused by the output of ppstest (some digits ommited to make line shorter): $ sudo ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 59.97, sequence: 31814 - clear 60.899947, sequence: 330 source 0 - assert 60.80, sequence: 31815 - clear 60.899947, sequence: 330 source 0 - assert 60.80, sequence: 31815 - clear 61.899953, sequence: 331 source 0 - assert 61.999888, sequence: 31816 - clear 61.899953, sequence: 331 source 0 - assert 61.999888, sequence: 31816 - clear 62.899951, sequence: 332 GPS receivers cold start running on internal time until they receive enough almanac and ephemeris data to calculate a position/time solution. Older units like Garmin may output a free running PPS before they have a valid solution. Give them 15 minutes to warm up and receive all the data before starting tests. If they have been on for some time, check the PPS settings on the device and reset them appropriately if wrong. With your scope, you can check your GPS output and RS232 input levels. If your GPS power is too high or low or your interface impedance is outside specs, your signals may be outside spec for your RS232 inputs, which may be only 0-5V or lower these days with TIA-232-F. Your interface could also have contact or wiring issues. $ ntpq -pn remote refid st t when poll reach delay offset jitter === *127.127.20.0.GPS.0 l18 3770.000 -115.02 1.120 o127.127.22.0.PPS.0 l 56 64 3770.0000.040 0.020 As I've specified "fudge flag2 1" option for ATOM driver to use the falling edge of PPS, when clock is synchronized to .22.0, fraction of time stamp for clear event should be nearly zero. In my case the fraction is about 0.9. It doesn't make sense. Messages will be output when channel processing allows so suffer variable delay and jitter - NMEA PPS processing substitutes the PPS time for the end of line time when only a single message is output per second. If you can set your scope to trigger on DCD leading edge start, or a higher quality PPS source, and sweep to a bit more than the nominal pulse duration, you should be able to see the differences between pulse durations and rise and fall times. For more good advice on Garmin issues see: https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks#Section_6.1.12.2. Leading edge is synced to the UTC (or initially GPS) second with a sharp rise time; pulse duration, especially on Garmins, will be some approximation to that requested, probably performed at a lower scheduling priority, making the duration less accurate; the trailing edge usually has somewhat longer fall time adding more variance to the transition time. The RS-232 signal specs say: * For control signals, the transit time through the transition region should be less than 1ms. * For data and timing signals, the transit time through the transition region should be: - less than 1ms for bit periods greater than 25ms, - 4% of the bit period for bit periods between 25ms and 125µs, - less th
Re: [ntp:questions] Help: fudge time2 value for NMEA driver
On 2016-10-30 11:29, ogre up wrote: Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have strange offset value reported by ntpq -p. Some basic infomation about my setup: OS: CentOS 6.5 + 2.6.34.10 kernel (compiled with pps support) NTP: 4.2.8@p8 (with NEMA and ATOM clock driver enabled) Time ref: Garmin gps 18 (outputs GPRMC + GPGGA @ 4800bps) signal of pps and NMEA data from gps module capture by an osc looks like this: [see osc.jpg in attachments] /etc/ntp.conf: # use GPRMC sentence only server 127.127.20.0 mode 1 minpoll 3 maxpoll 4 iburst prefer fudge 127.127.20.0 fudge flag1 0 time2 0.213 server 127.127.22.0 fudge 127.127.22.0 fudge flag2 1 flag3 1 tos mindist 0.10 # required, or both peer will be falseticker "time2 0.216" calculated as follows: pps pulse width is set to 100ms, so the leading edge marks the valid second. GPRMC (69 bytes) came before GPGGA (80 bytes) in NMEA data burst, so time span from pps to end of GPRMC = 380 - (1/4800 * 10 * 1000 * 80) = 213 ms. However, output of ntpq -pn shows 127.127.20.0 still got a large offset value: remote refid st t when poll reach delay offsetjitter == *127.127.20.0.GPS.0 l18 3770.000 -115.021.120 o127.127.22.0.PPS.0 l 56 64 3770.0000.0400.020 Are these normal? Should I use "fudge flag 2" for 127.20.22.0? Sorry for my English and any suggestion will be appreciated. Presuming a Garmin 18LVC wired to power and a serial port as you have PPS, you get better results using the built-in NMEA PPS support as follows: symlink /dev/pps0 as /dev/gpspps0, possibly using udev if used by CentOS, set NMEA flag1 1 flag3 1, and drop PPS driver .22.0; add a startup script to send Garmin startup commands to: - output only $GPRMC as others slow down the Garmin and prevent proper PPS handling in the NMEA driver; - reduce PPS length to minimum (20ms?); - set speed to 9600bps, to reduce I/O and offset time; set corresponding mode 17, and set time2 to 0.500 - as long as it is large enough to account for the Garmin message output delay 400ms+ NMEA will use the PPS timestamp instead of the end of line character time. If you want to set an accurate time2, start with it at 0, run it for a day, average the peerstats offset, try that value, and see if it helps or not. Consistency can be improved by setting your system to always run at its maximum standard clock speed without any boosts or power saving features in a start up script; start ntpd with high realtime CPU and I/O priorities; and pin ntpd to your highest numbered processor, in the ntp startup script e.g. set max value from: /sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_available_frequencies in both: /sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_min_freq /sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_max_freq and the appropriate entry from: /sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_available_governors normally performance into: /sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_governor set ntpd priorities and affinity: start-stop-daemon --procsched rr:20 --iosched real-time:4 ... taskset -apc $CPU $PID It also helps to speed up acquisition and timing output if you can preload your position estimate, and latest almanac, ephemeris, or Extended Prediction Orbit data downloads to the Garmin in your GPS setup startup script, although there is some support for some modules via interactive Garmin Windows programs, info on this is sparse, although widely supported and documented for all other commercial, and even many cheap Asian modules. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Help: fudge time2 value for NMEA driver
Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have strange offset value reported by ntpq -p. Some basic infomation about my setup: OS: CentOS 6.5 + 2.6.34.10 kernel (compiled with pps support) NTP: 4.2.8@p8 (with NEMA and ATOM clock driver enabled) Time ref: Garmin gps 18 (outputs GPRMC + GPGGA @ 4800bps) signal of pps and NMEA data from gps module capture by an osc looks like this: [see osc.jpg in attachments] /etc/ntp.conf: # use GPRMC sentence only server 127.127.20.0 mode 1 minpoll 3 maxpoll 4 iburst prefer fudge 127.127.20.0 fudge flag1 0 time2 0.213 server 127.127.22.0 fudge 127.127.22.0 fudge flag2 1 flag3 1 tos mindist 0.10 # required, or both peer will be falseticker "time2 0.216" calculated as follows: pps pulse width is set to 100ms, so the leading edge marks the valid second. GPRMC (69 bytes) came before GPGGA (80 bytes) in NMEA data burst, so time span from pps to end of GPRMC = 380 - (1/4800 * 10 * 1000 * 80) = 213 ms. However, output of ntpq -pn shows 127.127.20.0 still got a large offset value: remote refid st t when poll reach delay offset jitter == *127.127.20.0.GPS.0 l18 3770.000 -115.02 1.120 o127.127.22.0.PPS.0 l 56 64 3770.0000.040 0.020 Besides, ppstest command does not always got same output: $ sudo ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1477817715.52604, sequence: 31470 - clear 1477781599.834058655, sequence: 24 source 0 - assert 1477817716.74467, sequence: 31471 - clear 1477781599.834058655, sequence: 24 source 0 - assert 1477817717.58504, sequence: 31472 - clear 1477781599.834058655, sequence: 24 source 0 - assert 1477817718.81812, sequence: 31473 - clear 1477781599.834058655, sequence: 24 $ sudo ppswatch /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" timestamp: 1477817756, sequence: 25, offset: -100040731 timestamp: 1477817756, sequence: 25, offset: -100040731 timestamp: 1477817757, sequence: 26, offset: -100039236 timestamp: 1477817757, sequence: 26, offset: -100039236 timestamp: 1477817758, sequence: 27, offset: -100039364 timestamp: 1477817758, sequence: 27, offset: -100039364 $ sudo ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1477818059.97871, sequence: 31814 - clear 1477818060.899947568, sequence: 330 source 0 - assert 1477818060.80293, sequence: 31815 - clear 1477818060.899947568, sequence: 330 source 0 - assert 1477818060.80293, sequence: 31815 - clear 1477818061.899953546, sequence: 331 source 0 - assert 1477818061.999888506, sequence: 31816 - clear 1477818061.899953546, sequence: 331 source 0 - assert 1477818061.999888506, sequence: 31816 - clear 1477818062.899951101, sequence: 332 source 0 - assert 1477818062.54442, sequence: 31817 - clear 1477818062.899951101, sequence: 332 Are these normal? Should I use "fudge flag 2" for 127.20.22.0? Sorry for my English and any suggestion will be appreciated. Paul Best Regards ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
