"Unruh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> David L. Mills wrote:
>>> Unless the computer clock intrinsic frequency error is huge, the
>>> only time the 500-PPM kicks in is with a 100-ms step transient and
>>> poll interval 16 s. The loop still works if it hits the stops
Unruh <[EMAIL PROTECTED]> writes:
>weekends. Lots of power at 10^-5 Hz and harmonics, and .7 10^-8Hz.-- more
>than would be predicted by 1/f
10^-5Hz is about once per day. I'm not sure what .7 10^8Hz is - it
seems to be about once every 4.5 years? I would have assumed you'd
get power around 10^-5
[EMAIL PROTECTED] (Danny Mayer) writes:
>David L. Mills wrote:
>> Danny,
>>
>> It doesn't stop working; it just clamps whatever it gets to +-500 PPM as
>> appropriate. If the intrinsic error is greater than 500 PPM, the loop
>> will do what it can with the residual it can't correct showing as a
[EMAIL PROTECTED] (David Malone) writes:
>Unruh <[EMAIL PROTECTED]> writes:
>>weekends. Lots of power at 10^-5 Hz and harmonics, and .7 10^-8Hz.-- more
>>than would be predicted by 1/f
>10^-5Hz is about once per day. I'm not sure what .7 10^8Hz is - it
>seems to be about once every 4.5 years? I
"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
Unruh wrote:
> [EMAIL PROTECTED] (Danny Mayer) writes:
>
>> David L. Mills wrote:
>>> Danny,
>>>
>>> It doesn't stop working; it just clamps whatever it gets to +-500 PPM as
>>> appropriate. If the intrinsic error is greater than 500 PPM, the loop
>>> will do what it can with the residual it can
What was the problem?
On Mon, 28 Jan 2008, Danny Mayer wrote:
> Unruh wrote:
>> [EMAIL PROTECTED] (Danny Mayer) writes:
>>
>> > David L. Mills wrote:
>> > > Danny,
>> > >
>> > > It doesn't stop working; it just clamps whatever it gets to +-500 PPM
>> > > as appropriate. If the intrinsic e
Hello Dean and Hal,
On Tuesday, January 22, 2008 at 1:08:00 +, Dean S. Messing wrote:
> hal-usenet wrote:
>> try changing the code that reads the CMOS clock to spin in a loop
>> reading it until it changes. That will give you the time early in
>> the second.
The adjtimex code is already de
David,
We can argue about the Hurst parameter, which can't be truly random-walk
as I have assumed, but the approximation is valid up to lag times of at
least a week. However, as I have been cautioned, these plots are really
sensitive to spectral lines due to nonuniform sampling. I was very
car
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
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
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
Hi,
I am using ntpv4.2.0 and have a question about the system statistics
interpretation on my NTP server.
The ntp page on monitoring options lists 11 'system stat' fields as
follows.
http://www.eecis.udel.edu/~mills/ntp/html/monopt.html
MJD date
time past midnight
time since restart
packets recei
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
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
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
Maarten,
Maybe I didn't make myself clear. The case in question is when the
intrinsic frequency error of the computer clock is greater than 500 PPM,
in which case the discipline loop cannot compensate for the error. The
result is a systematic time offset error that cannot be driven to zero.
Th
Danny Mayer wrote:
>
> I'm not sure what it was you were trying to modify, the NTP v4 draft,
> the book, something else.
>
> I never said that you can consider ntpd in isolation. It's part of a
> network of ntpd servers and each is interacting with others. That's a
> very important part of th
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
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
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
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
>
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
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
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
> 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
>>> In article <[EMAIL PROTECTED]>, Steve Pearson <[EMAIL PROTECTED]> writes:
Steve> Hi, I am using ntpv4.2.0 and have a question about the system
Steve> statistics interpretation on my NTP server.
Steve> The ntp page on monitoring options lists 11 'system stat' fields as
Steve> follows. http://
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,
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
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 -
>
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
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
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,
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
Steve,
The best place to check the data is in the ntp_util.c file,
record_sys_stats() routine. I recently added another stat, but you might
not be using the most recent version.
The time since startup is in hours. The packets received are the total
number of packets received. The server packet
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
"David L. Mills" <[EMAIL PROTECTED]> writes:
>David,
>We can argue about the Hurst parameter, which can't be truly random-walk
>as I have assumed, but the approximation is valid up to lag times of at
>least a week. However, as I have been cautioned, these plots are really
>sensitive to spectra
"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
40 matches
Mail list logo
