Mischanko, Edward T wrote:> I would modify the current algorithm with an
exception
> that if offsets exceed 1 millisecond for more than one
> polling cycle, then, polling will be reduced by one
> interval, else, continue normal operation.
Look at ntp_loopfilter.c {around line 650?}
* Here we
Sent: Saturday, May 25, 2013 9:27 AM
>> To: questions@lists.ntp.org
>> Subject: Re: [ntp:questions] Tighter regulation?
>>
>> On 2013-05-25, Mischanko, Edward T
>> wrote:
>> >
>> >> -Original Message-
>> >> From: Charles Swi
ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> Mischanko, Edward T wrote:
>
> >
> > I tried reducing the Allan Intercept to 7 and the result was wild swings
> in
> > frequency ppm. I don't know why? Is the FLL broken? Has anyone else
> &g
Mischanko, Edward T wrote:
I don't believe the room temperature changes much at this computer's
location.
Now if your computer
heats up and cools down by 20C over an hour that could change the clock
by a few ms. And ntpd is slow to respond to changes in clock rate.
[Mischanko, Edward T
Mischanko, Edward T wrote:
I tried reducing the Allan Intercept to 7 and the result was wild swings in
frequency ppm. I don't know why? Is the FLL broken? Has anyone else
observed this behavior?
If you are not suffering from wild swings in frequency, you should not
be trying to reduce t
ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> unruh wrote:
>
> >
> > Note that on maxpoll 10, the clock will freerun for about 7000 sec
> > between disciplines. 5ms in 7000 sec is about 1PPM. Now if your computer
>
> The time constant for the pro
sts.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> On 5/25/2013 5:55 AM, Mischanko, Edward T wrote:
> > [Mischanko, Edward T]
> >
> > I would modify the current algorithm with an exception that if offsets
> > exceed 1 millisecond for more than one p
ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> On 2013-05-25, Mischanko, Edward T
> wrote:
> >
> >> -Original Message-
> >> From: Charles Swiger [mailto:cswi...@mac.com]
> >> Sent: Friday, May 24, 2013 1:01 AM
> >> To: Mischanko,
ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> Mischanko, Edward T wrote:
>
> >
> > I would modify the current algorithm with an exception that if offsets
> > exceed 1 millisecond for more than one polling cycle, then, polling
> will be
> &g
unruh wrote:
Note that on maxpoll 10, the clock will freerun for about 7000 sec
between disciplines. 5ms in 7000 sec is about 1PPM. Now if your computer
The time constant for the proportional correction is 16384 seconds, so
only about 35% of the correction would be made over 7000 seconds. I
On 5/25/2013 5:55 AM, Mischanko, Edward T wrote:
[Mischanko, Edward T]
I would modify the current algorithm with an exception that if offsets
exceed 1 millisecond for more than one polling cycle, then, polling will be
reduced by one interval, else, continue normal operation.
What if 1 mill
On 2013-05-25, Mischanko, Edward T wrote:
>
>> -Original Message-
>> From: Charles Swiger [mailto:cswi...@mac.com]
>> Sent: Friday, May 24, 2013 1:01 AM
>> To: Mischanko, Edward T
>> Cc: questions@lists.ntp.org
>> Subject: Re: [ntp:questions] Tighter
Mischanko, Edward T wrote:
I would modify the current algorithm with an exception that if offsets
exceed 1 millisecond for more than one polling cycle, then, polling will be
reduced by one interval, else, continue normal operation.
Whilst I still think the OP is trying to make the statisti
chanko=arcelormittal@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelormittal@lists.ntp.org] On Behalf Of
> unruh
> Sent: Friday, May 24, 2013 9:55 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> On 2013-05-24
> >>> On 2013-05-21, Mischanko, Edward T
>
> >> wrote:
> My concern is that too much data is being thrown away when polling
> above 256 seconds and that allows excessive wandering of my clock.
> >> If too much data is being thrown away, it would be because the poll
> >> adjust algorithm
> -Original Message-
> From: Charles Swiger [mailto:cswi...@mac.com]
> Sent: Friday, May 24, 2013 1:01 AM
> To: Mischanko, Edward T
> Cc: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> On May 23, 2013, at 10:02 PM, "Mischank
On 2013-05-24, David Woolley wrote:
>
>> is entitled to. Why do you not use chrony? I know you have tried it.
>>
> I'm fairly sure he said Windows up thread.
If he did, I missed it, and I apologize for my irrelevant suggestion.
So, decrease the poll interval.
_
is entitled to. Why do you not use chrony? I know you have tried it.
I'm fairly sure he said Windows up thread.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On 2013-05-24, Mischanko, Edward T wrote:
>
>
>>
>>
>> > On 2013-05-21, Mischanko, Edward T
>> wrote:
>> >
>> >> My concern is that too much data is being thrown away when polling
>> >> above 256 seconds and that allows excessive wandering of my clock.
>> >
>>
>> If too much data is being thro
David Woolley writes:
> Offset is not offset from true time.
And that, I think, is the major point of confusion here. If offset was
the offset from true time ntpd would just subtract it out, set the clock
to true time, and we'd all be happy. It isn't. It's one of the pieces
of information ntpd
Mischanko, Edward T wrote:
On 2013-05-21, Mischanko, Edward T
wrote:
My concern is that too much data is being thrown away when polling
above 256 seconds and that allows excessive wandering of my clock.
If too much data is being thrown away, it would be because the poll
adjust algorithm h
On May 23, 2013, at 10:02 PM, "Mischanko, Edward T"
wrote:
> It takes too long to figure out it needs a more aggressive correction.
> If I leave maxpoll at the default of 1024 seconds, my clock drifts outside
> of 5 milliseconds consistently.
Measured by what? If you have a better source of tim
>
>
> > On 2013-05-21, Mischanko, Edward T
> wrote:
> >
> >> My concern is that too much data is being thrown away when polling
> >> above 256 seconds and that allows excessive wandering of my clock.
> >
>
> If too much data is being thrown away, it would be because the poll
> adjust algorith
On 2013-05-21, Mischanko, Edward T wrote:
My concern is that too much data is being thrown away when polling
above 256 seconds and that allows excessive wandering of my clock.
If too much data is being thrown away, it would be because the poll
adjust algorithm has chosen too high a poll
On 2013-05-21, Mischanko, Edward T wrote:
> My concern is that too much data is being thrown away when polling
> above 256 seconds and that allows excessive wandering of my clock.
The clock filter algorithm processes the offset and delay samples
produced by the on-wire protocol for each peer pro
] On Behalf Of
> unruh
> Sent: Monday, May 20, 2013 3:14 PM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> On 2013-05-20, Mischanko, Edward T
> wrote:
> > Hello friends,
> >
> > Does anyone know what setting can be chan
ounces+edward.mischanko=arcelormittal@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelormittal@lists.ntp.org] On Behalf Of
> David Woolley
> Sent: Monday, May 20, 2013 8:13 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation
On 2013-05-20, unruh wrote:
> On 2013-05-20, David Woolley wrote:
>> Mischanko, Edward T wrote:
>>
>>> Does anyone know what setting can be changed that will cause
>>> tighter regulation of the offset. My goal is to get clk_wander to
>>
>> Why do you want to track network propagation delay chang
On 2013-05-20, David Woolley wrote:
> Mischanko, Edward T wrote:
>
>> Does anyone know what setting can be changed that will cause
>> tighter regulation of the offset. My goal is to get clk_wander to
>
> Why do you want to track network propagation delay changes, at the
> expense of accurate tim
On 2013-05-20, Mischanko, Edward T wrote:
> Hello friends,
>
> Does anyone know what setting can be changed that will cause
> tighter regulation of the offset. My goal is to get clk_wander to
> equal as close to zero as possible more often. I would also like
> to see the frequency adjusted with
Mischanko, Edward T wrote:>
The particular client I am monitoring is on an extremely stable corporate
LAN. The servers are on the same LAN. Changes in network propagation
are minimal.
On the other hand, it is on Windows, which doesn't have very stable time
measurement.
The 8 stage minimu
David Woolley wrote:
Mischanko, Edward T wrote:>
2) an analysis of the breakdown of errors between the crystal frequency,
Windows load related errors, and network load related error.
In particular, unless your main error source is changes in crystal
frequency, in which case the best approac
ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> On 20/05/2013 08:58, Mischanko, Edward T wrote:
> > Hello friends,
> >
> > Does anyone know what setting can be changed that will cause
> > tighter regulation of the offset. My goal is to get clk_wander to
>
estions@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>
> Mischanko, Edward T wrote:
>
> > Does anyone know what setting can be changed that will cause
> > tighter regulation of the offset. My goal is to get clk_wander to
>
> Why do you want
Mischanko, Edward T wrote:
Does anyone know what setting can be changed that will cause
tighter regulation of the offset. My goal is to get clk_wander to
Why do you want to track network propagation delay changes, at the
expense of accurate time keeping?
equal as close to zero as possible
On 20/05/2013 08:58, Mischanko, Edward T wrote:
Hello friends,
Does anyone know what setting can be changed that will cause
tighter regulation of the offset. My goal is to get clk_wander to
equal as close to zero as possible more often. I would also like
to see the frequency adjusted with ever
Hello friends,
Does anyone know what setting can be changed that will cause
tighter regulation of the offset. My goal is to get clk_wander to
equal as close to zero as possible more often. I would also like
to see the frequency adjusted with every change in offset data;
it currently does not app
37 matches
Mail list logo
