>However, you give me an idea. Why not shut down the burst when the clock
>filter delivers the first sample? Gotta think about that.
That would make sense if the goal is to get an answer on a lossy
system.
I think the background in this discussion was not loss, but delays
in setting up arp/routi
Eric,
There are actually two burst modes IBURST when the server is unreachable
and BURST when it is. They are independent of each other and both can be
used at the same time. Currently, IBURST uses 6 packets, as that is a
couple more than to pass the distance threshold and synchronize the
cloc
Hal,
Not any more. Current NTPv4 sends the burst at 2-s intervals, mainly to
coordinate with Autokey opportunities and reduce the total number of
packets.
Dave
Hal Murray wrote:
>>I'll probably quite easily display my profound NTP ignorance here :)
>>But if there is assymetric delay stemming
On Mon, 28 Jan 2008 17:44:08 -0500, "Richard B. Gilbert"
<[EMAIL PROTECTED]> wrote for the entire planet to see:
>I thought that "burst" sent eight packets two seconds apart at each poll
>interval. It's not apprropriate for most situations. It was designed
>for systems making infrequent dialup
Eric wrote:
> On Mon, 28 Jan 2008 22:09:11 +, "David L. Mills" <[EMAIL PROTECTED]> wrote
> for the entire planet to see:
>
>
>>However, you give me an idea. Why not shut down the burst when the clock
>>filter delivers the first sample? Gotta think about that.
>>
>>Dave
>
>
> Hi Dave -
>
Eric wrote:
>
> I'm pleased to know I've provoked some new thoughts. If I understand your
> post, burst mode was intended to get enough (lousy) samples into and
> through the clock filters to allow for initial sync. Once the pipeline is
> loaded no more "extra" polls are needed.
>
That's ibu
On Mon, 28 Jan 2008 22:09:11 +, "David L. Mills" <[EMAIL PROTECTED]> wrote
for the entire planet to see:
>However, you give me an idea. Why not shut down the burst when the clock
>filter delivers the first sample? Gotta think about that.
>
>Dave
Hi Dave -
I'm pleased to know I've provoke
Hal Murray wrote:
>>I'll probably quite easily display my profound NTP ignorance here :)
>>But if there is assymetric delay stemming from an ARP resolution,
>>won't it affect all the packets in the burst? Unless the tranmission
>>time of the burst getting out of NTP is >> the ARP resolution time,
> The "burst" is sent at 1 second intervals. There should be lots of
> time for all the switches and routers to get their act in gear.
Ah, well chalk that one up to me being picky (perhaps even wrong :)
about network terminology then :) I always think of a burst as a
series of packets sent back-t
Eric,
Good suggestion. In either burst mode the code sends a single packet at
each poll interval, but sends the remaining packets only after receiving
a response; packets in the burst are sent at 2-s intervals. The most
cautious can set the headway to 512 s, in which a single packet is sent
at
>I'll probably quite easily display my profound NTP ignorance here :)
>But if there is assymetric delay stemming from an ARP resolution,
>won't it affect all the packets in the burst? Unless the tranmission
>time of the burst getting out of NTP is >> the ARP resolution time,
>the entire burst is
On Mon, 28 Jan 2008 21:39:17 + (UTC), Rick Jones <[EMAIL PROTECTED]>
wrote for the entire planet to see:
>Eric <[EMAIL PROTECTED]> wrote:
>> Of course, different manufacturers may have different methods of
>> detecting the cache miss and recovering from that, so it would be
>> hard to elimina
Brian Utterback <[EMAIL PROTECTED]> wrote:
> Rick Jones wrote:
> > Eric <[EMAIL PROTECTED]> wrote:
> >> Then there is the MAC cache in your switches, which generally
> >> purge after 1-5 minutes. This can often be adjusted higher, but
> >> that can sometimes cause issues for others when they are
>
Eric <[EMAIL PROTECTED]> wrote:
> You are probably right about the MAC cache miss not affecting
> timing. You are the resident switch guru here.
Scary thought :)
> Of course, different manufacturers may have different methods of
> detecting the cache miss and recovering from that, so it would be
Steve,
You might have missed my message about rate control on the hackers list.
The average headway for all packets, including those in a burst is
strictly controlled at 16 s. So, 1 packet in a "burst" at 16 s, 2 at 32
s, 4 at 64 and 8 at 128 s and higher. The default average headway can be
se
Rick Jones wrote:
> Eric <[EMAIL PROTECTED]> wrote:
>> Then there is the MAC cache in your switches, which generally purge
>> after 1-5 minutes. This can often be adjusted higher, but that can
>> sometimes cause issues for others when they are reconfiguring part
>> of the network.
>
> I suppose i
Eric <[EMAIL PROTECTED]> wrote:
> Then there is the MAC cache in your switches, which generally purge
> after 1-5 minutes. This can often be adjusted higher, but that can
> sometimes cause issues for others when they are reconfiguring part
> of the network.
I suppose if STP gets involved, but jus
Hi Rick -
You are probably right about the MAC cache miss not affecting timing. You
are the resident switch guru here.
Of course, different manufacturers may have different methods of detecting
the cache miss and recovering from that, so it would be hard to eliminate
that effect from considera
On 2008-01-28, David L. Mills <[EMAIL PROTECTED]> wrote:
> Eric wrote:
>
>> [---=| TOFU protection by t-prot: 72 lines snipped |=---]
>
> That case and the ones you describe are exactly what the NTP burst
> mode is designed for. The first packet in the burst carves the caches
> all along the route
Dave,
The problem Eric describes would seem to be most evident for LAN clients,
and on networks where there is already lots of traffic.
Recommending 'burst' for this case seems to me (without any experimental
evidence or even a read thru the code) to be counter-productive.
If a burstsize of 2 wo
On Mon, 28 Jan 2008 19:19:12 +, "David L. Mills" <[EMAIL PROTECTED]> wrote
for the entire planet to see:
>Eric,
>
>Many years ago the Proteon routers dropped the first packet after the
>cache timed out; that was a disaster. That case and the ones you
>describe are exactly what the NTP burst
Eric,
Many years ago the Proteon routers dropped the first packet after the
cache timed out; that was a disaster. That case and the ones you
describe are exactly what the NTP burst mode is designed for. The first
packet in the burst carves the caches all along the route and back. The
clock fil
On Sun, 20 Jan 2008 17:50:41 GMT, Unruh <[EMAIL PROTECTED]> wrote
for the entire planet to see:
>[EMAIL PROTECTED] (David Woolley) writes:
>
>>In article <[EMAIL PROTECTED]>,
>>Unruh <[EMAIL PROTECTED]> wrote:
>>> I would assume that ntp is giving these samples with long round trip very
>>> low
[EMAIL PROTECTED] (David Woolley) writes:
>In article <[EMAIL PROTECTED]>,
>Unruh <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (David Woolley) writes:
>> >Note that chrony seems not to have been updated for several years and its
>> Actually not true. The latest version 1.23 has just been rele
Unruh wrote:
>> Is there some problem in ntp?
>> ntp-4.2.0-31.2mdv2007.0
First, get a newer version of ntp installed. That's a postively ancient
version and well past it's best-used-by date.
Danny
___
questions mailing list
questions@lists.ntp.org
http
In article <[EMAIL PROTECTED]>,
Unruh <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (David Woolley) writes:
> >Note that chrony seems not to have been updated for several years and its
> Actually not true. The latest version 1.23 has just been released, but it
> is true that the support has beco
[EMAIL PROTECTED] (David Woolley) writes:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (David Woolley) wrote:
>> Pop corn spikes of less than 128ms are not ignored in the default
>> configuration. If, as I suspect, you only have one time source, they
>However I forgot that only the best
[EMAIL PROTECTED] (David Woolley) writes:
>In article <[EMAIL PROTECTED]>,
>Unruh <[EMAIL PROTECTED]> wrote:
>> but the offsets are still over 100 times worse than I was getting with
>> chrony. (Yes, I know, one suggestion is-- go back to chrony-- but the
>Note that chrony seems not to have been
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Woolley) wrote:
> Pop corn spikes of less than 128ms are not ignored in the default
> configuration. If, as I suspect, you only have one time source, they
However I forgot that only the best of the last 8 samples is used. Sample
quality i
In article <[EMAIL PROTECTED]>,
Unruh <[EMAIL PROTECTED]> wrote:
> but the offsets are still over 100 times worse than I was getting with
> chrony. (Yes, I know, one suggestion is-- go back to chrony-- but the
Note that chrony seems not to have been updated for several years and its
knocking copy
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> Unruh <[EMAIL PROTECTED]> writes:
>>
>>
>>>In trying to figure out whether it is chrony or the machine which is
>>>causing the oscillations in the rate on my systems, I decided to switch one
>>>to ntp. That system was withing 10us
Unruh wrote:
> Unruh <[EMAIL PROTECTED]> writes:
>
>
>>In trying to figure out whether it is chrony or the machine which is
>>causing the oscillations in the rate on my systems, I decided to switch one
>>to ntp. That system was withing 10usec of the "correct" time ( ie the time
>>as desgnated by
Unruh <[EMAIL PROTECTED]> writes:
>In trying to figure out whether it is chrony or the machine which is
>causing the oscillations in the rate on my systems, I decided to switch one
>to ntp. That system was withing 10usec of the "correct" time ( ie the time
>as desgnated by a GPS driven computer wi
In trying to figure out whether it is chrony or the machine which is
causing the oscillations in the rate on my systems, I decided to switch one
to ntp. That system was withing 10usec of the "correct" time ( ie the time
as desgnated by a GPS driven computer withing about 150usec roundtrip
network d
34 matches
Mail list logo
