> From: Unruh
> Date: Sun, 29 Mar 2009 04:16:23 GMT
> Sender: questions-bounces+oberman=es@lists.ntp.org
>
> ober...@es.net (Kevin Oberman) writes:
>
> >> From: Harlan Stenn
> >> Date: Sat, 28 Mar 2009 08:48:35 +
> >> Sender: questions-bounces+oberman=es@lists.ntp.org
> >>
> >> >>>
Unruh wrote:
[]
> Curnow had an intrest at one time in porting to windows, but his
> interest
> or time to keep up chrony is low now so it will have to be done by
> others.
OK, Bill, sorry to hear it may take some time.
Cheers,
David
___
questions ma
ober...@es.net (Kevin Oberman) writes:
>> From: Harlan Stenn
>> Date: Sat, 28 Mar 2009 08:48:35 +
>> Sender: questions-bounces+oberman=es@lists.ntp.org
>>
>> >>> In article , Bill Unruh
>> >>> writes:
>>
>> > Harlan Stenn writes:
>> >> From one POV, it seems to me that each "instance
John,
The intended design to detect and suppress bad reference/PPS clocks is
at least two additional sources, that do not have to be reference
clocks. If the reference/PPS clock sails to the sunset, the selection
algorithm will vote it off and the PPS will follow. The server will
continue at w
Kevin Oberman said the following on 03/28/2009 06:53 PM:
> Ideally, if the source of the time being trained by the PPS is bad, the
> PPS also should be considered bad and kernel PPS should be disabled.
This should only be the behaviour for a refclock that provides both a
PPS and a timecode. If
> From: Harlan Stenn
> Date: Sat, 28 Mar 2009 08:48:35 +
> Sender: questions-bounces+oberman=es@lists.ntp.org
>
> >>> In article , Bill Unruh
> >>> writes:
>
> > Harlan Stenn writes:
> >> From one POV, it seems to me that each "instance" of a PPS source should
> >> come with "health i
"David J Taylor"
writes:
>David Woolley wrote:
>> David J Taylor wrote:
>>
>>>
>>> Is there a parameter I can tune from the ntp.conf which would reduce
>>> the offset, at the expense of increased jitter? Perhaps I'm asking
>>> for the impossible?
>>>
>>
>> Reducing minpoll will help, but you ar
Are there any algorithm of other differences which might cause noticeable
performance differences between 4.2.4 and 4.2.5? For example:
- 4.2.5 being more reluctant to increasing the polling interval from 64s
(with a mixture of local stratum-1 and Internet pool servers)?
- 4.2.5 showing an inc
>>> In article <49ce0b3a.9030...@febo.com>, j...@febo.com (John Ackermann N8UR)
>>> writes:
> Harlan Stenn said the following on 03/28/2009 04:48 AM:
>> In one case, there can be a GPS device that may deliver a PPS second but
>> that PPS is not really sync'd. The GPS device in this case will usu
Harlan Stenn said the following on 03/28/2009 04:48 AM:
> Bill> Not sure what the health info would be. The health of PPS is either
> Bill> great, (if the seconds is good) or attrocious (if the second is bad),
> Bill> and the driver presumably does not know this or it would have
> Bill> corrected
David J Taylor wrote:
>
> Is there a parameter I can tune from the ntp.conf which would reduce the
> offset, at the expense of increased jitter? Perhaps I'm asking for the
> impossible?
>
Reducing minpoll will help, but you are basically observing an aspect of
why Bill Unruh advocates chron
David Woolley wrote:
> David J Taylor wrote:
>
>>
>> Is there a parameter I can tune from the ntp.conf which would reduce
>> the offset, at the expense of increased jitter? Perhaps I'm asking
>> for the impossible?
>>
>
> Reducing minpoll will help, but you are basically observing an aspect
> of w
David J Taylor wrote:
> You can now call the program with a list of ntp nodes to check on the
> command line:
Further update, I've added a command-line only version for fully automated
operation.
http://www.satsignal.eu/software/net.htm#NTPLeapTrace
On my own system, the following nodes are i
>>> In article , Bill Unruh
>>> writes:
> Harlan Stenn writes:
>> From one POV, it seems to me that each "instance" of a PPS source should
>> come with "health information" about that PPS instance. This "health"
>> information should include the current expected precision of the PPS
>> signal.
Harlan Stenn writes:
In article <968zl.19988$ph1.19...@edtnps82>, Unruh
writes:
>Unruh> That may be the logic, but it is seriously flawed. It also indicates
>Unruh> that the decision to interpret PPS separately from the other drivers
>Unruh> is flawed. atom should ONLY be used for a
15 matches
Mail list logo
