On Thu, Mar 24, 2011 at 04:17 UTC, Dave Hart wrote:
> 4.2.7p24 came out in April 2009
Correction: 4.2.7p24 came out 13 April 2010.
> Nothing between p23 and p24 jumps out at me as likely related. I
> wonder if this cset from October 2010 (first included in 4.2.5p237-RC)
I need coffee. 4.2.5p23
On Thu, Mar 24, 2011 at 02:19 UTC, lellis wrote:
> Well, I have used the ever-faithful binary search on the Windows
> builds to try to find where the strange offset introduced itself.
I'm impressed by your patience with the tedium required.
> The first build to show the odd offset (between NMEA
Well, I have used the ever-faithful binary search on the Windows
builds to try to find where the strange offset introduced itself.
The first build to show the odd offset (between NMEA and PPS ATOM) is
4.2.7p24.
4.2.7p23 seems to behave normally.
The offset difference between PPS and NMEA is abou
On Tue, Mar 22, 2011 at 11:12 PM, unruh wrote:
> On 2011-03-23, Hal Murray wrote:
>
> You can probably do better than that. That is for the reaction to
> something that you do not expect. Ie, you have decide that the event has
> occured and then send the messages to your finger to press. However
On Wed, Mar 23, 2011 at 08:06 UTC, David J Taylor wrote:
> "stable" builds have even numbers
> "development" have odd numbers
>
> I believe some of the later changes relate to how multiple NMEA sentences
> are handled, but I can't give you exact version numbers where changes were
> made.
Use the s
On 2011-03-22, bombjack wrote:
> I am fully aware fo how ntpd should be used, i.e. 24/7/365, but that
> is not what I am asking for. As I stated above, I need to make sure
> the system clock is roughly (your wrist watch would do) the correct
> time ASAP during boot as other systems will use this
On 23.3.2011 8:07, Hal Murray wrote:
You can probably do better than that. That is for the reaction to
something that you do not expect. Ie, you have decide that the event has
occured and then send the messages to your finger to press. However for
the timing, you know exactly when it is going t
Thanks to all. I am using Garmin 3.20, as it it turns out.
However, I reverted to 4.2.5p233 of Dave Hart's builds, and it does
not appear to have the same strange behavior. I had been using
4.2.7p138 (which I first installed only yesterday).
I'll try a few of Dave's other builds to see if I ca
On Mar 22, 10:54 pm, Steve Kostecke wrote:
> On 2011-03-22, bombjack wrote:
>
> > Hehe, that's what I am trying to do, i.e. get rid of rdate. The system
> > I work with is rather old and has used rdate since forever. I am
> > merely doing maintenance work and want to exchange rdate for ntpd.
> >
>You can probably do better than that. That is for the reaction to
>something that you do not expect. Ie, you have decide that the event has
>occured and then send the messages to your finger to press. However for
>the timing, you know exactly when it is going to occur. You can get
>yourself into
On 2011-03-23, Hal Murray wrote:
>
>>> oh, come off it. Your reaction time is nowhere near what ntp -q would
>>> give you. Using ntp -q run once every hour, and assuming say a 20PPM
>>> drift for the crystal, his clock would be out by less than a 100 ms due to
>>> the
>>> drifting, and your react
11 matches
Mail list logo
