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 change
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 not
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 cross the Allan
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 undoubtedly correct. I was
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
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
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 inherited
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
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 from 16ms to
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
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 as well-- ie
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 nothing
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 the source with the
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 replied to the
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.
recent,
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 I
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
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
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. My
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 that Unruh
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.
(There's nothing wrong
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
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 servers agree
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
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
87ms. The offsets
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 raw versus filtered offset
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 offset graphs in the
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 choice
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 that
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.
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, the
[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 issues in the clock
filter code.
I
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
[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. Thus my caveate. However throwing
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 be if there
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 find
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 have seems excessive.
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
38 matches
Mail list logo
