On Wed, 30 Jan 2008, Danny Mayer wrote:
Unruh wrote:
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
Danny Mayer wrote:
Well of course. You are running Linux and losing interrupts. FreeBSD and
Lost interrupts are not the problem here and nothing about FreeBSD
should help (unless it runs the CPU permanently at full power).
___
questions mailing
David,
Cite: Judah Levine of NIST, personal communication. A few little
mistakes on my part proved him right.
Dave
[EMAIL PROTECTED] wrote:
In comp.protocols.time.ntp you write:
Hi Dave,
We can argue about the Hurst parameter, which can't be truly random-walk
as I have assumed, but the
[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 would
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't correct showing
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 error is greater than
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
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.
David L. Mills wrote:
It's easy to make your own Allan characteristic. Just let the computer
clock free-run for a couple of weeks and record the offset relative to a
known and stable standard, preferable at the smallest poll interval you
can. The PPS from a GPS receiver is an ideal source,
David L. Mills wrote:
Danny,
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; it just can't
drive the offset to zero.
Dave
Yes, I found
Danny Mayer wrote:
No, ntpd deliberately limits frequency changes to 500 PPM. That's hard
coded. You need to avoid using anything greater than that as Dave has
explained. That would be the reason why it taks ntpd longer to bring the
clock back to the right time.
Assuming that the static
David Woolley [EMAIL PROTECTED] wrote:
Petri Kaukasoina wrote:
Basically, it stepped time with ntpdate, slept 100 seconds and stepped time
again with ntpdate. From the time adjustment, the script calculated the
drift value and put that to the drift file. Again, the time offset always
stays
Petri Kaukasoina wrote:
David Woolley [EMAIL PROTECTED] wrote:
That has quite a lot of similarity with what ntpd itself does if it is
cold started with iburst. The only big difference is that it uses 900,
Hmm, I can't see that. I put in only one good time source with iburst,
deleted
David,
David Woolley wrote:
ISTR that time stamps on financial transactions are required to be
within two seconds of the correct time. With NTP that standard is not
too difficult to meet.
In 2006, it turns out that it was 3 seconds
http://tf.nist.gov/general/pdf/2125.pdf,
NIST is a US
Jan Ceuleers wrote:
NIST is a US government institution; might there perhaps be different
laws or regulations elsewhere in the world? Does anyone among the
readership here know?
I used the US case as that is the one that has come up on the newsgroup,
but I assume there are similar rules
Richard,
There were several different architecture computers considered in the
1995 and 1998 studies, incluing SPARC, Alpha, Intel and several lab
instruments. All oscillators conformed to a simple model: white phase
noise (slope -1) below the intercept, random-walk frequency noise (slope
David L. Mills wrote:
Richard,
There were several different architecture computers considered in the
1995 and 1998 studies, incluing SPARC, Alpha, Intel and several lab
instruments. All oscillators conformed to a simple model: white phase
noise (slope -1) below the intercept, random-walk
Danny,
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; it just can't
drive the offset to zero.
Dave
Danny Mayer wrote:
Unruh wrote:
David L.
Petru,
The default 900-s stepout interval was originally determined by the time
an old Spectracom WWVB receiver took to regain synchronization after a
leapsecond and should probably be reduced. It can of course be tinkere.
During the initial training period the time is not disciplined other
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
David L. Mills [EMAIL PROTECTED] writes:
Reading your claims literally, chrony would have to slew the clock
considerably greater than the 500 PPM provided by the standard Unix
adjtime() system call. Please explain how it does that.
David J Taylor [EMAIL PROTECTED] writes:
Richard B. Gilbert wrote:
[]
Computer Network Time Synchronization: The Network Time Protocol by
David L. Mills (Hardcover - Mar 24, 2006)
Available from Amazon.com. You may be able to find a copy at a
University Book store. Be prepared for Sticker
David,
I don't know your version, but the TSET state was removed some time ago
and your comments are different from the current source. It's really
hard to test the discipline under all conceivable conditions. Now and
then somebody cooks up a case considered very unlikely, like Solaris
David Woolley [EMAIL PROTECTED] writes:
What I was expecting was for it to unconditionally do both frequency and
phase calibration, in the absence of the drift file. I presume that
chrony does a correction on the first couple of samples and then refines it.
Yes. Actually it does a
Richard B. Gilbert [EMAIL PROTECTED] writes:
David,
Why are you telling me this? My contribution to this thread consisted
of the above exposition of the publication data and availability of Das
Buch.
He is not good at following attributions in threads. He addressed it to you
because he read
David L. Mills wrote:
5. This flap about the speed of convergence has become silly. Most of us
are less concerned about squeezing to the low microseconds in four
Have you done the market surveys to confirm this? I don't have the
resources or time to do that, but my impression from the sort
Root,
Right; 5 microseconds per timer interrupt at 100 Hz is 0.5 ms/s. That
was the original Unix kernel value.
Dave
root wrote:
David L. Mills [EMAIL PROTECTED] writes:
snip
___
questions mailing list
questions@lists.ntp.org
Petri Kaukasoina wrote:
Basically, it stepped time with ntpdate, slept 100 seconds and stepped time
again with ntpdate. From the time adjustment, the script calculated the
drift value and put that to the drift file. Again, the time offset always
stays below 1 ms.
That has quite a lot of
David Woolley wrote:
David L. Mills wrote:
5. This flap about the speed of convergence has become silly. Most of
us are less concerned about squeezing to the low microseconds in four
Have you done the market surveys to confirm this? I don't have the
resources or time to do that, but
Daivd,
Well, I have done a market survey of sorts, if you can count my
consulting clients. There seems general agreement that 1 ms is a good
target, but there is a wide range of expecttions on how quickly that
must be achieved. Actually, if the TOY chip is within 1 PPM and the
downtime is
Danny, I agree with everything you said except:
Danny Mayer wrote:
I agree. I don't see how it can be a specification violation. The
biggest factor is how well it keeps time. A caesium clock keeps good
time but you wouldn't say that it violates the specification.
When we first started
David Woolley [EMAIL PROTECTED] writes:
David L. Mills wrote:
The NTP discipline is basically a type-II feedback control system. Your
training should recall exactly how such a loop works and how it responds
to a 50-ms step. Eleven seconds after NTP comes up the mitigation
You both have
Brian,
The 500 PPM limit in the reference implementation was originally set to
match the adjtime() slew of that value, but so many kernels have been
hacked adjtime that this might not even be appropriate now. The bottom
line is that an update given to adjtime() should be completed before the
Unruh wrote:
I am sorry, but this is idiotic. The ONLY requirement should be that the
communication protocol is implimented properly and that the clock is
Only a very small part of the mandatory parts of the NTP specification
describe the wire formats. The pool is an NTP network, not an SNTP
David J Taylor [EMAIL PROTECTED] writes:
chrony falls at the first hurdle for me - there appears to be no native
Windows implementation.
Correct. chrony is not implimented on nearly as many platforms as ntp.
There were plans once upon a time, but life got in Curnoe's way.
Anyway, I am NOT
Unruh wrote:
David J Taylor
[EMAIL PROTECTED] writes:
chrony falls at the first hurdle for me - there appears to be no
native Windows implementation.
Correct. chrony is not implimented on nearly as many platforms as ntp.
There were plans once upon a time, but life got in Curnoe's way.
Maarten Wiltink [EMAIL PROTECTED] writes:
Unruh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
David J Taylor
[EMAIL PROTECTED] writes:
chrony falls at the first hurdle for me - there appears to be no native
Windows implementation.
Correct. chrony is not implimented on nearly as
Unruh,
The NTP discipline is basically a type-II feedback control system. Your
training should recall exactly how such a loop works and how it responds
to a 50-ms step. Eleven seconds after NTP comes up the mitigation
algorithms present that transient to the loop and what happens
afterwards
David L. Mills [EMAIL PROTECTED] writes:
Unruh,
I'm sure you know that an ntpd simulator is included in the NTP software
distribution. It handles multiple simultaneous servers using the same
algorithms as in the working daemon. We use it to test the daemon
response to all kinds of possible
Unruh wrote:
situation, but have no reasons for that worry. The very worst case is if
the system runs for a while on very short poll intervals, and then suddenly
has very log poll intervals. The short period estimation of the drift is
not a good estimator of the long period drift. But I
Guys,
Sure, I'm stubborn as a bull. The laws of physics make me so.
I am dismissing any comparisons between ntpd and crony or any other
vehicle unless the comparison includes substantially all the scenarios
that ntpd is designed to work with. The protocol is specifically
designed to work over
Guys,
Reprinted without permission from the draft spec:
14. Simple Network Time Protocol (SNTP)
Primary servers and clients complying with a subset of NTP, called
the Simple Network Time Protocol (SNTPv4) [2], do not need to
implement the mitigation algorithms described in Section
David L. Mills [EMAIL PROTECTED] writes:
Unruh,
This answers my earlier question. I can't believe this is so crude and
dangerous. you really need to provide an analysis on the errors this
creates when reading the clock during the slew. The problem is not the
residual time offset but the rate
Brian Utterback [EMAIL PROTECTED] writes:
Unruh wrote:
situation, but have no reasons for that worry. The very worst case is if
the system runs for a while on very short poll intervals, and then suddenly
has very log poll intervals. The short period estimation of the drift is
not a good
David L. Mills wrote:
The NTP discipline is basically a type-II feedback control system. Your
training should recall exactly how such a loop works and how it responds
to a 50-ms step. Eleven seconds after NTP comes up the mitigation
You both have problems here.
Dave Mills: your problem
Just an update: I started chrony with a 60ms offset. It had the right drift
file. It took about 1 min ( having collected about 4 samples from the
servers at minpoll 4) to drive the offset down to about 100 usec (Yes, a
1000 fold improvement in about 50 sec.) Ie, the time constant for
correction
Harlan Stenn wrote:
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Danny Mayer) writes:
Danny Harlan Stenn wrote:
Unruh Unfortunately I cannot run both ntp and chrony on the same system at
Unruh the same time.
Bill,
Exactly why can you not run ntpd and chrony on the same system at the
[EMAIL PROTECTED] (Danny Mayer) writes:
...
And as Bill said, it would be Swell if there was a way to do this using, eg,
virtual machines so that we could test them that way. Better yet, it would
be nice to have a simulator framework where we could run these tests faster
than in real-time.
Unruh wrote:
[EMAIL PROTECTED] (Danny Mayer) writes:
Virtual machines buys you the same problem as above. Even on a virtual
machine there's only one clock. You can have only one application
discipline that clock never mind how many virtual machines are running.
Don't be fooled by the
Maarten,
I turn my machines off and on all the time and the clock is set from the
server within 11 seconds after starting ntpd. If I didn't use burst
mode, that would take four minutes. Golly.
Please understand the difference between impulse response and poll
interval. It is true that it
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
[EMAIL PROTECTED] (Danny Mayer) writes:
Virtual machines buys you the same problem as above. Even on a virtual
machine there's only one clock. You can have only one application
discipline that clock never mind how many virtual machines
Brian Utterback [EMAIL PROTECTED] writes:
Unruh wrote:
Just an update: I started chrony with a 60ms offset. It had the right drift
file. It took about 1 min ( having collected about 4 samples from the
servers at minpoll 4) to drive the offset down to about 100 usec (Yes, a
1000 fold
David L. Mills [EMAIL PROTECTED] writes:
Maarten,
I turn my machines off and on all the time and the clock is set from the
server within 11 seconds after starting ntpd. If I didn't use burst
mode, that would take four minutes. Golly.
When you say the clock is set what do you mean? With what
Unruh wrote:
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
[EMAIL PROTECTED] (Danny Mayer) writes:
Virtual machines buys you the same problem as above. Even on a virtual
machine there's only one clock. You can have only one application
discipline that clock never mind how many
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Danny Mayer) writes:
Danny You do realize that there are timers built into the code so in order
Danny to run faster you'd need to figure out how to change the timers to
Danny work that way?
When was the last time you looked at the ntpdsim code?
[EMAIL PROTECTED] (Danny Mayer) writes:
Harlan Stenn wrote:
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Danny Mayer) writes:
Danny Harlan Stenn wrote:
Unruh Unfortunately I cannot run both ntp and chrony on the same system at
Unruh the same time.
Bill,
Exactly why can you not run
chrony falls at the first hurdle for me - there appears to be no native
Windows implementation.
David
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Unruh [EMAIL PROTECTED] wrote:
After I collect more data on steady state, I will rerun startups both with
no drift file and a bad drift file to see how fast the convergence is with
4.2.4.
Hi,
On recent Linux kernels, I think the drift file is always bad after reboot.
HZ=100, no dynamic ticks
Unruh,
It may help to review the material on Allan deviation and noise
modelling in the briefings on the NTP project page. If you are down in
the low microsecond range with poll intervals much over 64 s, expect to
see a frequency sway due to small temperature variations less than one
degree
Guys,
I haven't read every word on this thread, but all I can contribute is
that nothing reported here is anything like my experience here. Our
servers pogo.udel.edu and rackety.udel.edu are synchronized via GPS and
PPS. I invite the skeptics to peek at them from time to time. I describe
Unruh,
Please read the specification. The offset statistic is the
maximum-likelihood estimate of the remote clock offset relative to the
local clock and the sign really does matter. The best way to describe
this and keep the sign straight is to assume the signed offset is the
quantity in
Unruh,
The basic clock discipline feedback loop has been unchanged since 1992,
although minor changes have been made to improve behavior in very long
poll intervals. The only radical change has been using a preliminary
15-minute initial frequency computation when no frequency file is
Unruh,
As you can see from the Allan deviation plots in the briefings on the
NTP project page, it does no good whatsoever to average over ten hours;
the observations are completely uncorrelated over that lag. The Allan
intercept, or best averaging time, is more like twenty minutes to two
Petri,
I knew Linux was broken, but what you report suggests it is broken
beyond my wildest imagination. First, I do know Linux supports the
precision time kernel, as it has the ntp_adjtime() system call, even if
it is buried in a wrapper. If so, and assuming that syscall is
implemented
David L. Mills [EMAIL PROTECTED] writes:
Unruh,
It may help to review the material on Allan deviation and noise
modelling in the briefings on the NTP project page. If you are down in
the low microsecond range with poll intervals much over 64 s, expect to
see a frequency sway due to small
David L. Mills [EMAIL PROTECTED] writes:
In principle, comparing ntpd and chrony or any other vehicle is
meaninful only if using the same hardware, operating system and poll
interval. I assume chrony has done its homework and optimized the time
constant for the given poll interval. I am on a
David L. Mills [EMAIL PROTECTED] writes:
Unruh,
Please read the specification. The offset statistic is the
maximum-likelihood estimate of the remote clock offset relative to the
local clock and the sign really does matter. The best way to describe
this and keep the sign straight is to assume
David L. Mills [EMAIL PROTECTED] writes:
Unruh,
The basic clock discipline feedback loop has been unchanged since 1992,
although minor changes have been made to improve behavior in very long
poll intervals. The only radical change has been using a preliminary
15-minute initial frequency
Hey Danny!
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Unruh Unfortunately I cannot run both ntp and chrony on the same system at
Unruh the same time.
Bill,
Exactly why can you not run ntpd and chrony on the same system at the same
time?
I want the ability to run multiple
Unruh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
David L. Mills [EMAIL PROTECTED] writes:
There are lots of ways to measure the loop transient response. The
easiest way is to set the clock some 50-100 ms off from some stable
source (not necessarily accurate) and watch the loop
David L. Mills wrote:
As for offset should be much larger than the error, be careful here.
By error I assume you mean what ntpq rv shows as jitter. The best case
No. By error I meant a measurement that neither ntpd nor chrony can
actually make, namely the difference between the user's
Harlan Stenn [EMAIL PROTECTED] writes:
Hey Danny!
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Unruh Unfortunately I cannot run both ntp and chrony on the same system at
Unruh the same time.
Bill,
Exactly why can you not run ntpd and chrony on the same system at the same
On Mon, 21 Jan 2008, Danny Mayer wrote:
Unruh wrote:
All I say is that the experiments I have carried out show that ntp is slow
to converge if it starts of badly, and leaves the offset scatter larger
than chrony does. It does have a smaller scatter in the rate.
But you are using an
On recent Linux kernels, I think the drift file is always bad after reboot.
HZ=100, no dynamic ticks aka tickless system (CONFIG_NO_HZ not set). I think
I even tried with a kernel command line option lpj= but it didn't help.
If the system is rebooted, ntpd stabilizes to a new different drift
Harlan Stenn wrote:
Hey Danny!
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Unruh Unfortunately I cannot run both ntp and chrony on the same system at
Unruh the same time.
Bill,
Exactly why can you not run ntpd and chrony on the same system at the same
time?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Danny Mayer) writes:
Danny Harlan Stenn wrote:
Unruh Unfortunately I cannot run both ntp and chrony on the same system at
Unruh the same time.
Bill,
Exactly why can you not run ntpd and chrony on the same system at the
same time?
Danny
[EMAIL PROTECTED] (David Woolley) writes:
In article [EMAIL PROTECTED],
Bill Unruh [EMAIL PROTECTED] wrote:
Offset error:
NTP: Mean=-3.1usec, Std Dev=63.1usec
If offset is the value reported by ntpq, please note that, when ntpd
is locked up, this is an indication of the instantaneous
[EMAIL PROTECTED] (David Woolley) writes:
In article [EMAIL PROTECTED],
Unruh [EMAIL PROTECTED] wrote:
No, the offset is the value reported in loopstats.
Same thing. If chrony is reporting the same measurements, neither set of
measurements is particularly valid. You need to measure the
Unruh wrote:
correction applied on that sample.
No, this is offset as measured by the ntp procedure ( (t1+t4-t2-t3)/2 )
No, that's wrong. It is very carefully described in the NTPv4 draft
section 8 (p27):
theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]
Not only do you have the wrong
Unruh wrote:
All I say is that the experiments I have carried out show that ntp is slow
to converge if it starts of badly, and leaves the offset scatter larger
than chrony does. It does have a smaller scatter in the rate.
But you are using an extremely old version of ntp and things have
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
All I say is that the experiments I have carried out show that ntp is slow
to converge if it starts of badly, and leaves the offset scatter larger
than chrony does. It does have a smaller scatter in the rate.
But you are using an
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
correction applied on that sample.
No, this is offset as measured by the ntp procedure ( (t1+t4-t2-t3)/2 )
No, that's wrong. It is very carefully described in the NTPv4 draft
section 8 (p27):
theta = T(B) - T(A) = 1/2 * [(T2-T1) +
82 matches
Mail list logo
