David:
Thanks. I might give that a shot. Right now, I've gone back into
the ntp.conf file and and tweaked the time1 setting to 0.850 and
its helped, but its no panacea.
And so far, hunting down an 18 LVC isn't yielding results. It doesn't
look like any vendors have 18's anymore, just 18x's. Blah... :)
remote refid st t when poll reach delay offset
jitter
==============================================================================
+time.nist.gov .ACTS. 1 u 51 64 17 57.335 -2.060
1.657
+ntp-nasa.arc.na .GPS. 1 u 50 64 17 92.223 4.510
0.984
+tick.usask.ca .GPS. 1 u 49 64 17 89.631 3.269
5.160
*ntp.alaska.edu .GPS. 1 u 48 64 17 137.186 6.185
2.837
+timekeeper.isi. .GPS. 1 u 44 64 17 91.553 -0.758
9.976
+ntp2.usno.navy. .USNO. 1 u 42 64 17 67.288 -5.225
4.873
+SHM(0) .GPS. 0 l - 16 377 0.000 1.698
26.364
SHM(1) .PPS. 0 l - 16 0 0.000 0.000
0.001
On Mon, February 28, 2011 4:25 pm, David J Taylor wrote:
> What I have done on the affected server is to use just the PPS signal
> from the GPS 18x LVC, and rely on other sources for getting to the nearest
> second. The other sources include two different GPS pucks. See:
>
> http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x
>
>
> Otherwise, you might want to revert the firmware to 3.20. Look for:
>
>
> GPS18xPC_LVC_320.exe
> at:
> http://www.gawisp.com/perry/oem_sensor/
>
>
> Cheers,
> David
>
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
