Bill,
Not quite. There must always be a selection in every run of eight
samples, so there can be no more than seven unselected samples in a row.
To gain more insight, run ntpd with -d to produce a trace. Note in the
clock_filter trace the age value, which is the interval from the last
selected
David,
The rub is when a new sample comes along when an older sample with lower
delay is in the filter. This can and often does persist until the
minimum sample is ejected from the filter by a newer sample and the
minimum sample is redetermined. So, the minimum sample, and thus the
maximum loo
Unruh,
My message to David probably is most relevant.
Dave
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
>
>>Unrug,
>
>
>>You are not accurately describing the ntpd clock filter. An accurate
>>desciption would surely help the point you are making.
>
>
> You are undoubtedl
Unruh wrote:
> night and getting myself confused again. I do not think my comments about
> the aging are correct.
It looks like ones older than the Allan Intercept are aged, but they are
defined in such a way that they are always worse choices than ones
before the Allan Intercept.
>
> I think
David Woolley <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>>
>> Under ... is the line
>> dst[i]=peer->filter_delay[j]
>>
>Apologies, I missed that detail. I guess dst has changed its meaning
>over time. (It doesn't really look right to me though, as there is a
>sudden discontinuity as you cros
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Unrug,
>You are not accurately describing the ntpd clock filter. An accurate
>desciption would surely help the point you are making.
You are undoubtedly correct. I was reading the source code again loast
night and getting myself confused again. I do
Unruh wrote:
>
> Under ... is the line
> dst[i]=peer->filter_delay[j]
>
Apologies, I missed that detail. I guess dst has changed its meaning
over time. (It doesn't really look right to me though, as there is a
sudden discontinuity as you cross the Allan Intercept.)
However, that doesn't chan
David Woolley <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>>
>> This is in the clock_filter algorithm. It selects the sample of the last 8
>> which has the lowest delay (suitably aged) If that sample is the most
>Yes. That's what I am talking about. Specifically clock_filter in
>ntp_proto.c.
>
David,
We are talking right past each other and are not having a productive
discussion. Tge best choice for me is just to shut up.
Dave
David Woolley wrote:
> David L. Mills wrote:
>
>> Guys,
>>
>> This is really silly. The Unruh agenda is clear. Should you choose to
>
>
> I think you repl
Unrug,
You are not accurately describing the ntpd clock filter. An accurate
desciption would surely help the point you are making.
Davde
Unruh wrote:
> Grian Utterback <[EMAIL PROTECTED]> writes:
>
>
>>David J Taylor wrote:
>>
>>>Brian Utterback wrote:
>>>[]
>>>
Which is why NTP prefers
David,
Can we take a time out? Can you read the NTPv4 specification where it
describes the system process? Our disussion would be much more
productive after that.
Dave
David Woolley wrote:
> David L. Mills wrote:
>
>> David,
>>
>> I don't know what you mean by "figure head", but this is proba
Unruh wrote:
>
> This is in the clock_filter algorithm. It selects the sample of the last 8
> which has the lowest delay (suitably aged) If that sample is the most
Yes. That's what I am talking about. Specifically clock_filter in
ntp_proto.c.
> recent, then it is actually used. Otherwise noth
David Woolley <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>>
>> Worse than that . Only if the latest sample is the one with the min delay
>> is it chosen Otherwise it is not. You can go for 16 or more samples never
>> using any of thembefor one fits the criteion. (actually the samples are
>> aged
Unruh wrote:
>
> Worse than that . Only if the latest sample is the one with the min delay
> is it chosen Otherwise it is not. You can go for 16 or more samples never
> using any of thembefor one fits the criteion. (actually the samples are
> aged as well-- ie the delay is increased as they get o
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Guys,
>This is really silly. The Unruh agenda is clear. Should you choose to
>limit the application space to fast local networks, the chrony choice
>may or may not be optimal. Should you extend this space to the raunchy
>global Internet, conviction
Grian Utterback <[EMAIL PROTECTED]> writes:
>David J Taylor wrote:
>> Brian Utterback wrote:
>> []
>>> Which is why NTP prefers the source with the smallest delay. The
>>> system I am using has servers whose delays are 51ms to 94. I can't
>>> find any closer. On my company LAN, the delays range fr
David L. Mills wrote:
> Guys,
>
> This is really silly. The Unruh agenda is clear. Should you choose to
I think you replied to the wrong node in the thread. I think what you
are actually doing is telling Steve that he shouldn't be asking for
these changes to included in ntpd at all.
Also, I
David L. Mills wrote:
> David,
>
> I don't know what you mean by "figure head", but this is probably what
I meant that it is the one peer chosen to represent all the peers
actually used.
> is intended. The statistics such as root delay, root dispersion and
> related statistics are in fact inh
Guys,
This is really silly. The Unruh agenda is clear. Should you choose to
limit the application space to fast local networks, the chrony choice
may or may not be optimal. Should you extend this space to the raunchy
global Internet, conviction will require diligent testing and analysis.
There
David,
I don't know what you mean by "figure head", but this is probably what
is intended. The statistics such as root delay, root dispersion and
related statistics are in fact inherited from the system peer, but the
actual clock offset is computed as a weighted average. See the draft
MT{v4 sp
Steve Kostecke wrote:
> There's nothing stopping him from implementing what he considers to be a
> solution himself. He could even distribute his modified version of NTP
> to anyone who wanted to use it.
Why should he do that when something already exists, although it is not
technically NTP? As
On 2008-01-31, David Woolley <[EMAIL PROTECTED]>
wrote:
> Steve Kostecke wrote:
>
>> If you wish to have a specific feature in NTP you can add it yourself
>> using the source which is available for download from:
>
> Whilst that is often an appropriate response, it isn't here. My
> impression is t
Steve Kostecke wrote:
> If you wish to have a specific feature in NTP you can add it yourself
> using the source which is available for download from:
Whilst that is often an appropriate response, it isn't here. My
impression is that Unruh has already downloaded the source code and
studied. M
David L. Mills wrote:
>
> The result of the sort is usually the first entry on the list, but even
I thought this only gave the figure head peer, but that the actual clock
disciplining used a weighted average of some number of candidates aa well.
> that can be temporarily displaced by the anti-
On 2008-01-30, Unruh <[EMAIL PROTECTED]> wrote:
> Again while I understand the desire for robustness, designing [NTP]
> so it always assumes very worst case scenario seems like overkill.
> Very few people are 160msec away from servers. Also the use of "pre"
> packets ( whether ping or ntp) really
Guys,
There seems to be widespread misunderstanding about how ntpd ranks the
survivors. The sort ranks the survivors first by stratum and then by
what the spec calls root distance within the same stratum. Root distance
is calculated as one-half the root roundtrip delay plus the root
dispersion
Brian Utterback <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>
>>> Unruh,
>>
>>> It would seem self evident from the equations that minimizing the delay
>>> variance truly does minimize the offset variance. Further evidence of
>>> that is in the ra
Brian Utterback wrote:
> Richard B. Gilbert wrote:
>
>> Maarten Wiltink wrote:
>>
>>> "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
>>> news:[EMAIL PROTECTED]
>>> [...]
>>>
I can imagine an RTT of 60-70ms. What I have difficulty imagining is
using such a source to synch with
Brian Utterback wrote:
[]
> I mis-spoke. It is actually the case that NTP prefers the sample of
> the eight from any one single source that has the least delay. After
> the sample is chosen, the samples from all the servers are then
> subjected to different criteria to determine which will be the f
David J Taylor wrote:
> Brian Utterback wrote:
> []
>> Which is why NTP prefers the source with the smallest delay. The
>> system I am using has servers whose delays are 51ms to 94. I can't
>> find any closer. On my company LAN, the delays range from 16ms to
>> 87ms. The offsets of all these server
Dennis Hilberg, Jr. wrote:
> David J Taylor wrote:
>> Brian Utterback wrote:
>> []
>>> Which is why NTP prefers the source with the smallest delay. The
>>> system I am using has servers whose delays are 51ms to 94. I can't
>>> find any closer. On my company LAN, the delays range from 16ms to
>>> 87
David J Taylor wrote:
> Brian Utterback wrote:
> []
>> Which is why NTP prefers the source with the smallest delay. The
>> system I am using has servers whose delays are 51ms to 94. I can't
>> find any closer. On my company LAN, the delays range from 16ms to
>> 87ms. The offsets of all these server
Brian Utterback wrote:
[]
> Which is why NTP prefers the source with the smallest delay. The
> system I am using has servers whose delays are 51ms to 94. I can't
> find any closer. On my company LAN, the delays range from 16ms to
> 87ms. The offsets of all these servers agree to within 9ms. Sure, I
Richard B. Gilbert wrote:
> Maarten Wiltink wrote:
>> "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> [...]
>>
>>> I can imagine an RTT of 60-70ms. What I have difficulty imagining is
>>> using such a source to synch with.
>>
>>
>> Pfft. Kids these days.
>>
>
Maarten Wiltink wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> [...]
>
>>I can imagine an RTT of 60-70ms. What I have difficulty imagining is
>>using such a source to synch with.
>
>
> Pfft. Kids these days.
>
> (There's nothing wrong with an RTT
"Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[...]
> I can imagine an RTT of 60-70ms. What I have difficulty imagining is
> using such a source to synch with.
Pfft. Kids these days.
(There's nothing wrong with an RTT of 60 to 70 ms per se. For example, if
it w
Brian Utterback wrote:
> Unruh wrote:
>
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>
>>> Unruh,
>>
>>
>>> It would seem self evident from the equations that minimizing the
>>> delay variance truly does minimize the offset variance. Further
>>> evidence of that is in the raw versus filtered
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
>> Unruh,
>
>> It would seem self evident from the equations that minimizing the delay
>> variance truly does minimize the offset variance. Further evidence of
>> that is in the raw versus filtered offset graphs in the architecture
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Unruh,
>It would seem self evident from the equations that minimizing the delay
>variance truly does minimize the offset variance. Further evidence of
>that is in the raw versus filtered offset graphs in the architecture
>briefings. If nothing else
Unruh,
It would seem self evident from the equations that minimizing the delay
variance truly does minimize the offset variance. Further evidence of
that is in the raw versus filtered offset graphs in the architecture
briefings. If nothing else, the filter reduces the variance by some 10
dB. M
Unruh wrote:
> I am also a little bit surprized that it is the delay that is used and not
> the total roundtrip time. As I seem to read it, the delay is (t4-t3+t2-t1)
> ie, it does not take into account the delay within the far machinei (eg
> t4-t1), but
> only propagation delay. I would expect th
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Danny,
>True; there is an old RFC or IEN that reports the results with varying
>numbers of clock filter stages, from which the number eight was the
>best. Keep in mind these experiments were long ago and with, as I
>remember, ARPAnet sources. The c
Danny,
True; there is an old RFC or IEN that reports the results with varying
numbers of clock filter stages, from which the number eight was the
best. Keep in mind these experiments were long ago and with, as I
remember, ARPAnet sources. The choice might be different today, but
probably would
[EMAIL PROTECTED] (Danny Mayer) writes:
>Unruh wrote:
>> [EMAIL PROTECTED] (Danny Mayer) writes:
>>
>>> Unruh wrote:
Brian Utterback <[EMAIL PROTECTED]> writes:
> Unruh wrote:
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>> You might not have noticed a couple of crucial
Unruh wrote:
> [EMAIL PROTECTED] (Danny Mayer) writes:
>
>> Unruh wrote:
>>> Brian Utterback <[EMAIL PROTECTED]> writes:
>>>
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>> You might not have noticed a couple of crucial issues in the clock
>> filter code.
> I d
[EMAIL PROTECTED] (Danny Mayer) writes:
>Unruh wrote:
>> Brian Utterback <[EMAIL PROTECTED]> writes:
>>
>>> Unruh wrote:
"David L. Mills" <[EMAIL PROTECTED]> writes:
>>
> You might not have noticed a couple of crucial issues in the clock
> filter code.
I did notice them all. T
Unruh wrote:
> Brian Utterback <[EMAIL PROTECTED]> writes:
>
>> Unruh wrote:
>>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
You might not have noticed a couple of crucial issues in the clock
filter code.
>>> I did notice them all. Thus my caveate. However throwing away 80% of the
>
Brian Utterback <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>> You might not have noticed a couple of crucial issues in the clock
>>> filter code.
>>
>> I did notice them all. Thus my caveate. However throwing away 80% of the
>> precious data you h
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>> You might not have noticed a couple of crucial issues in the clock
>> filter code.
>
> I did notice them all. Thus my caveate. However throwing away 80% of the
> precious data you have seems excessive.
But it isn't really. It would
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Root,
>You could have saved a lot of time sweating the code if you looked at
>the briefings. See especially the before and after time series and note
>the 10 dB improvement in S/N.
I am sorry, but looking at the code is far simpler than trying to f
Root,
You could have saved a lot of time sweating the code if you looked at
the briefings. See especially the before and after time series and note
the 10 dB improvement in S/N.
You might not have noticed a couple of crucial issues in the clock
filter code.
1. The basic principle is to select
OK, having looked at the code, I see what it is doing. It essentially
takes the measurement with the shortest delay in the past 8 measurements.
If that measurement happens to be the current one, it is actually used
in the clock loop. (Yes, I know this characterisation of the clock filter is
cr
Having been testing ntp, I was looking at the peerstats file. Here is a
sequence of such measurements.
54489 29187.448 137.82.1.3 9414 0.005089025 0.016225398 0.067088246 0.001122070
54489 29269.446 142.103.234.11 9614 0.003231929 0.015419416 0.009606450
0.001005171
54489 29316.445 137.82.1.3 941
53 matches
Mail list logo
