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
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.
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.
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.
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.
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.
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
