On Sun, 28 Dec 2008 09:45:18 -0500, "Richard B. Gilbert"
<rgilber...@comcast.net> wrote:
>George R. Kasica wrote:
>> On Sat, 27 Dec 2008 23:53:49 GMT, Unruh <unruh-s...@physics.ubc.ca>
>> wrote:
>>
>>> George R. Kasica <geor...@netwrx1.com> 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!
OK. Noted.
>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!
I was just going on what I had seen used elsewhere and ntp pool;
servers as suggested. Have modified accordingly to just use the GPS
locally, two local servers on the same net and 3 NTP us pool servers -
can't really control the locations of those though that I know of.
>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.
See below, now set up as recommended with three us.pool.ntp.org
servers but as you say it will take some time to be useful, but I
don't seem to be getting the NEMA data as of 1415Z 28-dec-2008.
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
GPS_NMEA(0) .GPS. 0 l 273 16 0 0.000 -664.93
0.002
xSHM(0) .PPS. 0 l 7 16 227 0.000 -634.51
349.893
eagle-local 192.168.1.7 4 u 11 64 37 0.120 -11.083
0.523
apollo-local 192.168.1.7 3 u 18 64 37 0.224 6.685
0.765
x64.247.17.251 129.6.15.28 2 u 12 64 37 34.158 -18.850
6.764
+ip-72-167-54-20 204.123.2.72 2 u 13 64 37 82.722 1.031
1.821
*caspak.cerias.p .GPS. 1 u 10 64 37 22.867 7.745
10.934
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
