Hello Ulrich,
Ulrich Windl wrote:
Is that too simple?
msyslog(LOG_ERR, authentication key %lu unknown,
(unsigned long)sys_authkey);
Oooh, of course that't the best fix.
I have already prepared a patch but I must have been blind that I didn't see
the obvious
Ulrich Windl wrote:
Unruh [EMAIL PROTECTED] writes:
In ntpdate.c around line 542 (4.2.4p4)is the sequence
if (!authistrusted(sys_authkey)) {
char buf[10];
(void) sprintf(buf, %lu, (unsigned long)sys_authkey);
msyslog(LOG_ERR, authentication key %s unknown, buf);
Unruh [EMAIL PROTECTED] writes:
In ntpdate.c around line 542 (4.2.4p4)is the sequence
if (!authistrusted(sys_authkey)) {
char buf[10];
(void) sprintf(buf, %lu, (unsigned long)sys_authkey);
msyslog(LOG_ERR, authentication key %s unknown, buf);
Is that too simple?
David L. Mills [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Is there also a random backoff after an increase of the polling
interval?
No. However, there is a small dither of a few percent at all poll
intervals to resist self-synchronization.
The natural behavior of a bunch of
Hal Murray wrote:
20 ms sounds like a typical DSL link. That 1ms accuracy goes out
the window if you are doing a big download. (At least on my DSL
link.)
People don't generally do big downloads during the boot of a machine!
On a big network, the most likely reason for rebooting a
David L. Mills [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
No, there is no random delay at startup. Each association starts one
second after the previous one. The random backoff occurs only after
a step.
Is there also a random backoff after an increase of the polling
interval?
Maarten,
The natural behavior of a bunch of oscillators near the same frequency
is to become one giant phase-locked oscillator. Adding a bit of random
fuzz at each poll turns each oscillator into a mini random-walk which
breaks up that tendency. The fuzz is not a lot, like 10 percent.
Dave
Dave,
David L. Mills wrote:
Serge,
The behavior after a step is deliberate. The iburst volley after a step
is delayed a random fraction of the poll interval to avoid implosion
at a busy server. An additional delay may be enforced to avoid violating
the headway restrictions. This is not
Harlan Stenn wrote:
For the general use case (LAN and/or WAN and/or jerky path) ntpd behaves
well.
We are talking typical rather than general cases. In the typical case,
1ms after 1 second is a reasonable expectation on a WAN, especially when
a site is restarting, e.g. after a power
Dave,
David L. Mills wrote:
[...]
The ntpd time constant is purposely set somewhat large at 2000 s, which
results in a risetime of about 3000 s. This is a compromise for stable
acquisition for herky-jerky Internet paths and speed of convergence for
LANs. For typical Internet paths the Allan
Unruh wrote:
David Woolley [EMAIL PROTECTED] writes:
Harlan Stenn wrote:
For the general use case (LAN and/or WAN and/or jerky path) ntpd behaves
well.
We are talking typical rather than general cases. In the typical case,
1ms after 1 second is a reasonable expectation on a WAN,
Bill,
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Unruh Why not? The power comes on on your computer farm of 2000 machines,
Unruh all the clients are the same type so the bootup sequence is
Unruh identical. They all start ntp at the same time, to within a second or
Unruh so.
Maarten,
No. However, there is a small dither of a few percent at all poll
intervals to resist self-synchronization.
Dave
Maarten Wiltink wrote:
David L. Mills [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
No, there is no random delay at startup. Each association starts one
Unruh,
Depends who the clients are. An ntpd client will not come up in the
first second, although successive associations will come up at 2-s
intervals. I would not expect 2000 clients to come up at the same exact
time anyway due ordinary latency variations in the boot process. I would
be
I was talking about what people could expect from software that behaved
well; I think you are describing what ntpd actually does here. My point
was that ntpd's ability to tolerate really rotten links is irrelevant
for most users, who are only about 20ms away from their ISP's time
server, and
Hello David,
On Tuesday, February 12, 2008 at 15:04:45 +, David L. Mills wrote:
Serge Bets wrote:
ntpd -q can make use of the driftfile to set the kernel frequency
That was removed as a significant security hazard.
Why exactly?
If you want to rxplicitly set the frequency, use ntptime
Martin Burnicki wrote:
Wouldn't it make sense to adjust the time constant depending on the time
after startup, and/or the quality of the responses from the upstream
servers?
It does get adjusted. We are talking about the minimum value!
___
Martin Burnicki [EMAIL PROTECTED] writes:
Dave,
David L. Mills wrote:
Serge,
The behavior after a step is deliberate. The iburst volley after a step
is delayed a random fraction of the poll interval to avoid implosion
at a busy server. An additional delay may be enforced to avoid
Serge,
That was removed as a significant security hazard. If you want to
rxplicitly set the frequency, use ntptime -f. Ths scheme is designed so
you can run ntpd until the kernel frequency has stabilized, then kill
ntpd and run SNTP client at regular intervals. I surely wouldn't
recommend
Hello David,
On Tuesday, February 12, 2008 at 3:03:37 +, David L. Mills wrote:
The behavior after a step is deliberate. The iburst volley after a
step is delayed a random fraction of the poll interval to avoid
implosion at a busy server.
Ah OK, I understand now! Thank you.
This makes
Hello David,
On Tuesday, February 12, 2008 at 2:43:06 +, David L. Mills wrote:
Just for clarity, neither the daemon nor kernel frequency is adjusted
in any way with ntpd -q.
ntpd -q can make use of the driftfile to set the kernel frequency:
| # ntpd -q -d | grep frequency
|
Hello Harlan,
On Tuesday, February 12, 2008 at 3:22:59 +, Harlan Stenn wrote:
Interesting script - thanks. Would you like me to put it in the
distribution?
Excellent idea! As contrib example, or installed in bindir along with
ntp-wait?
what benefit do we get by using the script to
Martin,
No, there is no random delay at startup. Each association starts one
second after the previous one. The random backoff occurs only after a
step. The fact that the initial backoff is small means that the client
population is crudely synchronized and could well gang up after a step.
ntdate -b steps the clock. That's the function under discussion.
The one that's used nearly universally in boot sequences.
-Tom
David L. Mills wrote:
Guys,
There seems to some misinformation here.
Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
After that, stock
Harlan Stenn [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes:
David Harlan Stenn wrote:
Why would ntpd be exiting during a warm start?
David Because we are discussing using it with the -q option. If you just
David use -g, it will take a lot
Hello David,
On Monday, February 11, 2008 at 19:03:36 +, David L. Mills wrote:
Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
After that, stock Unix adjtime() slews the clock at rate 500 PPM,
which indeed could take 256 s for an initial offset of 128 ms.
And on
In article [EMAIL PROTECTED], David L. Mills [EMAIL PROTECTED] writes:
David Serge, I didn't believe what you said until I checked the code and it
David does increase the correction by 50%, but limits the overshoot to 50
David ms. Why in the would it overshoot at all?
Dave, this is one of the
In article [EMAIL PROTECTED], Tom Smith [EMAIL PROTECTED] writes:
Tom ntdate -b steps the clock. That's the function under discussion. The
Tom one that's used nearly universally in boot sequences.
Then change the boot sequence.
Using ntpdate -b to step the clock before starting ntpd is no
Serge,
I didn't believe what you said until I checked the code and it does
increase the correction by 50%, but limits the overshoot to 50 ms. Why
in the would it overshoot at all?
Dave
Serge Bets wrote:
Hello David,
On Monday, February 11, 2008 at 19:03:36 +, David L. Mills wrote:
Serge,
Interesting script - thanks. Would you like me to put it in the
distribution?
This brings up an underlying question. It is possible for events to unfold
in a way that while in state 4, events will be such that there will be
future wiggles. Some of them may even take us out of state 4.
Guys,
Just for clarity, neither the daemon nor kernel frequency is adjusted in
any way with ntpd -q.
Serge Bets wrote:
On Monday, February 11, 2008 at 7:38:53 +, David Woolley wrote:
Serge Bets wrote:
the kind of slew (singleshot) initiated by ntpd -q comes *above* the
usual
Hello Harlan,
On Monday, February 11, 2008 at 0:33:36 +, Harlan Stenn wrote:
1) what are you trying to accomplish by the sequence:
ntpd -gq ; wait a bit; ntpd
that you do not get with:
ntpd -g ; ntp-wait
Let's compare. I used a some weeks old ntp-dev 4.2.5p95, because the
latest
Tom,
With tinker step .001 in the configuration file, ntpd -q will step the
clock, unless the residual offset is less than .001 s. This is probably
more complexity than you can stand. Just keep using ntpdate and be happy.
Dave
Tom Smith wrote:
ntdate -b steps the clock. That's the function
Harlan Stenn [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Harlan In terms of the behavior model of ntp, state 4 is as good as it
Harlan gets. You are in the right ballpark.
Unruh And as has been commented on numerous times, ntp is state 4 is very
I've tried to keep quiet and bite my tongue at this whole ntp vs chrony
thing... But something has been nagging me in the back of my head that i
juat have to know the answer to...
How are you measuring your results? From what I've skimmed over you are
simply using each program's own generated
So, no, I am comparing apples to apples ( the offsets as determined from
the ntp packet exchange mechanism which both use and both report).
Another approach is to setup a 3rd machine to watch both.
--
These are my opinions, not necessarily my employer's. I hate spam.
Guys,
There seems to some misinformation here.
Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
After that, stock Unix adjtime() slews the clock at rate 500 PPM, which
indeed could take 256 s for an initial offset of 128 ms. A prudent
response would be to measure the
In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes:
David Harlan Stenn wrote:
Why would ntpd be exiting during a warm start?
David Because we are discussing using it with the -q option. If you just
David use -g, it will take a lot longer to converge within a few
David
Hello David,
On Sunday, February 10, 2008 at 10:55:29 +, David Woolley wrote:
However, if it wasn't stepped, because it was already within 128ms, it
will be slewing at maximum rate. Allowing 100ppm for motherboard
tolerances, that means that it can take up to a further 320 seconds to
In article [EMAIL PROTECTED], Serge Bets [EMAIL PROTECTED] writes:
David I don't believe it would be safe to start ntpd in normal mode within
David that period.
Serge Indeed: the daemon then behaves strangely, not sane at all. Last year
Serge I published here an awk script calling ntpd -gq and
Serge Bets wrote:
Only 256 seconds maximum, because the kind of slew (singleshot)
initiated by ntpd -q comes *above* the usual frequency correction
already annihiliating the motherboard error.
That assumes the use of the kernel time discipline, alhtough if you
don't have that, it is even
David L. Mills wrote:
Harlan,
You make some good points. However, if folks want SNTP from here I think
they would prefer it in its own distribution rather than bundle it with
the huge NTP distribution. You can make a strong argument to host here
I don't think you are ever going to get
David Woolley wrote:
David L. Mills wrote:
Harlan,
You make some good points. However, if folks want SNTP from here I
think they would prefer it in its own distribution rather than bundle
it with the huge NTP distribution. You can make a strong argument to
host here
I don't think
Richard B. Gilbert wrote:
David Woolley wrote:
David L. Mills wrote:
Harlan,
You make some good points. However, if folks want SNTP from here I
think they would prefer it in its own distribution rather than bundle
it with the huge NTP distribution. You can make a strong argument to
On 2008-02-09, Tom Smith [EMAIL PROTECTED] wrote:
He means be done with it, including hard-setting the clock, within a
second. The accuracy expected, based on ntpdate -b as the benchmark
you are trying to replace, is within a small number of milliseconds of
the specified servers.
Sorry,
In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes:
David I don't think you are ever going to get rid of ntpdate from the
David distribution (as supplied by packagers and vendors) until ntpd offers
David a mode which sets the time within about one second of being started.
The
In article [EMAIL PROTECTED], David L. Mills [EMAIL PROTECTED] writes:
David Harlan, You make some good points. However, if folks want SNTP from
David here I think they would prefer it in its own distribution rather than
David bundle it with the huge NTP distribution.
That's not the feedback I
Harlan Stenn wrote:
Guys,
This is all discussed pretty well at:
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
So far everything I have seen in this thread has already been covered on
that page.
I just followed the above link. I see ONE feature missing!
ntpdate -Du (I
In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes:
David Harlan Stenn wrote:
In article [EMAIL PROTECTED], David Woolley
[EMAIL PROTECTED] writes:
David I'm not convinced that SNTP will displace ntpdate for this purpose.
Why not?
David Because ntpdate is fixed in the
Harlan Stenn [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Unruh Harlan Stenn [EMAIL PROTECTED] writes:
Bill,
ntpdate is being deprecated.
Unruh Maybe, but it should still not have bugs if it is actually still part
Unruh of the distro.
I mostly
In article [EMAIL PROTECTED], David L. Mills [EMAIL PROTECTED] writes:
David Harlan, My position on ntpdate and sntp has always been clear. Remove
David them both from the distribution and let other folks contribute sntp
David products.
Yes, your position has been clear and your opinion has
Harlan,
You make some good points. However, if folks want SNTP from here I think
they would prefer it in its own distribution rather than bundle it with
the huge NTP distribution. You can make a strong argument to host here
if the claim that both NTP and SNTP are strictly specification
In ntpdate.c around line 542 (4.2.4p4)is the sequence
if (!authistrusted(sys_authkey)) {
char buf[10];
(void) sprintf(buf, %lu, (unsigned long)sys_authkey);
msyslog(LOG_ERR, authentication key %s unknown, buf);
exit(1);
}
Since unsigned long does not have a
Bill,
ntpdate is being deprecated.
And it is *much* better to file reports like this using bugs.ntp.org as
otherwise they tend to get lost in the wind.
H
--
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Unruh In ntpdate.c around line 542 (4.2.4p4)is the sequence if
Unruh
Harlan Stenn [EMAIL PROTECTED] writes:
Bill,
ntpdate is being deprecated.
Maybe, but it should still not have bugs if it is actually still part of
the distro.
And it is *much* better to file reports like this using bugs.ntp.org as
otherwise they tend to get lost in the wind.
OK. Will do.
H
In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes:
Unruh Harlan Stenn [EMAIL PROTECTED] writes:
Bill,
ntpdate is being deprecated.
Unruh Maybe, but it should still not have bugs if it is actually still part
Unruh of the distro.
I mostly agree with you. And one reason there are a
56 matches
Mail list logo
