| RE: [chrony-users] kernel PPS troubleshooting |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
Bill,
Thanks for taking an initial look. I've added my system to our network to compare our GPS time with the general NTP pool and it looks like our GPS could be right on the edge of that 0.4s window. I'm going to let it run for a bit like this and report back after trying a larger offset for our SHM refclock. The receiver I am using is an MTK3339 if anyone else has a standard offset they use (default speed and strings (9600 8n1 with GGA GSA RMC VTG and VSG enabled).
Thanks,
SCott
-----Original Message-----
From: Bill Unruh [mailto:unruh@xxxxxxxxxxxxxx]
Sent: Tuesday, November 26, 2013 1:43 PM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [chrony-users] kernel PPS troubleshooting
The pps can only give you when the second turnover occurs, it cannot tell you which second that is. That MUST be given by some other time source, which could be the nmea sentences from the gps or by some other source. The problem with the nmea is that it is usually late. Late by something like .5 to 1 sec.
But chrony must be confident that the system time is within less than .5 sec of the real time before it will trust the PPS. source. Now, it looks to me on a very quick look that this is not happening for some reason, and so that pps data is being rejected.
I have not looked at Miroslav's code to figure out exactly what is being reported, so am not at allconfident I am reading it properly.
On Tue, 26 Nov 2013, Battocchi, Scott L. wrote:
> Miraslov,
> Thanks for the modified source, I've recompiled it with --enable-trace and do indeed get a lot more information.
> I modified the original chrony.conf to drop the external gps (GPSe/PPSe) since they were generating a lot of sample ignored trace messages (no valid fix and no updating pps), so the reports below are with only the GPSi/PPSi sources active in the configuration.
>
> I've tried to copy key portions of the run below to avoid attaching the 5MB trace log, I'm open to other methods of sharing the whole log if there is interest. I have attached the tracking.log since it shows when PPS was available compared to the long periods where GPS was active (and the PPS was coming into /dev/pps1). It looks like the pulse is ignored when offdiff is relatively large (>0.2?), but that the offdiff steps very quickly between valid and invalid. It is also possible I'm interpreting the pulse handling completely incorrectly.
>
> Starting the modified chrony all appears well for a while but within a couple of minutes most of the PPS pulses are ignored. PPS goes in and out of being ignored for the next ~5 minutes before disappearing for another 90 minutes. After that brief recovery, it is ignored for the rest of the run:
> :~/chronytrace# ./chrony [Jd -d
> main.c:355:(main)[26-18:00:28] chronyd version DEVELOPMENT starting
> sys_linux.c:1022:(get_version_specific_details)[26-18:00:28] Linux
> kernel major=3 minor=3 patch=0
> sys_linux.c:1080:(get_version_specific_details)[26-18:00:28] hz=100
> shift_hz=7 freq_scale=1.00000000 nominal_tick=10000
> slew_delta_tick=833 max_tick_bias=1000 shift_pll=2
> local.c:565:(lcl_RegisterSystemDrivers)[26-18:00:28] Local
> freq=297.043ppm refclock.c:253:(RCL_AddRefclock)[26-18:00:28] refclock
> PPS added poll=4 dpoll=0 filter=16
> refclock.c:253:(RCL_AddRefclock)[26-18:00:28] refclock SHM added
> poll=4 dpoll=0 filter=16 reference.c:194:(REF_Initialise)[26-18:00:28]
> Initial frequency 297.043 ppm
> sources.c:331:(SRC_SetSelectable)[26-18:00:28] PPSi
> sources.c:331:(SRC_SetSelectable)[26-18:00:28] GPSi
> refclock.c:416:(RCL_AddPulse)[26-18:00:28] refclock pulse ignored no
> ref sample refclock.c:687:(filter_add_sample)[26-18:00:28] filter
> sample 0 t=Tue 11/26/13 18:00:28.080062 offset=1.059937008
> dispersion=0.000003000 refclock.c:440:(RCL_AddPulse)[26-18:00:29]
> refclock pulse ignored offdiff=-0.459021095 refdisp=0.000003000
> disp=0.000002001 refclock.c:687:(filter_add_sample)[26-18:00:29]
> filter sample 1 t=Tue 11/26/13 18:00:29.060753 offset=1.079246196
> dispersion=0.000003000 refclock.c:440:(RCL_AddPulse)[26-18:00:30]
> refclock pulse ignored offdiff=-0.440026443 refdisp=0.000003000
> disp=0.000002001 refclock.c:687:(filter_add_sample)[26-18:00:30]
> filter sample 2 t=Tue 11/26/13 18:00:30.076668 offset=1.063331638
> dispersion=0.000003000 refclock.c:440:(RCL_AddPulse)[26-18:00:31]
> refclock pulse ignored offdiff=-0.456248500 refdisp=0.000003000
> disp=0.000002001 refclock.c:687:(filter_add_sample)[26-18:00:31]
> filter sample 3 t=Tue 11/26/13 18:00:31.121044 offset=1.018955039
> dispersion=0.000003000 refclock.c:440:(RCL_AddPulse)[26-18:00:32]
> refclock pulse ignored offdiff=0.499073485 refdisp=0.000003000
> disp=0.000002001 refclock.c:687:(filter_add_sample)[26-18:00:32]
> filter sample 4 t=Tue 11/26/13 18:00:32.121227 offset=1.018772016
> dispersion=0.000003000 refclock.c:440:(RCL_AddPulse)[26-18:00:33]
> refclock pulse ignored offdiff=0.498576090 refdisp=0.000003000
> disp=0.000002001 refclock.c:687:(filter_add_sample)[26-18:00:33]
> filter sample 5 t=Tue 11/26/13 18:00:32.702642 offset=1.437357065
> dispersion=0.000003000 refclock.c:447:(RCL_AddPulse)[26-18:00:34]
> refclock pulse second=0.479480414 offset=1.520519586
> offdiff=-0.083162521 samplediff=0.776838000
.....
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.