On Wed, Dec 11, 2013 at 10:11:48AM -0800, Bill Unruh wrote:
> On Wed, 11 Dec 2013, Miroslav Lichvar wrote:
> >When no source is selected, the PPS samples are ignored. If the SHM
> >source doesn't move to the acceptable range to overlap with the PPS
> >source in 8 polling intervals, the PPS source i
On Tue, Dec 10, 2013 at 08:29:25PM -0500, Battocchi, Scott L. wrote:
> I've attached the tracking, measurements, refclocks, and sources logs trimmed
> to start at the 2.35 hour mark (to coincide with the graph colored by sync
> source in my previous mail). I also moved the rolling header line fo
On Wed, 11 Dec 2013, Miroslav Lichvar wrote:
On Tue, Dec 10, 2013 at 08:29:25PM -0500, Battocchi, Scott L. wrote:
I've attached the tracking, measurements, refclocks, and sources logs trimmed
to start at the 2.35 hour mark (to coincide with the graph colored by sync
source in my previous mail
On Tuesday, December 03, 2013 9:18 AM Miroslav Lichvar wrote:
> On Mon, Dec 02, 2013 at 02:59:05PM -0500, Battocchi, Scott L. wrote:
>> Since we will not have access to a network time source and will be relying
>> on GPSD/NMEA to get us in the correct ballpark on system startup, is there
>> an
On Mon, Dec 02, 2013 at 02:59:05PM -0500, Battocchi, Scott L. wrote:
> Since we will not have access to a network time source and will be relying on
> GPSD/NMEA to get us in the correct ballpark on system startup, is there
> another configuration option we can try to minimize the snapping back to
--Original Message-
From: Bill Unruh [mailto:un...@physics.ubc.ca]
Sent: Monday, December 02, 2013 1:56 PM
To: chrony-users@chrony.tuxfamily.org
Subject: RE: [chrony-users] kernel PPS troubleshooting
The key purpose of the gps is to supply the seconds for the PPS. Once it has
done that it is no lo
2013 1:56 PM
To: chrony-users@chrony.tuxfamily.org
Subject: RE: [chrony-users] kernel PPS troubleshooting
The key purpose of the gps is to supply the seconds for the PPS. Once it has
done that it is no longer needed. Thus you could have the gps run with pps for
a while, and then do a noselect on it usin
On Thursday, November 28, 2013 6:15 AM Miroslav Lichvar wrote:
>On Wed, Nov 27, 2013 at 04:06:58PM -0500, Battocchi, Scott L. wrote:
>> I ran the GPS while connected to a handful of ntp servers and saw that my
>> gps offset (originally 0.180) was too low, so I bumped it up to 0.530 for
>> the ne
--
From: Bill Unruh [mailto:un...@physics.ubc.ca]
Sent: Friday, November 29, 2013 11:48 AM
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] kernel PPS troubleshooting
On Fri, 29 Nov 2013, Miroslav Lichvar wrote:
> On Fri, Nov 29, 2013 at 09:46:32AM -0800, Bill Unruh wrote:
>> On Fri, 2
nruh [mailto:un...@physics.ubc.ca]
Sent: Friday, November 29, 2013 11:48 AM
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] kernel PPS troubleshooting
On Fri, 29 Nov 2013, Miroslav Lichvar wrote:
On Fri, Nov 29, 2013 at 09:46:32AM -0800, Bill Unruh wrote:
On Fri, 29 Nov 2013, Bill Unru
On Fri, Nov 29, 2013 at 09:46:32AM -0800, Bill Unruh wrote:
> On Fri, 29 Nov 2013, Bill Unruh wrote:
> By the way, does the kernel PPS do median filtering before passing on the
> times to chrony? (Ie, taking the median of say the past 16 inputs and throwing
> away the 6 worst outliers and then reta
On 29/11/2013 18:21, Miroslav Lichvar wrote:
Anyway, it should not be switching sources unless the deviation of the
selected source exceeds the variance of the alternative (or unless the source
has disappeared for a suitable number of poll intervals, probably related to
how long one would expect
On Thu, Nov 28, 2013 at 11:11:18AM -0800, Bill Unruh wrote:
> On Thu, 28 Nov 2013, Miroslav Lichvar wrote:
> >That looks similar to what I see with with a Garmin 18x LVC. This is a
> >capture 30 hours long I did some time ago (the NMEA source's offset
> >value was set to 0.5):
> >
> >http://mlichva
On Fri, 29 Nov 2013, Miroslav Lichvar wrote:
On Fri, Nov 29, 2013 at 09:46:32AM -0800, Bill Unruh wrote:
On Fri, 29 Nov 2013, Bill Unruh wrote:
By the way, does the kernel PPS do median filtering before passing on the
times to chrony? (Ie, taking the median of say the past 16 inputs and throwin
On Fri, 29 Nov 2013, Bill Unruh wrote:
On Fri, 29 Nov 2013, Miroslav Lichvar wrote:
> The problem in his case is that the PPS signal is occasionally
> (but far too often) off by almost .3 sec. That is rediculous. And it is
> only
> when the gps-nmea and the PPS are the only sources.
He
On Fri, 29 Nov 2013, Miroslav Lichvar wrote:
The problem in his case is that the PPS signal is occasionally
(but far too often) off by almost .3 sec. That is rediculous. And it is only
when the gps-nmea and the PPS are the only sources.
He said chronyd was switching between the PPS and GPS sou
On 28/11/2013 20:54, Bill Unruh wrote:
And on further thought, I also concede your point, since
pps does not really
give the fractions of a second either, but just gives the
second mark. You do
need an additional "clock" to actually tell you the
fractions of a second.
Yes...
Anyway, I hope
On 28/11/2013 20:05, Bill Unruh wrote:
On Thu, 28 Nov 2013, Tomalak Geret'kal wrote:
On 28/11/2013 19:11, Bill Unruh wrote:
Is this the nmea time or the PPS time?
What is "PPS time"? PPS provides timing, not time.
In my nomenclature, they are the same. PPS does supply
time but just the
f
On 28/11/2013 19:11, Bill Unruh wrote:
Is this the nmea time or the PPS time?
What is "PPS time"? PPS provides timing, not time.
Tom
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
On Wed, Nov 27, 2013 at 04:06:58PM -0500, Battocchi, Scott L. wrote:
> I ran the GPS while connected to a handful of ntp servers and saw that my gps
> offset (originally 0.180) was too low, so I bumped it up to 0.530 for the
> next two tests. I've attached plots of the offset as recorded in the
And on further thought, I also concede your point, since pps does not really
give the fractions of a second either, but just gives the second mark. You do
need an additional "clock" to actually tell you the fractions of a second.
Anyway, I hope I clarified what I meant.
On Thu, 28 Nov 2013, Tom
On Thu, 28 Nov 2013, Tomalak Geret'kal wrote:
On 28/11/2013 19:11, Bill Unruh wrote:
Is this the nmea time or the PPS time?
What is "PPS time"? PPS provides timing, not time.
In my nomenclature, they are the same. PPS does supply time but just the
fractional seconds part of it. (Just as nt
On Thu, 28 Nov 2013, Miroslav Lichvar wrote:
On Wed, Nov 27, 2013 at 04:06:58PM -0500, Battocchi, Scott L. wrote:
I ran the GPS while connected to a handful of ntp servers and saw that my gps
offset (originally 0.180) was too low, so I bumped it up to 0.530 for the next
two tests. I've attac
wander seen in the ntp plot.
Thanks,
Scott
-Original Message-
From: Miroslav Lichvar [mailto:mlich...@redhat.com]
Sent: Wednesday, November 27, 2013 1:44 AM
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] kernel PPS troubleshooting
On Tue, Nov 26, 2013 at 08:49:19PM -
...@redhat.com]
Sent: Wednesday, November 27, 2013 1:44 AM
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] kernel PPS troubleshooting
On Tue, Nov 26, 2013 at 08:49:19PM -0500, Battocchi, Scott L. wrote:
Bill,
Thanks for taking an initial look. I've added my system to our ne
On Tue, Nov 26, 2013 at 08:49:19PM -0500, Battocchi, Scott L. wrote:
> 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
ed one for timing.
Thanks,
SCott
-Original Message-
From: Bill Unruh [mailto:un...@physics.ubc.ca]
Sent: Tuesday, November 26, 2013 1:43 PM
To: chrony-users@chrony.tuxfamily.org
Subject: RE: [chrony-users] kernel PPS troubleshooting
The pps can only give you when the second turnover occurs,
ovember 26, 2013 1:43 PM
To: chrony-users@chrony.tuxfamily.org
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 sentence
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
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
On Mon, Nov 25, 2013 at 06:50:01PM -0500, Battocchi, Scott L. wrote:
> I've recently cross-compiled chrony-0308330 to run on our armv5 platform and
> it seems to silently/selectively ignore our PPS source even when it is
> present. Currently all testing is being done with our cheap receiver
> (
On Mon, 25 Nov 2013, Battocchi, Scott L. wrote:
Hi,
I'm very new to chrony and am trying to do something that I believe to be
supported. I am trying to sync our system to two local GPS receivers depending
on whether one or both of them have a fix, with a preference for the higher
priced rece
32 matches
Mail list logo
