[ntp:questions] serialPPS+gpsd+ntpd large offset & jitter

M Z mcrunch2 at yahoo.com
Sat Oct 16 15:24:02 UTC 2010


I have since run ntp on 2 other similar systems, with and without the gps. It 
seems that the problem is not with the gps but with ntp as there is always a 
large offset and jitter. I have tried some things from the ntp.org problems page 
such as setting HZ=100, setting clocksource to tsc, hpet, and  acpi_pm. I do not 
know what to do with acpi so i didn't test that. one of my systems has drift of 
< +-10 which is good. one of the systems is not behind my firewall.
I have snipped all gps info out below as i only want to know what to do with ntp 
now.

Another machine (no 'prefer' used for any server) looks like this (pretty much 
the same without the gps also):

ntpq -p
     remote           refid               st t when poll reach   delay   offset  
 jitter
==============================================================================
xSHM(0)          .GPS.                 0 l   11   16  377    0.000  708.561  
81.946
*SHM(1)          .PPS.                  0 l    -     16  377    0.000   50.438   
7.412
-131.107.13.100  .ACTS.              1 u   40   64  375   55.163   93.635  
28.647
+saturn.netwrx1. .PPS.                1 u   60   64  377   60.648   85.418  
42.763
+tick.usask.ca   .GPS.                1 u    9   64  377   81.602   78.736  
18.084
-ds3-us.zagbot.c 204.9.54.119     2 u   19   64  377   38.948   59.947  31.416
-dione.cbane.org 66.220.9.122     2 u   54   64  377   49.886   55.340  27.939
-montblanc.arbor 208.66.175.36    2 u   21   64  377   34.546  102.890  27.588




----- Original Message ----
From: "questions-request at lists.ntp.org" <questions-request at lists.ntp.org>
To: questions at lists.ntp.org
Sent: Sat, October 16, 2010 7:00:01 AM
Date: Thu, 14 Oct 2010 22:51:40 -0700 (PDT)
From: M Z <mcrunch2 at yahoo.com>
To: questions at lists.ntp.org
Subject: [ntp:questions] serialPPS+gpsd+ntpd large offset & jitter
Message-ID: <499281.68938.qm at web113313.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1

Hi. I have both usglobalsat MR350P and garmin 18xLVC connected to serial at both 

4800 and 9600.
gpsd was 2.37 but is now 2.95. ntpd is 4.2.4p7, OS: SuSE 11.2 = 2.6.31. I have 
used both
serial ports. I set to low_latency as per instructions:
http://www.lammertbies.nl/comm/info/GPS-time.html


more time
?SHM(0)????????? .GPS.??????????? 0 l? 57m?? 16??? 0??? 0.000??? 0.000?? 0.001
?SHM(1)????????? .PPS.??????????? 0 l? 57m?? 16??? 0??? 0.000??? 0.000?? 0.001
+131.107.13.100? .ACTS.?????????? 1 u??? 3? 128? 367?? 55.288?? -7.875?? 5.460
*saturn.netwrx1. .PPS.??????????? 1 u?? 78? 128? 377?? 59.112?? -9.368?? 5.779
+tick.usask.ca?? .GPS.??????????? 1 u?? 51? 128? 377?? 81.580?? -7.873?? 1.362
+dev1-c.lax009.i 209.81.9.7?????? 2 u? 127? 128? 377?? 41.934?? -6.816?? 3.922
-clock.trit.net? 192.12.19.20???? 2 u?? 24? 128? 377?? 41.983? -13.802?? 4.239

just the servers are creeping a little but look like they are settling. 
certainly not going to -400 like it
would already be with the PPS.

    *NOTE* - hours later, offsets were -300 with jitter -50  (approximately)


I got rid of?server 127.0.0.1?in /etc/ntp.conf but that didn't help. Here is 
ntp.conf:
restrict??? default kod nomodify notrap nopeer
restrict -6 default kod nomodify notrap nopeer
restrict 127.0.0.1
restrict -6 ::1
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.485 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid PPS
server 131.107.13.100
server ntp2.netwrx1.com? iburst
restrict 131.107.13.100 mask 255.255.255.255 nomodify notrap noquery
restrict ntp2.netwrx.com? mask 255.255.255.255 nomodify notrap noquery
server tick.usask.ca
restrict tick.usask.ca mask 255.255.255.255 nomodify notrap noquery
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

So, what is going wrong? What things do I still need to do? This computer will 
not serve time to any others but needs very accurate time itself. cron jobs all 
commented out.?ps ax |grep ntp ?looks like:

...???? ?/usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp 
-c /etc/ntp.conf
Thanks.

------------------------
Message: 2
Date: 16 Oct 2010 08:42:32 GMT
From: Rob <nomail at example.com>
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] serialPPS+gpsd+ntpd large offset & jitter
Message-ID: <slrnibipbo.5ja.nomail at xs8.xs4all.nl>
Content-Type: text/plain; charset=us-ascii

M Z <mcrunch2 at yahoo.com> wrote:
> Hi. I have both usglobalsat MR350P and garmin 18xLVC connected to serial at 
>both 
>
> 4800 and 9600.
> gpsd was 2.37 but is now 2.95. ntpd is 4.2.4p7, OS: SuSE 11.2 = 2.6.31. I have 

> used both
> serial ports. I set to low_latency
> gpsd 2.37 did not communicate with ntp for the pps (ntpq -p 'when' column 
>always 
>
> -). 2.95 seems to work ok. output looks good, xgps works (7 sats used), etc. 
> However, jitter seems large and offset, no matter how small to start (usually 
>+- 
>
> 20.) always creeps up to about -300 to -500.

There is a problem within gpsd that can bite you with some receivers.
I originally wrote the code but I have not been paying attention lately
and it may be that some things have changed.

However the point is this: the PPS sent from gpsd to ntpd is sent via
the second SHM interface.  But via this interface to ntpd one cannot
really send PPS information, only absolute time can be sent.  But of
course PPS does not convey absolute time.

So the workaround I made in gpsd is to derive the absolute time from
the NMEA or whatever binary messages sent by the receiver (and conveyed
to ntpd via the first SHM interface).  To do this, the moment the PPS
line ticks has to be within a certain time from the moment the serial
message arrives, I think this was coded at about 400ms, or the PPS
pulse cannot be related to an absolute timestamp and it is rejected.

The problem is that some receivers send a serial message timestamp that
is way off the actual time, and the lock can never be achieved.
It is possible to increase the locking range (and I think the current
maintainers have done that already) but the risk is that the PPS
pulse is associated with the wrong serial message and the PPS clock
is off by one second.


      



More information about the questions mailing list