Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Mon, Feb 16, 2015 at 1:11 AM, William Unruh  wrote:

> But that is not what you said. When I asked how ntimed works you
> answered that it disciplines the computer clock.
>

BZZT!

You said: "Be interesting to see how and what it does."
To which I replied: "Since I've told you how it does and what it does is
obvious ..."

Perhaps when you're puzzled by answers to your questions you should review
your questions.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-16, Paul  wrote:
> On Sun, Feb 15, 2015 at 1:18 PM, William Unruh  wrote:
>
>> It I say to someone-- I hear you are trying out the new
>> Subaru, I wonder how it works
>>
>
> If you ask me how my new Subaru works I'd say fine.  If you ask me how much

But that is not what you said. When I asked how ntimed works you
answered that it disciplines the computer clock. 


> I like it I'd say a lot.  If you wanted a comparison to "competitive"
> models I'd direct you to the Subaru competetive models comparison page.  If
> you said "No, no I mean I want *your* summary of Eyesight" I'd say it's
> better than I am and admit that I don't know if there is any public
> technical material on their computer vision system and send you a link to
> the YouTube video.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sun, Feb 15, 2015 at 1:18 PM, William Unruh  wrote:

> Thank you. I had no idea what the new version was called, and saw
> someone call it timed. Sorry if it confused you.
>

This means you're not paying attention to details.  It also means you're
not reading PHK's notes.


> I wanted YOUR summary.
>

I gave you my summary.  You didn't like it.  Fortunately you don't need
anyone else's summary since PHK has thoughtfully prepared a set of them.
>From the README file to the slides to the notes and finally the code.


> It I say to someone-- I hear you are trying out the new
> Subaru, I wonder how it works
>

If you ask me how my new Subaru works I'd say fine.  If you ask me how much
I like it I'd say a lot.  If you wanted a comparison to "competitive"
models I'd direct you to the Subaru competetive models comparison page.  If
you said "No, no I mean I want *your* summary of Eyesight" I'd say it's
better than I am and admit that I don't know if there is any public
technical material on their computer vision system and send you a link to
the YouTube video.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[David Lord]

Harlan Stenn wrote:

David Lord writes:

... The one big flaw with ntpd is that when motherboard temperature
changes too quickly the ntpd control loop is broken and ntp offset can
rise from < 300u to > 10ms.




That might have been a false alarm.

I've not yet been able to search all the logs. I've not
found the 10ms offsets which might have been on one of the
pcs which is now offline. I have found offsets >> 1ms which
were due to reboots and some > 100ms after internet
connection was lost for 8 hrs (those were mostly during the
following 12hrs whilst ntpd was regaining sync to < 300u).

Some of my pcs are located in unheated rooms and I guess
temperatures can vary from below zero to above 25C when in
full sun. Tonight the back room was around 2C and wiil be
much lower early morning. Other pcs are comfortable in a
heated room at 18-24C.


David



Assuming the above is true (and I have no reason to doubt David's
numbers) I have to wonder if it would be an appropriate GSoC project to
write something that monitors and tracks available temperature sensors
and correlates temperature (perhaps with the first derivative) with the
resulting effect on clock frequency.

Once a suitable data gathering mechanism was in place, we could then
decide on a way to get this information into ntpd or any other software
package that cared about it.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Philip Homburg]

In article ,
William Unruh   wrote:
>The documentation has some, but much is in the code. 

I think that's bad situation if you want the ideas embedded in the code
to be adopted by other implementations.


-- 
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-15, Philip Homburg  wrote:
> In article ,
> William Unruh   wrote:
>>I bring up chrony not to discuss it as a program but todiscuss its
>>philosophy of clock control and its design. It presents an alternative
>>to the approach of ntpd, which ntimed appears to be following. 
>
> There is plenty of documentation on how NTP was designed. PHK has 
> a series of articles on the approach he has taken in ntimed, but I can't
> find anything similar for chrony. Do you have a pointer to the design docs
> of chrony?

The documentation has some, but much is in the code. 

The basic idea is that the usual ntp packets are used to get time from a
remote system. chrony places each offset into an array for each source--
up to 64 entries long if I remember correctly. A linear regression is
performed on those entries. That linear regression is tested for
linearity by looking at the number of times that the residual changes
sign. If the number of times is too small, it means that the residuals
tend to cluster on one side or the other too much and a linear model is
a bad model, so the number of offsets saved is reduced either until the
linear fit passes the test, or there are only 3 entries left. That
linear regression is then used to determine the current offset of the
clock and the drift rate. The drift rate is changed (using adjtimex) and
all of the offsets in the array are adjusted to take into account the
new drift rate and the new offset after adjustment. 

The offsets coming in are tested with all of the usual ntp tests, but
also the delays are tested if you have that switched on, to see if the
delay is much longer than the minimum remembered delay (amount
adjustable) 



>
>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Philip Homburg]

In article ,
William Unruh   wrote:
>I bring up chrony not to discuss it as a program but todiscuss its
>philosophy of clock control and its design. It presents an alternative
>to the approach of ntpd, which ntimed appears to be following. 

There is plenty of documentation on how NTP was designed. PHK has 
a series of articles on the approach he has taken in ntimed, but I can't
find anything similar for chrony. Do you have a pointer to the design docs
of chrony?


-- 
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-15, Paul  wrote:
> On Sat, Feb 14, 2015 at 11:21 PM, William Unruh  wrote:
>
>> If you demand that I give
>> detailed explanation
>
>
> You started off down the ntpd versus chrony path again.
>   "To get the discussion started, lets compare some of the differences
> between chrony and ntpd"
> That's not useful.  You've spent years talking about chrony vs. ntpd.
> There's nothing new to be said.

I bring up chrony not to discuss it as a program but todiscuss its
philosophy of clock control and its design. It presents an alternative
to the approach of ntpd, which ntimed appears to be following. 

>
>
>> tell me that timed
>
>
> You keep saying timed.  Is that part of some plan to deny responsibility in
> future?  I'm talking about NTIMED-CLIENT.  I don't know what you mean by
> TIMED.

Thank you. I had no idea what the new version was called, and saw
someone call it timed. Sorry if it confused you.
>
>
>> is different from ntpd, but
>> give me no explanation as to how, or how timed differs from ntpd
>>
>
> I've repeated pointed you to Poul-Henning Kamp's notes regarding Ntimed.
> Why isn't that sufficient?  Please provide your parameters for adequate
> explanation.

I wanted YOUR summary. 

>
>
>>
>> > I've downloaded ntimed which compiled ok so will give it a try in
>> > a few days.
>>
>> Be interesting to see how and what it does.
>>
>
> Since I've told you how it does and what it does is obvious (but just in
> case -- it disciplines system time by steering it to UTC) you can see why
> people might think you're not genuinely interested in a discussion.

Oh, dear. Some people might think that you are not interested in
discussion. It I say to someone-- I hear you are trying out the new
Subaru, I wonder how it works, I do not expect them to come back with --
What do you mean. It drives along roads. 


>
>   "I have given you detailed answers to your question[s]"
>
> Not so much as of yet.  But I keep hoping.

A lot more than you have to me!

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sat, Feb 14, 2015 at 11:21 PM, William Unruh  wrote:

> If you demand that I give
> detailed explanation


You started off down the ntpd versus chrony path again.
  "To get the discussion started, lets compare some of the differences
between chrony and ntpd"
That's not useful.  You've spent years talking about chrony vs. ntpd.
There's nothing new to be said.


> tell me that timed


You keep saying timed.  Is that part of some plan to deny responsibility in
future?  I'm talking about NTIMED-CLIENT.  I don't know what you mean by
TIMED.


> is different from ntpd, but
> give me no explanation as to how, or how timed differs from ntpd
>

I've repeated pointed you to Poul-Henning Kamp's notes regarding Ntimed.
Why isn't that sufficient?  Please provide your parameters for adequate
explanation.


>
> > I've downloaded ntimed which compiled ok so will give it a try in
> > a few days.
>
> Be interesting to see how and what it does.
>

Since I've told you how it does and what it does is obvious (but just in
case -- it disciplines system time by steering it to UTC) you can see why
people might think you're not genuinely interested in a discussion.

  "I have given you detailed answers to your question[s]"

Not so much as of yet.  But I keep hoping.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-15, David Lord  wrote:
> William Unruh wrote:
>> On 2015-02-14, Paul  wrote:
>>> On Sat, Feb 14, 2015 at 2:09 PM, William Unruh  wrote:
>>>
>>>
>>> Yes but you said
>>>  "This means that if you are using say a PPS source, which gives
>>> microsecond long term offset, it can take many hours to get there"
>>> and I was responding to that.  If you refuse to accept that your previous
>>> statements set the context for a discussion then you're just an ANON troll.
>> 
>> Hardly anon. But if the context was PPS, then I agree that I was
>> probably wrong (not being able to remember what my test system was
>> doing.)
>> 
>>>
 To get the discussion started, lets compare some of the differences
 between chrony and ntpd.

>>> BZT.  NTPd is yesterday's news.  It's core is unlikely to change absent
>>> a security flaw.  Design "discussions" about it are useless and unhelpful
>>> (but they should still be on more relevant list).  Come back when you're
>>> ready to write about the differences between Chrony and Ntimed with reasons
>>> to select one or the other.  In the meantime be a better advocate of
>>> alternatives to NTPd i.e. get unstuck from the past and port Chrony to
>>> Windows.
>> 
>> When timed is actually out I may be interested in testing it again.
>> However, you discussion indicates to me that there the design of timed
>> had not advanced from that of ntpd. Whether it is yesterday's news or
>> not, it seems to be determining tomorrow nontheless. 
>> You have not given any indication that the design discussion has moved
>> on from ntpd. 
>>> Research is needed, and such research should be part
 of any new system. Is it there?

>>> Ntimed has a few constraints -- no research needed:
>>> 1) Be safer (simpler) than ntpd.
>>> 2) Be smaller than ntpd.
>>> 3) Be as good or better than ntpd where better is probably slippery.
>> 
>> None of those indicate that anything about the design has changed. You
>> know much better than I do I would assume.
>> No idea what is unsafe about ntpd. Smaller may be possible, mainly be
>> cleaning up the accretion of code. And I would like to hear about what 
>> "better" means. I have mentioned why I believe chrony is better. What do
>> you mean by better?
>> 
>> 
>>> It's not clear to me if worrying about dial-up costs is an Ntimed concern
>>> (I doubt it) but if it is for you then use Chrony.
>> 
>> Dialup costs? Where did I ever mention dialup costs? And chrony's
>> ability to handle dialup is simply an indication of its greater
>> flexibility. Dialup costs never played a role in the design of chrony,
>> except in making it flexible enough to handle the situation of
>> intermittent connectivity to a time source. 
>> 
>>  I am beginning to wonder who the troll is here. I have given you
>>  detailed answers to your question, you come back with irrelevancies and
>>  snarky comments. 
>> 
>
> Hi
>
> I must be a troll since I disagree with you. I used chrony during

You can disagree with me and not be a troll. If you demand that I give
detailed explanation, tell me that timed is different from ntpd, but
give me no explanation as to how, or how timed differs from ntpd, then I
would start to think you are a troll (You are not, you give reasons). 

> the 90's, probably because my isp was demon. I also tried ntpd but
> with my pcs not being online 24/7 and using dialup for internet
> connection ntpd wasn't really usable. Late 90's to 2005 I
> eventually had several pcs online 24/7 and found that ntpd gave
> lower and more stable offsets than chrony but I still needed to
> use chrony on the dialup pc. The one big flaw with ntpd is that
> when motherboard temperature changes too quickly the ntpd control
> loop is broken and ntp offset can rise from < 300u to > 10ms.

That is of course a disaster. 
Note that chrony has changed substantially since the 90s. Lichvar has
done a lot of updating of chrony, adding refclock support, improving rtc
support, etc. Both he and I have done testing of chrony vs ntpd, and
both found that chrony disciplined the clock better (I think because of
its faster response to temperature changes). 

>
> I've downloaded ntimed which compiled ok so will give it a try in
> a few days.

Be interesting to see how and what it does. 

>
>
> David
>
>
>
>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

David Lord writes:
> ... The one big flaw with ntpd is that when motherboard temperature
> changes too quickly the ntpd control loop is broken and ntp offset can
> rise from < 300u to > 10ms.

Assuming the above is true (and I have no reason to doubt David's
numbers) I have to wonder if it would be an appropriate GSoC project to
write something that monitors and tracks available temperature sensors
and correlates temperature (perhaps with the first derivative) with the
resulting effect on clock frequency.

Once a suitable data gathering mechanism was in place, we could then
decide on a way to get this information into ntpd or any other software
package that cared about it.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sat, Feb 14, 2015 at 6:38 PM, William Unruh  wrote:

>
> When timed is actually out I may be interested in testing it again.
>

Ntimed-client.  Again?  So you've installed the code?  <
https://github.com/bsdphk/Ntimed>
That seems unlikely.  Read this: 


> You have not given any indication that the design discussion has moved
> on from ntpd.
>

Have you read the notes?  If you mean why is Ntimed still using PLL instead
of curve-fitting you should ask PHK or Harlan.  Ask eight times.


> > Ntimed has a few constraints -- no research needed:
> > 1) Be safer (simpler) than ntpd.
> > 2) Be smaller than ntpd.
> > 3) Be as good or better than ntpd where better is probably slippery.
>
> None of those indicate that anything about the design has changed.


They arent' intended to.  You said research is needed I was pointing out
that it isn't needed.  The engineering is understood it's a matter of
deciding on a solution and coding it up.  Get the slides <
http://phk.freebsd.dk/_downloads/FOSDEM_2015.pdf> read slides five to nine.


> No idea what is unsafe about ntpd.


Please tell me you're kidding.  Really.  If not then ... well we really
can't even begin to have a discussion until you understand the recent and
current state of NTPd.  Get the slides <
http://phk.freebsd.dk/_downloads/FOSDEM_2015.pdf> see slide 39.


> Smaller may be possible, mainly be
> cleaning up the accretion of code.


PHK's coarse count puts ~300,000 lines of code in the tarball.  That's
overstating it a bit since a significant fraction is comments but there are
~60k lines of real code in the ntpd directory.


> And I would like to hear about what
> "better" means. I have mentioned why I believe chrony is better. What do
> you mean by better?
>

To repeat myself -- Ntimed-client keeps my difficult (poorly networked or
slow) clients at O(1) microsecond offsets.  That's an order of magnitude
better than ntpd.  That's one definition of better.   However, like beauty,
better is in the eye of the beholder.


> Dialup costs? Where did I ever mention dialup costs?
>

You didn't.  The designer of Chrony did.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[David Lord]

William Unruh wrote:

On 2015-02-14, Paul  wrote:

On Sat, Feb 14, 2015 at 2:09 PM, William Unruh  wrote:


Yes but you said
 "This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there"
and I was responding to that.  If you refuse to accept that your previous
statements set the context for a discussion then you're just an ANON troll.


Hardly anon. But if the context was PPS, then I agree that I was
probably wrong (not being able to remember what my test system was
doing.)




To get the discussion started, lets compare some of the differences
between chrony and ntpd.


BZT.  NTPd is yesterday's news.  It's core is unlikely to change absent
a security flaw.  Design "discussions" about it are useless and unhelpful
(but they should still be on more relevant list).  Come back when you're
ready to write about the differences between Chrony and Ntimed with reasons
to select one or the other.  In the meantime be a better advocate of
alternatives to NTPd i.e. get unstuck from the past and port Chrony to
Windows.


When timed is actually out I may be interested in testing it again.
However, you discussion indicates to me that there the design of timed
had not advanced from that of ntpd. Whether it is yesterday's news or
not, it seems to be determining tomorrow nontheless. 
You have not given any indication that the design discussion has moved
on from ntpd. 

Research is needed, and such research should be part

of any new system. Is it there?


Ntimed has a few constraints -- no research needed:
1) Be safer (simpler) than ntpd.
2) Be smaller than ntpd.
3) Be as good or better than ntpd where better is probably slippery.


None of those indicate that anything about the design has changed. You
know much better than I do I would assume.
No idea what is unsafe about ntpd. Smaller may be possible, mainly be
cleaning up the accretion of code. And I would like to hear about what 
"better" means. I have mentioned why I believe chrony is better. What do

you mean by better?



It's not clear to me if worrying about dial-up costs is an Ntimed concern
(I doubt it) but if it is for you then use Chrony.


Dialup costs? Where did I ever mention dialup costs? And chrony's
ability to handle dialup is simply an indication of its greater
flexibility. Dialup costs never played a role in the design of chrony,
except in making it flexible enough to handle the situation of
intermittent connectivity to a time source. 


 I am beginning to wonder who the troll is here. I have given you
 detailed answers to your question, you come back with irrelevancies and
 snarky comments. 



Hi

I must be a troll since I disagree with you. I used chrony during
the 90's, probably because my isp was demon. I also tried ntpd but
with my pcs not being online 24/7 and using dialup for internet
connection ntpd wasn't really usable. Late 90's to 2005 I
eventually had several pcs online 24/7 and found that ntpd gave
lower and more stable offsets than chrony but I still needed to
use chrony on the dialup pc. The one big flaw with ntpd is that
when motherboard temperature changes too quickly the ntpd control
loop is broken and ntp offset can rise from < 300u to > 10ms.

I've downloaded ntimed which compiled ok so will give it a try in
a few days.


David




___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-14, Paul  wrote:
> On Sat, Feb 14, 2015 at 2:09 PM, William Unruh  wrote:
>
>
> Yes but you said
>  "This means that if you are using say a PPS source, which gives
> microsecond long term offset, it can take many hours to get there"
> and I was responding to that.  If you refuse to accept that your previous
> statements set the context for a discussion then you're just an ANON troll.

Hardly anon. But if the context was PPS, then I agree that I was
probably wrong (not being able to remember what my test system was
doing.)

>
>
>> To get the discussion started, lets compare some of the differences
>> between chrony and ntpd.
>>
>
> BZT.  NTPd is yesterday's news.  It's core is unlikely to change absent
> a security flaw.  Design "discussions" about it are useless and unhelpful
> (but they should still be on more relevant list).  Come back when you're
> ready to write about the differences between Chrony and Ntimed with reasons
> to select one or the other.  In the meantime be a better advocate of
> alternatives to NTPd i.e. get unstuck from the past and port Chrony to
> Windows.

When timed is actually out I may be interested in testing it again.
However, you discussion indicates to me that there the design of timed
had not advanced from that of ntpd. Whether it is yesterday's news or
not, it seems to be determining tomorrow nontheless. 
You have not given any indication that the design discussion has moved
on from ntpd. 
>
> Research is needed, and such research should be part
>> of any new system. Is it there?
>>
>
> Ntimed has a few constraints -- no research needed:
> 1) Be safer (simpler) than ntpd.
> 2) Be smaller than ntpd.
> 3) Be as good or better than ntpd where better is probably slippery.

None of those indicate that anything about the design has changed. You
know much better than I do I would assume.
No idea what is unsafe about ntpd. Smaller may be possible, mainly be
cleaning up the accretion of code. And I would like to hear about what 
"better" means. I have mentioned why I believe chrony is better. What do
you mean by better?


>
> It's not clear to me if worrying about dial-up costs is an Ntimed concern
> (I doubt it) but if it is for you then use Chrony.

Dialup costs? Where did I ever mention dialup costs? And chrony's
ability to handle dialup is simply an indication of its greater
flexibility. Dialup costs never played a role in the design of chrony,
except in making it flexible enough to handle the situation of
intermittent connectivity to a time source. 

 I am beginning to wonder who the troll is here. I have given you
 detailed answers to your question, you come back with irrelevancies and
 snarky comments. 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Sat, Feb 14, 2015 at 2:09 PM, William Unruh  wrote:

> Because ntpd is what I know.


Except you've admitted you don't know NTPd.


> If you are saying that this is all up in the air again with
> the new replacement, that would be great. But I have seen no evidence
> thereof in discussions here.
>

And you won't.  This list is called ntp:questions.  If Ntimed was going to
be discussed on an ntp ilst ntp:hackers would make more sense.  But I
suspect Ntimed will be code and fact driven.   And PHK driven.  So read the
material I pointed you to last time, read the code and present useful
comments or code.


> I would have expected people involved to discuss what the new design
> philosophy was, what they saw as the advantages and disadvantages of the
> various approaches, etc. I have not seen those discussion. Either they
> are taking place elsewhere than here, or they are not taking place, and
> the new is simply a repolishing of the old.
>

See above.


>
> Regardind the rate of convergence, clearly that will be vastly faster
> with a PPS refclock... But most people use the net, not a local PPS source.
>

Yes but you said
 "This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there"
and I was responding to that.  If you refuse to accept that your previous
statements set the context for a discussion then you're just an ANON troll.


> To get the discussion started, lets compare some of the differences
> between chrony and ntpd.
>

BZT.  NTPd is yesterday's news.  It's core is unlikely to change absent
a security flaw.  Design "discussions" about it are useless and unhelpful
(but they should still be on more relevant list).  Come back when you're
ready to write about the differences between Chrony and Ntimed with reasons
to select one or the other.  In the meantime be a better advocate of
alternatives to NTPd i.e. get unstuck from the past and port Chrony to
Windows.

Research is needed, and such research should be part
> of any new system. Is it there?
>

Ntimed has a few constraints -- no research needed:
1) Be safer (simpler) than ntpd.
2) Be smaller than ntpd.
3) Be as good or better than ntpd where better is probably slippery.

It's not clear to me if worrying about dial-up costs is an Ntimed concern
(I doubt it) but if it is for you then use Chrony.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-14, Paul  wrote:
> On Fri, Feb 13, 2015 at 8:48 PM, William Unruh  wrote:
>
> However you've not responded to my question regarding your deep concerns.
> For years you've complained about the ntpd pll and on occasion suggested
> chrony.  Now a replacement is being developed.  So why do you continue to
> focus on what you consider to be defects in ntpd?

Because ntpd is what I know. I now run chrony exclusively (I used to use
ntpd to get time from a Garmin gps but Miroslav Lichvar has done
extensive work on chrony, and it now handles "refclocks" where it used
not to do so). When I was testing things, I had
the hope that the ntpd could incorporate the strengths of chrony into
ntpd, and that one could at least have a discussion of the advantages
and disadvantages of a "fitting" algorithm over a Markovian feedback
loop, for example. And the possibility of using all measurements made instead 
of 1 in
8 as ntpd does. But there has been zero interest shown by the ntpd people in 
either
of these. If you are saying that this is all up in the air again with
the new replacement, that would be great. But I have seen no evidence
thereof in discussions here. 

I would have expected people involved to discuss what the new design
philosophy was, what they saw as the advantages and disadvantages of the
various approaches, etc. I have not seen those discussion. Either they
are taking place elsewhere than here, or they are not taking place, and
the new is simply a repolishing of the old. 

Regardind the rate of convergence, clearly that will be vastly faster
with a PPS refclock, which has not roundtrip time delay, vs the
convergence from the net. As I recall, my tests were on the latter, not
the former. I used a PPS clock to time and test the system, to get a
handle on what the "true" offset of the system was. Clearly the
convergence time of ntpd from the net, with its effective minpoll of 9
would be, and is, vastly longer than that from a PPS with an effective
minpoll of 3. But most people use the net, not a local PPS source. 

To get the discussion started, lets compare some of the differences
between chrony and ntpd. 

chrony uses a fitting algorithm to do a linear fit on the last N offset
measurements to determine the current offset and drift. As such it
averages over those last N measurements to reduce the uncertainty in
that estimate of the offset and drift. Note that it it also compensates
past measurements for current changes in the clock rate, so that those
measurements are always on the basis of "If the clock had been running
at the current drift when those measurements were made." It then alters
the clock rate to eliminate that offset and to get the system to the
correct drift rate of 1s/s. ntpd on the other hand alters the current
drift to eliminate the currently measured offset. It retains no memory.
It has no idea what the "correct" clock rate is. All it knows is that it
must chase the current offset. 

chrony has an adaptive algorithm to determine N in the above. It tests
the linear fit to see if the data supports the hypothesis that the drift
rate of the clock has been constant over the N samples (It does so by
looking at the distribution of offsets that lie above and below the
line) If it feels that a linear hypothesis is not good, it reduces N
until it is good. If it is good, it allows N to increase. The larger N
the better the linear fit can eliminate random measurement fluctuations. 

ntpd has a clock filter algorithm. It remembers the past 8
measurements-- both offset and delay (roundtrip time) and choses the
next useable measurement as that measuement of the past 
of the past 8 which has the smallest delay as a way of trying to
eliminate assymetry in round trip delays. This is often silly. If round
trip A is 1 microsecond longer than B on a 10ms roundtrip time, A will
not be used, since B is shorter. But even if that 1 microsecond were
completely one way, the harm  to accuracy of the system clock to
eliminating A is far larger than that harm of that "one way" delay. The
advantage of statistics in reducing uncertainty outweighs the
disadvantage of that tiny error in roundtrip. I suspect stongly that in
most useages of ntpd, that is true. It may be that in certain
situations, that clock filter helps, but I suspect they are rare. 
Chrony uses all measurements,
except you can tell it to filter out measurements whose delay is larger
than some multiple of the minimum delay over the past N measurements. 
It's hypothesis is that variation in the delay time is simply another
random perturbation of the measurement which the linear regression can
handle. 

The effect of those two differences is that chrony is much faster than
ntpd is at noticing changes -- eg due to temperature changes. 

These are two of the main differences. Chrony in experiments I have
done, and Lichvar has done, disciplines the clock a factor of 2 to 20
times better than does ntpd. Ie, the difference between the time on the
computer

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Fri, Feb 13, 2015 at 8:48 PM, William Unruh  wrote:

> >
> > I had a properly set up PPS source to do the comparison.
>
> As did I.
>

Ooops, I see that the text/plain part of the message was damaged.  I was
quoting you saying:
" I had a properly set up PPS source" and my response was we have no way of
knowing that but you've clarified that.  However I believe the minpoll 4
advice predates minpoll 3.  Although much better than the ntp.org docs
(xntp ... really!) the udel documents are not completely consistent.

In any case all of my comments are specific to a PPS refclock, which you
mentioned in the post that prompted my reponse, and nanosecond jitter.
That value is significant only in so far was we can ignore jitter and focus
on wander.

 Poll 4 for PPS, Poll 6-10 for network.


There's an assumption that the Allan intercept for "fast" local networks is
512s and that the time constant  jitter versus wander trade-off supports
using minpoll 4 but I think the correct choice is three (minpoll 3 maxpoll
3) and my results reflect that.


>  Note that since the effective poll interval is 3 higher
>  than the nominal poll interval,
>
and since the convergence time scale is
>  larger than one poll interval, this would give a convergence time of
>  greater than 2^9 sec, or 500 sec (10 min)


I'm not completely clear on what you mean here but in any case using a time
constant of 256s would be expected to cut any time in half.  It also worth
noting that the bulk of offset "error" is corrected very quickly with only
the residue taking a significant amount of time.

However you've not responded to my question regarding your deep concerns.
For years you've complained about the ntpd pll and on occasion suggested
chrony.  Now a replacement is being developed.  So why do you continue to
focus on what you consider to be defects in ntpd?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-13, Paul  wrote:
> On Fri, Feb 13, 2015 at 12:42 AM, William Unruh  wrote:
>
>> OK, so we seem to have two different sets of experiments with very
>> different results. Note that I did not erase the drift file, or restart
>> ntpd after my perturbation.
>>
>
> Okay, I offset my clock by 100ms without restarting ntpd.  It took about
> 100 seconds to reduce that by two orders of magnitude and about 2,800
> seconds to return to O(1) microsecond offset albeit O(10) microseconds of
> jitter.   Next I'll try Ntimed-client.  Perhaps you should redo your
> experiment in the modern era.  Or quit referring to stale data.

Good suggestion. I had seen nothing however that caused me to think ntpd
had changed this part.

>
> I had a properly set up PPS source to do the comparison.

As did I.
>
>
> We have no way of knowing that and the simplest way to get poor recovery is
> to use the wrong poll interval with a PPS refclock.
 Poll 4 for PPS, Poll 6-10 for network. I think the test referred to was
 using a local network, but by this time it is hard to remember the
 exact details. Note that since the effective poll interval is 3 higher
 than the nominal poll interval, and since the convergence time scale is
 larger than one poll interval, this would give a convergence time of
 greater than 2^9 sec, or 500 sec (10 min) that is still faster than I
 was finding. 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

David Lord  wrote:
> Rob wrote:
>> Terje Mathisen  wrote:
>>> Charles Swiger wrote:
 On Feb 12, 2015, at 1:56 AM, Rob  wrote:

> However, what I observe is that the plots of the offset show the 
> derivative
> of the environment temperature, which unfortunately cannot be controlled
> any better.  I am considering to locate the crystal that is responsible
> for the timing and see if it could be ovenized or replaced by a more
>>> I've considered packing some insulation around the crystal, this would 
>>> tend to stabilize (while also increasing) the temperature, but this 
>>> would also be likely to reduce its lifetime, and the motherboard would 
>>> probably conduct heat too well.
>> 
>> That will only slow down the rate of change, and probably not much.
>> We tend to have temperature cycles over 24h and this will not help.
>
> At least in my case on occasions the rate of change seems to
> be faster than the control loop can handle and offsets of my
> various pcs rather than being < 300u rise to 10ms. Only a
> small reduction in rate of change would be required to
> avoid this. Thermostatic temperature control at the crystal
> or a stable external clock source would be better but more
> difficult to implement.

It is not certain that this problem is caused by temperature, unless
maybe you are running at 1024 second poll interval.

When you want close tracking of the offset the first thing to do is
set the maxpoll to 6.  Otherwise the interval over which the excursions
happen is much too large, and overshoots of both the original offset and
the compensation happen.

With maxpoll 6 and local ethernet reference I have no trouble keeping
within 50us.  With maxpoll 10 this is impossible.

The systems with local PPS (which is configured with maxpoll 4 although
this seems to be handled differently in recent versions) normally remain
within 10us, temperature changes result in wobbles of 4-6 us.  When
temperature is constant, it is more like 1-2 us.  So it should be possible
to get better results when temperature changes are taken into account.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Charles Swiger]

On Feb 12, 2015, at 11:21 PM, Terje Mathisen  wrote:
> I've considered packing some insulation around the crystal, this would tend 
> to stabilize (while also increasing) the temperature, but this would also be 
> likely to reduce its lifetime, and the motherboard would probably conduct 
> heat too well.

The standard AT cut crystals are designed to be most linear at or around 25 C.
They wouldn't be as accurate at much higher temperatures, but they don't mind
high temperatures the way capacitors do.

OCXO generally uses SC cut crystals which were designed to be most stable around
75 C, which is too hot for caps to have a long life (especially electrolytics).

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Fri, Feb 13, 2015 at 12:42 AM, William Unruh  wrote:

> OK, so we seem to have two different sets of experiments with very
> different results. Note that I did not erase the drift file, or restart
> ntpd after my perturbation.
>

Okay, I offset my clock by 100ms without restarting ntpd.  It took about
100 seconds to reduce that by two orders of magnitude and about 2,800
seconds to return to O(1) microsecond offset albeit O(10) microseconds of
jitter.   Next I'll try Ntimed-client.  Perhaps you should redo your
experiment in the modern era.  Or quit referring to stale data.

I had a properly set up PPS source to do the comparison.


We have no way of knowing that and the simplest way to get poor recovery is
to use the wrong poll interval with a PPS refclock.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[David Lord]

Rob wrote:

Terje Mathisen  wrote:

Charles Swiger wrote:

On Feb 12, 2015, at 1:56 AM, Rob  wrote:


However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better.  I am considering to locate the crystal that is responsible
for the timing and see if it could be ovenized or replaced by a more
I've considered packing some insulation around the crystal, this would 
tend to stabilize (while also increasing) the temperature, but this 
would also be likely to reduce its lifetime, and the motherboard would 
probably conduct heat too well.


That will only slow down the rate of change, and probably not much.
We tend to have temperature cycles over 24h and this will not help.


At least in my case on occasions the rate of change seems to
be faster than the control loop can handle and offsets of my
various pcs rather than being < 300u rise to 10ms. Only a
small reduction in rate of change would be required to
avoid this. Thermostatic temperature control at the crystal
or a stable external clock source would be better but more
difficult to implement.


David

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

Terje Mathisen  wrote:
> Charles Swiger wrote:
>> On Feb 12, 2015, at 1:56 AM, Rob  wrote:
>>
>>> However, what I observe is that the plots of the offset show the derivative
>>> of the environment temperature, which unfortunately cannot be controlled
>>> any better.  I am considering to locate the crystal that is responsible
>>> for the timing and see if it could be ovenized or replaced by a more
>
> I've considered packing some insulation around the crystal, this would 
> tend to stabilize (while also increasing) the temperature, but this 
> would also be likely to reduce its lifetime, and the motherboard would 
> probably conduct heat too well.

That will only slow down the rate of change, and probably not much.
We tend to have temperature cycles over 24h and this will not help.

>>> temperature-stable oscillator.  However, one can argue that it could be
>>> fixed in software as well.  ntpd could sense a changing drift and 
>>> extrapolate
>>> it, if necessary helped by input from a temperature sensor.
>>
>> You're describing a TCXO; using a temperature sensor to compensate for 
>> thermal
>> drift would gain perhaps a factor of 5 accuracy.
>
> It should be noted that this experiment has been tried out in real life 
> a few times: It has always helped! Depending upon the (temperature) 
> offset between the selected sensor and the crystal, you can see an order 
> of magnitude improvement.
>
> We don't have any code like that in the ntpd reference code base, simply 
> because it would be _very_ unportable. :-(

I see in chrony there is a command to add temperature compensation, and it
has a couple of parameters like the pseudo-file to read and the offset
and gain.  When just reading a file it is not very unportable, it may be
that some systems do not provide that functionality but it will still
compile.  A more portable solution could extend this with the option of
reading data from an external program or script.

Linux provides access to onboard temperature sensors via files in /sys
or /proc that can just be read by any file access function.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Miroslav Lichvar]

On Fri, Feb 13, 2015 at 05:42:54AM +, William Unruh wrote:
> On 2015-02-13, Paul  wrote:
> > On Thu, Feb 12, 2015 at 7:27 PM, William Unruh  wrote:
> >
> >> It was based on measurements I made with ntpd
> >
> > Are you assuming the numbers I provided are based on theory or were you
> > looking over my shoulder when I perturbed system time by two milliseconds
> > and watched it converge to O(10) microseconds in ~180 seconds.
> 
> OK, so we seem to have two different sets of experiments with very
> different results. Note that I did not erase the drift file, or restart
> ntpd after my perturbation. 

The difference probably comes from different ntp versions. In some
4.2.7 version the code was reworked to correct the initial offset by
adjtime() without touching the PLL. If the drift file contains an
accurate value, the PLL should be now able to lock pretty quickly.

There is an interesting problem with larger step threshold, however
[1]. The code assumes the adjtime() correction can finish in 300
seconds. If the correction is so large that it can't finish before
the next clock update, it results in worse behavior than without this
feature.

On systems that use the standard adjtime() slew rate of 500 ppm the
maximum reliable correction is 150 ms, on systems with faster slew
it's proprotionally larger.

[1] https://bugs.ntp.org/show_bug.cgi?id=2021

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

William Unruh  wrote:
> No, that is a hardware solution. There are software solutions-- a
> termistor to meaure the temperature of the crystal ( or somethign
> nearby) which feeds that measurement to the OS. the revised ntp then
> reads the temperature, and corrects the drift rate as a function of that
> temperature. This means that the change in the ntpd drift rate does not only 
> depend on
> the offset meaured but also on that temperature. Since it takes a while
> for a temperature to be reflected in the offset, this makes ntpd track
> the correct rate of the clock much more closely. Yes, factors of 5 are
> easy. Actually, I suspect that oneof the reasons that chrony does so
> much better than ntpd does in disciplining the clock ( 2-20 times
> better) is because it reacts to such temperature changes much more
> rapidly. It can do so because it keeps a memory of the drifts and
> offsets and can see changes much more quickly. It also does not throw
> away 85% of the measurements to correct round trip errors, so can also
> react faster because of that. 

After reading that chrony can now handle local PPS clocks, I viewed
the recent chrony manual and I see that it has support for temperature
compensation as well.
Unfortunately it is not automatic so it will have to be calibrated and
put in the configuration file.  As described by others it would be
possible to make it auto-calibrating and only save the results of the
calibration like the drift that is also saved.

Measuring the temperature is no problem, those systems have a couple
of different temperature sensors (for ambient, board and CPU temperature)
that can be used as an approximation.

Maybe I try chrony.  First I need to test it on my own system and see if
it can be monitored similar to ntpd (readvar).

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Terje Mathisen]

David Lord wrote:

Solutions that measure the temperature require calibration
for the individual crystal as with the cheap crystals used
the drift per deg C can be either positive or negative and
also depending on "cut" of the crystal can follow a
parabolic or "lazy S" curve.


The only reasonable way to handle this problem IMHO is to have a big 
history table:


For each adjustment period, log the temperature and the current best 
estimate clock frequency delta (i.e. offset from average drift rate). 
This could be in the form of full statistics, or (much simpler!) an 
exponential decay for each possible temperature reading. The latter just 
needs a couple of multiplications and an add for each update.


The entire table starts by being initialized to zero, then it should be 
saved away once a day or so. When restarting you can load the previous 
history.


The alternative of fitting a simple heater with temperature
control to the crystal seemed to be more effective and with
pps ntp source the offset was < 300n.


Nice.

This does require you to open the box though, while a sw only solution 
could even be used on a rack full of blade servers. :-)


Terje


--
- 
"almost all programming can be viewed as an exercise in caching"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Terje Mathisen]

Charles Swiger wrote:

On Feb 12, 2015, at 1:56 AM, Rob  wrote:


However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better.  I am considering to locate the crystal that is responsible
for the timing and see if it could be ovenized or replaced by a more


I've considered packing some insulation around the crystal, this would 
tend to stabilize (while also increasing) the temperature, but this 
would also be likely to reduce its lifetime, and the motherboard would 
probably conduct heat too well.



temperature-stable oscillator.  However, one can argue that it could be
fixed in software as well.  ntpd could sense a changing drift and extrapolate
it, if necessary helped by input from a temperature sensor.


You're describing a TCXO; using a temperature sensor to compensate for thermal
drift would gain perhaps a factor of 5 accuracy.


It should be noted that this experiment has been tried out in real life 
a few times: It has always helped! Depending upon the (temperature) 
offset between the selected sensor and the crystal, you can see an order 
of magnitude improvement.


We don't have any code like that in the ntpd reference code base, simply 
because it would be _very_ unportable. :-(


Terje
--
- 
"almost all programming can be viewed as an exercise in caching"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-13, Paul  wrote:
> On Thu, Feb 12, 2015 at 7:27 PM, William Unruh  wrote:
>
>> It was based on measurements I made with ntpd
>>
>
> Are you assuming the numbers I provided are based on theory or were you
> looking over my shoulder when I perturbed system time by two milliseconds
> and watched it converge to O(10) microseconds in ~180 seconds.

OK, so we seem to have two different sets of experiments with very
different results. Note that I did not erase the drift file, or restart
ntpd after my perturbation. 

>
>
>> Note that the how long it takes to converge depends on the error that
>> needs correcting.
>>
>
> See note ** in my message.
>
>
>> Those are based on experiments, not theory.
>>
>
>  And my numbers are also based on empirical evidence not theory.  Do note
> my mention of constraints (a properly set-up PPS source because you
> mentioned one).

I had a properly set up PPS source to do the comparison. 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-13, Harlan Stenn  wrote:
> William Unruh writes:
>> On 2015-02-12, Harlan Stenn  wrote:

>
> It would have been far better for folks with those broken kernels to
> have simply removed any drift file before starting ntpd.  The code to
> remove the drift file could have been removed once the problem got
> fixed.


Of course. But the thing about computers is that they can take over and
reliably do what people could do with much additional work, and if it
has to be done after time, can remember to do each time. 

Is ntpd a place where it could take place? Yes. 

And the other problem is that even if they removed the drift file, they
could be screwed by the 500PPM limit. If their kernel that time happened
to be out by 470PPM, that would have left only 30PPM for ntpd to work
with. 

>
> Or folks could have proceeded with an idea I had years ago - write the
> tick value (or the frequency) to the drift file, and when starting up
> make sure those values were still appropriate.

I never have understood how they calibrated the system clock in the
first place. What acts as the reference? The rtc?

>
> But again, how far should we go to accomodate braindamage?

One could say the same for stupid networks, but ntpd spends vast amounts
of time and comprimizes to deal with very rare network problems.

>
> Ntimed is beautiful and small.  And every time somebody decides to
> address some new issue, the code will get bigger.

Yes, that is a problem with dealing with the real world. 

>
>> > - that should have been predicted and accommodated by stable-running
>> >   software and algorithms that have been around for decades,
>> 
>> That the kernel people screwed up was perhaps unpredictable. That clocks
>> could have drift rates substantiallydifferent from 1 sec/sec could have
>> been predicted. 
>> 
>> >
>> > - where no other kernel has ever misbehaved in this way,
>> >
>> > - and other projects should deal with that mess;
>> >
>> > - and chrony, a program with one design goal of closely tracking a
>> >   master avoids this kernel brokenness.
>> 
>> All of the above are predicated on you wrong assumption that I thought
>> that the kernel screwup could be predicted. 
>
> I don't see it that way.
>
> The linux folks went ahead and did something Unusual expecting other
> folks to deal with their mess.

No. I doubt very strongly that they did it on purpose. They screwed up
and then did not know how to fix it was how I saw it. If you have
evidence that it was malice rather than incompetence, I would love to
hear of it. 


>
> Kinda like when they took the PPASPI and decided that they were not
> going to implement both MOD_ and STA_ bits because they were "similar"
> and then got huffy because they changed something they were not using
> and the folks who were using it didn't feel like cleaning up that
> externally-created mess, either.

No idea of that. 

>
>> > And the net effect of the above indicates a shortcoming in the way NTP
>> > was designed, right?
>> 
>> The inability to deal with the real world, when that is one of its
>> design goals IS a shortcoming in NTP, yes. 
>
> Bullshit.
>
> How about "the unwillingness to deal with excessive stupidity"?

Unfortunately excessive stupidity is an attribute of the real world. 
And the fix is NOT difficult for something like ntp to handle. 


>
>> > That's OK, and it's why I don't take your messages very seriously.
>> 
>> Of course I cannot make you take anything seriously. I would have
>> thought that designing ntpd to handle the real world would be something
>> you take seriously. And that when you discover a feature of the real
>> world that ntpd does not handle but could, that you would seriously
>> consider changing ntpd so that it does. 
>
> Some behaviors are so broken it doesn't make sense to try and accomodate
> them.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 7:27 PM, William Unruh  wrote:

> It was based on measurements I made with ntpd
>

Are you assuming the numbers I provided are based on theory or were you
looking over my shoulder when I perturbed system time by two milliseconds
and watched it converge to O(10) microseconds in ~180 seconds.


> Note that the how long it takes to converge depends on the error that
> needs correcting.
>

See note ** in my message.


> Those are based on experiments, not theory.
>

 And my numbers are also based on empirical evidence not theory.  Do note
my mention of constraints (a properly set-up PPS source because you
mentioned one).
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 7:16 PM, William Unruh  wrote:

> Not really. But it should be distrubing that chrony disciplines clocks
> much better ( lower jitter) than does ntpd in normal situations. Why?
> And does that have lessons that ntpd could learn from?
>

If you don't stop fixating on NTPd you're not going to get anywhere.  In
general you should encourage people to use better solutions rather than
voicing pointless complaints.  Read PHK's posts and slides.  The facts are
there, the code is short and his biases are obvious so you can start
complaining about what is expected/hoped to replace NTPd with little
effort. If Ntimed tanks then you can start whinging about NTPd again .

As I've said before Ntimed(-client) on my difficult machines (old, slow or
poorly connected) instantly* sets the clock and quickly converges to
microsecond level offsets.

*For reasonable values of instantly.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

William Unruh writes:
> On 2015-02-12, Harlan Stenn  wrote:
> > Bill,
> >
> > So you believe:
> >
> > - the broken linux kernel behavior is an acceptable (or at least
> >   excusable) fact of life,
> 
> Of course not. However, it IS a fact of life, and I have to live in the
> real world. nptd spends many lines of code correcting for rare
> conditions in the real world. But not this one. 

Those coding problems with core linux timekeeping were outside our realm
of "we can reasonably deal with these problems."

It would have been far better for folks with those broken kernels to
have simply removed any drift file before starting ntpd.  The code to
remove the drift file could have been removed once the problem got
fixed.

Or folks could have proceeded with an idea I had years ago - write the
tick value (or the frequency) to the drift file, and when starting up
make sure those values were still appropriate.

But again, how far should we go to accomodate braindamage?

Ntimed is beautiful and small.  And every time somebody decides to
address some new issue, the code will get bigger.

> > - that should have been predicted and accommodated by stable-running
> >   software and algorithms that have been around for decades,
> 
> That the kernel people screwed up was perhaps unpredictable. That clocks
> could have drift rates substantiallydifferent from 1 sec/sec could have
> been predicted. 
> 
> >
> > - where no other kernel has ever misbehaved in this way,
> >
> > - and other projects should deal with that mess;
> >
> > - and chrony, a program with one design goal of closely tracking a
> >   master avoids this kernel brokenness.
> 
> All of the above are predicated on you wrong assumption that I thought
> that the kernel screwup could be predicted. 

I don't see it that way.

The linux folks went ahead and did something Unusual expecting other
folks to deal with their mess.

Kinda like when they took the PPASPI and decided that they were not
going to implement both MOD_ and STA_ bits because they were "similar"
and then got huffy because they changed something they were not using
and the folks who were using it didn't feel like cleaning up that
externally-created mess, either.

> > And the net effect of the above indicates a shortcoming in the way NTP
> > was designed, right?
> 
> The inability to deal with the real world, when that is one of its
> design goals IS a shortcoming in NTP, yes. 

Bullshit.

How about "the unwillingness to deal with excessive stupidity"?

> > That's OK, and it's why I don't take your messages very seriously.
> 
> Of course I cannot make you take anything seriously. I would have
> thought that designing ntpd to handle the real world would be something
> you take seriously. And that when you discover a feature of the real
> world that ntpd does not handle but could, that you would seriously
> consider changing ntpd so that it does. 

Some behaviors are so broken it doesn't make sense to try and accomodate
them.

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

William Unruh writes:
> > Chrony and ntpd have fundamentally different definitions of what it
> > means to "provide good time".
> 
> Not really. But it should be distrubing that chrony disciplines clocks
> much better ( lower jitter) than does ntpd in normal situations. Why?
> And does that have lessons that ntpd could learn from? 

I don't think there is any new information here.  You think NTP is
throwing away good data.  I don't agree with you.  Lots of other folks
don't agree with you.

The algorithms are in place for very good reasons.

Is there room for improvement?  Certainly.  And for that to happen there
would have to be constructive dialog.

I don't know if Ntimed's overall plan allows for the easy testing of
different algorithms.  If it doesn't, I'm game to see a rewrite of NTP
that *does* allow this, and right now it's looking like it will take a
bit of serious effort to either figure out how to get the current NTP
simulator code working again, or a different level of effort to come up
with new code that does this.

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[David Lord]

William Unruh wrote:

On 2015-02-12, Charles Swiger  wrote:

On Feb 12, 2015, at 1:56 AM, Rob  wrote:

Charles Swiger  wrote:

On Feb 11, 2015, at 7:23 AM, Rob  wrote:



However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better.  I am considering to locate the crystal that is responsible
for the timing and see if it could be ovenized or replaced by a more
temperature-stable oscillator.  However, one can argue that it could be
fixed in software as well.  ntpd could sense a changing drift and extrapolate
it, if necessary helped by input from a temperature sensor.

You're describing a TCXO; using a temperature sensor to compensate for thermal
drift would gain perhaps a factor of 5 accuracy.


No, that is a hardware solution. There are software solutions-- a
termistor to meaure the temperature of the crystal ( or somethign
nearby) which feeds that measurement to the OS. the revised ntp then
reads the temperature, and corrects the drift rate as a function of that
temperature. This means that the change in the ntpd drift rate does not only 
depend on
the offset meaured but also on that temperature. Since it takes a while
for a temperature to be reflected in the offset, this makes ntpd track
the correct rate of the clock much more closely. Yes, factors of 5 are
easy. Actually, I suspect that oneof the reasons that chrony does so
much better than ntpd does in disciplining the clock ( 2-20 times
better) is because it reacts to such temperature changes much more
rapidly. It can do so because it keeps a memory of the drifts and
offsets and can see changes much more quickly. It also does not throw
away 85% of the measurements to correct round trip errors, so can also
react faster because of that. 
This is all without controlling the temperature of the oscillator (TCXO)

but rather measuring that temperature-- much cheaper.


Solutions that measure the temperature require calibration
for the individual crystal as with the cheap crystals used
the drift per deg C can be either positive or negative and
also depending on "cut" of the crystal can follow a
parabolic or "lazy S" curve.

The alternative of fitting a simple heater with temperature
control to the crystal seemed to be more effective and with
pps ntp source the offset was < 300n.

There might still be examples on the web where this has been
done but the references I used have long since been taken
down.


David

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Charles Swiger]

On Feb 12, 2015, at 4:02 PM, William Unruh  wrote:
>> You're describing a TCXO; using a temperature sensor to compensate for 
>> thermal
>> drift would gain perhaps a factor of 5 accuracy.
> 
> No, that is a hardware solution. There are software solutions-- a
> termistor to meaure the temperature of the crystal ( or somethign
> nearby) which feeds that measurement to the OS. the revised ntp then
> reads the temperature, and corrects the drift rate as a function of that
> temperature.

Anything which measures temperature to provide a compensation for XO frequency
is a "TCXO" which is an acronym for "Temperature Compensated Crystal 
Oscillator".

There are details which matter; see: [1].

> This is all without controlling the temperature of the oscillator (TCXO)
> but rather measuring that temperature-- much cheaper.

Something which controls the temperature of the oscillator is an OCXO,
which is an "Oven Controlled Crystal Oscillator".

Regards,
-- 
-Chuck

[1]: If you wanted to distinguish between a precalibrated analog feedback 
circuit
commonly included within the package and external compensation via a digital
temp sensor (perhaps located on the motherboard chipset) and a lookup table,
ie, ATCXO vs DCXO, fine.  Good definitions here:

http://www.radio-electronics.com/info/data/crystals/tcxo.php

The lookup mechanism described above would be adjusting the kernel's tick values
(ie, how many ticks it counts per second) and not providing a voltage change--
aka VCXO-- to change the actual crystal oscillation frequency.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Paul  wrote:
> On Thu, Feb 12, 2015 at 12:00 PM, William Unruh  wrote:
>
>> This means that if you are using say a PPS source, which gives
>> microsecond long term offset, it can take many hours to get there
>>
>
> This has been asserted and corrected before -- as in years ago*.  A
> properly configured Linux system with a PPS reference will achieve
> best-possible short-term performance between 300-1200 seconds**.  This
> should be microsecond offset and jitter.  An optimal drift estimate may
> take longer.
>
> *It wouldn't suprise me if it was Mills correcting you.
> **Depending on initial conditions.

It was based on measurements I made with ntpd See for example 
www.theory.physics.ubc.ca/chrony/chrony.html
See the section toward the end Chrony vs NTP comparison for the rate
convergence and the offset convergence of ntpd vs chrony.
The exponential decay of the offset and of the rate had a time scale of
about .05 day or about 1 hour. Ie, eac hour the offset would drop in
half. I one goes from 1 ms to 1 us that is 10 decay times or about half
a day. 

Note that the how long it takes to converge depends on the error that
needs correcting. 

Those are based on experiments, not theory. 





___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Harlan Stenn  wrote:
> Bill,
>
> So you believe:
>
> - the broken linux kernel behavior is an acceptable (or at least
>   excusable) fact of life,

Of course not. However, it IS a fact of life, and I have to live in the
real world. nptd spends many lines of code correcting for rare
conditions in the real world. But not this one. 

>
> - that should have been predicted and accommodated by stable-running
>   software and algorithms that have been around for decades,

That the kernel people screwed up was perhaps unpredictable. That clocks
could have drift rates substantiallydifferent from 1 sec/sec could have
been predicted. 

>
> - where no other kernel has ever misbehaved in this way,
>
> - and other projects should deal with that mess;
>
> - and chrony, a program with one design goal of closely tracking a
>   master avoids this kernel brokenness.

All of the above are predicated on you wrong assumption that I thought
that the kernel screwup could be predicted. 

>
> And the net effect of the above indicates a shortcoming in the way NTP
> was designed, right?

The inability to deal with the real world, when that is one of its
design goals IS a shortcoming in NTP, yes. 

>
> That's OK, and it's why I don't take your messages very seriously.

Of course I cannot make you take anything seriously. I would have
thought that designing ntpd to handle the real world would be something
you take seriously. And that when you discover a feature of the real
world that ntpd does not handle but could, that you would seriously
consider changing ntpd so that it does. 

>
> H
>
> William Unruh writes:
>> On 2015-02-11, Charles Swiger  wrote:
>> > On Feb 11, 2015, at 7:23 AM, Rob  wrote:
>> >> But I see it has also been explained elsewhere in the thread: ntpd has
>> >> a maximum on the momentary drift of 500ppm, no matter if it is static
>> >> or dynamic or the sum of two.  I think that is not warranted.
>> >
>> > Do you believe that a clock which loses or gains over a minute per day
>> > should be assumed to be trustworthy?
>> >
>> > Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz
>> > waves from the AC line will do better than that.  While the power grid
>> > frequency fluctuates in the short term due to load with similar magnitude o
>> f
>> > error, the utilities make an effort to correct the time during non-peak
>> > hours with slew rates of 200 - 333 ppm so that AC synchronous clocks
>> > see 86400 seconds per day.
>> >
>> >> There are also other problems with dealing with a variable drift.
>> >> I know from observations that ntpd does not attempt to handle a
>> >> changing drift, it only tries to lock in to the momentary drift and
>> >> when that is changing, it keeps chasing the drift (resulting in an offset)
>> .
>> >
>> > chrony supposedly chases the short-term offset more aggressively than
>> > ntpd does, if that's what you prefer.
>> >
>> >> In practice a changing drift is often caused by changing temperature,
>> >> and it would be better to take the first derivative into account as well.
>> >
>> > Certainly it is true that changing temperature will cause a change in cryst
>> al
>> > frequency, on the order of ppm's to tens of ppm's per 10 C temperature chan
>> ge.
>> >
>> > But if you're willing to tolerate over 500ppm systemic error, why worry abo
>> ut
>> > a second-order effect in the 10s of ppm's?
>> 
>> A few kernels ago, Linux kernel had problems in calibrating the system
>> clock. It would be off by up to a few 100 PPM, and change from one boot
>> to the next. Ie, this was a consistant drift error. It could be zeroed
>> out using adjtimex, but ntpd is supposed to handle the clock, not demand
>> people fixing things by hand. chrony had no problem. It uses both the
>> frequency and the tick rate adjustments of admtimex. ntpd could have a
>> problem if the linux clock was off by say 400PPM in which case it would
>> leave little headroom for normal operation.
>> Of course the "right" procedure would be to fix the kernel, and that was
>> eventually done, but that eventually was on the order of a year or two. 
>> Were all Linux people to give up disciplining their clocks while waiting
>> for the kernel people to get their act together? That hardly seems
>> sensible advice. 
>> 
>> ___
>> questions mailing list
>> questions@lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Harlan Stenn  wrote:
> William Unruh writes:
>> ...  And what happens to B when A suddenly begins to
>> slew at 2000PPM?
>
> And how often does this happen?  Why does it happen?
>
> I'm pretty sure that ntpd will notice this and declare that source a
> falseticker quickly enough.

I agree, assuming ntpd is using enough other good sources. I was in fact
giving you ammuntion with that statement. Ie, if one increased the
default handling rate of ntpd from 500 PPM, then what would happen a
clock that B depended on suddenly sped up by 2000PPM, especially if A
depends only on that clock.  I do not know. could that cause
instabilities in ntp? I do not know. 


>
> Chrony and ntpd have fundamentally different definitions of what it
> means to "provide good time".

Not really. But it should be distrubing that chrony disciplines clocks
much better ( lower jitter) than does ntpd in normal situations. Why?
And does that have lessons that ntpd could learn from? 

>
> I don't respond to 1 in 8 of your messages.  More or less...

And as with ntpd does that mean you track the truth much more poorly
that if you did? :-)


>
> H

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Charles Swiger  wrote:
> On Feb 12, 2015, at 1:56 AM, Rob  wrote:
>> Charles Swiger  wrote:
>>> On Feb 11, 2015, at 7:23 AM, Rob  wrote:

>
>> However, what I observe is that the plots of the offset show the derivative
>> of the environment temperature, which unfortunately cannot be controlled
>> any better.  I am considering to locate the crystal that is responsible
>> for the timing and see if it could be ovenized or replaced by a more
>> temperature-stable oscillator.  However, one can argue that it could be
>> fixed in software as well.  ntpd could sense a changing drift and extrapolate
>> it, if necessary helped by input from a temperature sensor.
>
> You're describing a TCXO; using a temperature sensor to compensate for thermal
> drift would gain perhaps a factor of 5 accuracy.

No, that is a hardware solution. There are software solutions-- a
termistor to meaure the temperature of the crystal ( or somethign
nearby) which feeds that measurement to the OS. the revised ntp then
reads the temperature, and corrects the drift rate as a function of that
temperature. This means that the change in the ntpd drift rate does not only 
depend on
the offset meaured but also on that temperature. Since it takes a while
for a temperature to be reflected in the offset, this makes ntpd track
the correct rate of the clock much more closely. Yes, factors of 5 are
easy. Actually, I suspect that oneof the reasons that chrony does so
much better than ntpd does in disciplining the clock ( 2-20 times
better) is because it reacts to such temperature changes much more
rapidly. It can do so because it keeps a memory of the drifts and
offsets and can see changes much more quickly. It also does not throw
away 85% of the measurements to correct round trip errors, so can also
react faster because of that. 
This is all without controlling the temperature of the oscillator (TCXO)
but rather measuring that temperature-- much cheaper.

>
> Regards,

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 12:00 PM, William Unruh  wrote:

> This means that if you are using say a PPS source, which gives
> microsecond long term offset, it can take many hours to get there
>

This has been asserted and corrected before -- as in years ago*.  A
properly configured Linux system with a PPS reference will achieve
best-possible short-term performance between 300-1200 seconds**.  This
should be microsecond offset and jitter.  An optimal drift estimate may
take longer.

*It wouldn't suprise me if it was Mills correcting you.
**Depending on initial conditions.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

William Unruh writes:
> ... (Ie something equivalent to ntpd's arbitrary 1000 sec rule-- ie if
> the clock is out by 1000 sec ntpd gives up). But whether or not it
> should give up, or try its best is something that should be left to
> the user, not to some arbitrary rules by the designer.

Statement like the above are a clear example of why I don't take you
seriously.

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Charles Swiger  wrote:
> On Feb 12, 2015, at 12:49 AM, William Unruh  wrote:
>> On 2015-02-11, Charles Swiger mailto:cswi...@mac.com>> 
>> wrote:
>>> On Feb 11, 2015, at 7:23 AM, Rob >> > wrote:
 But I see it has also been explained elsewhere in the thread: ntpd has
 a maximum on the momentary drift of 500ppm, no matter if it is static
 or dynamic or the sum of two.  I think that is not warranted.
>>> 
>>> Do you believe that a clock which loses or gains over a minute per day
>>> should be assumed to be trustworthy?
> [ ... ]
>> A few kernels ago, Linux kernel had problems in calibrating the system
>> clock. It would be off by up to a few 100 PPM, and change from one boot
>> to the next. Ie, this was a consistant drift error.
>
> Yes-- I had that specific kernel bug in mind.
>
>> It could be zeroed out using adjtimex, but ntpd is supposed to handle the 
>> clock,
>> not demand people fixing things by hand. chrony had no problem.
>
> chrony has a problem if it trusts an obviously broken clock!

Not sure what you mean by this, or which broken clock it is that it is
supposed to trust. If it uses external sources, then it has a similar
selection algorithm just as ntpd has. If you mean itself, then yes, it
tries really hard to discipline the local clock. Whether it should have
some algorithm which shuts it down if the local clock seems to be too
wild, I do not remember if it does or does not. (Ie something equivalent
to ntpd's arbitrary 1000 sec rule-- ie if the clock is out by 1000 sec
ntpd gives up). But whether or not it should give up, or try its best is
something that should be left to the user, not to some arbitrary rules
by the designer. 
It is true that if others depend on that clock, then the responsible
thing to do might be to shut it down. But those foreign systems will
soon enough discover that this clock is crazy and exclude it anyway. 


>
>> It uses both the
>> frequency and the tick rate adjustments of admtimex. ntpd could have a
>> problem if the linux clock was off by say 400PPM in which case it would
>> leave little headroom for normal operation.
>
> For what it's worth, real physical hardware on a non-broken OS seems to
> do fine with only +/- 100 ppm tolerance almost all of the time.  I've
> looked for counterexamples in a large fleet, but the only things I saw
> with an ntp.drift value beyond 100ppm were VMs.

I had much bigger drifts than that when the linux kernel bug was in
place.  But I agree that the variation of the rate is less than 100 ppm.
and often less than 1ppm. 

>
>> Of course the "right" procedure would be to fix the kernel, and that was
>> eventually done, but that eventually was on the order of a year or two. 
>
> That's exactly right.  From that situation, I drew the conclusion that
> precise timekeeping wasn't a priority for the Linux project.

Or that the people at responsible for the timing did not understand what
the kernel was doing or why. It is a rather complex piece of code. 

>
>> Were all Linux people to give up disciplining their clocks while waiting
>> for the kernel people to get their act together? That hardly seems
>> sensible advice. 
>
> I recall advising anyone who cared about precise timekeeping to run
> FreeBSD, NetBSD, or even maybe OpenSolaris instead of Linux.

Linux was fine, after that intial transient was done with. Chrony fixed
it very quickly (much less than an hour) ntpd had much more difficulty with
it.
>
> And yes, I fully understand that some folks have a homogenous environment
> and lack the flexibility to select the best platform for a particular purpose.
> Been there, had thousands of java processes on Linux VMs get wonky with
> the June 2012 leap second due to adjtimex() kernel hang.
>
> Regards,

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

William Unruh writes:
> ...  And what happens to B when A suddenly begins to
> slew at 2000PPM?

And how often does this happen?  Why does it happen?

I'm pretty sure that ntpd will notice this and declare that source a
falseticker quickly enough.

Chrony and ntpd have fundamentally different definitions of what it
means to "provide good time".

I don't respond to 1 in 8 of your messages.  More or less...

H

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

catherine.wei1...@gmail.com writes:
> Yes,I just tested it and found that the synchronization of NTP is
> really slow.

It's well documented.  Adjustments are made at the rate of 500ppm.  By
default that will happen for corrections of up to 128ms.

500ppm is about 43 seconds/day, and a correction of 128ms will take
about 256 seconds' time to apply.

Otherwise the clock will be "stepped", so the correction is immediately
applied.

One can change some of these behaviors.  I believe that of the people
who change these behaviors, very few of them properly understand all of
the consequences of what they are doing.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

David Taylor  wrote:
> On 12/02/2015 17:00, William Unruh wrote:
> []
>> This means that if you are using say a PPS source, which gives
>> microsecond long term offset, it can take many hours to get there, even
>> if you or I looking at the offsets could see that it is off by ms after
>> the first few poll intervals.
> []
>
> Almost all of my NTP servers were restarted today after downloading and 
> compiling NTP 4.3.0.  From the graphs plotting offset versus time:
>
>http://www.satsignal.eu/mrtg/performance_ntp.php
>
> it seems to me that for the PPS-drived devices, 10 microseconds offset 
> was reached within a few minutes, and full stability within an hour (say 
> within a couple of microseconds).  Yes, it's not immediate, but it's not 
> "many hours" that I see here.

That is what I see here as well with 4.2.7/4.2.8 versions.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

Charles Swiger  wrote:
>> However, what I observe is that the plots of the offset show the derivative
>> of the environment temperature, which unfortunately cannot be controlled
>> any better.  I am considering to locate the crystal that is responsible
>> for the timing and see if it could be ovenized or replaced by a more
>> temperature-stable oscillator.  However, one can argue that it could be
>> fixed in software as well.  ntpd could sense a changing drift and extrapolate
>> it, if necessary helped by input from a temperature sensor.
>
> You're describing a TCXO; using a temperature sensor to compensate for thermal
> drift would gain perhaps a factor of 5 accuracy.

A TCXO could be better than what is fixed as standard (these are HP Proliant
and Dell servers), but note that when talking about microsecond accuracy
it will be quite difficult to get a freerunning oscillator that does not
gain a few microseconds per 5 minutes or so.

So there will always be a need for compensation.
(I would add a graph showing the offset when it would be possible on usenet)

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

Bill,

So you believe:

- the broken linux kernel behavior is an acceptable (or at least
  excusable) fact of life,

- that should have been predicted and accommodated by stable-running
  software and algorithms that have been around for decades,

- where no other kernel has ever misbehaved in this way,

- and other projects should deal with that mess;

- and chrony, a program with one design goal of closely tracking a
  master avoids this kernel brokenness.

And the net effect of the above indicates a shortcoming in the way NTP
was designed, right?

That's OK, and it's why I don't take your messages very seriously.

H

William Unruh writes:
> On 2015-02-11, Charles Swiger  wrote:
> > On Feb 11, 2015, at 7:23 AM, Rob  wrote:
> >> But I see it has also been explained elsewhere in the thread: ntpd has
> >> a maximum on the momentary drift of 500ppm, no matter if it is static
> >> or dynamic or the sum of two.  I think that is not warranted.
> >
> > Do you believe that a clock which loses or gains over a minute per day
> > should be assumed to be trustworthy?
> >
> > Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz
> > waves from the AC line will do better than that.  While the power grid
> > frequency fluctuates in the short term due to load with similar magnitude o
> f
> > error, the utilities make an effort to correct the time during non-peak
> > hours with slew rates of 200 - 333 ppm so that AC synchronous clocks
> > see 86400 seconds per day.
> >
> >> There are also other problems with dealing with a variable drift.
> >> I know from observations that ntpd does not attempt to handle a
> >> changing drift, it only tries to lock in to the momentary drift and
> >> when that is changing, it keeps chasing the drift (resulting in an offset)
> .
> >
> > chrony supposedly chases the short-term offset more aggressively than
> > ntpd does, if that's what you prefer.
> >
> >> In practice a changing drift is often caused by changing temperature,
> >> and it would be better to take the first derivative into account as well.
> >
> > Certainly it is true that changing temperature will cause a change in cryst
> al
> > frequency, on the order of ppm's to tens of ppm's per 10 C temperature chan
> ge.
> >
> > But if you're willing to tolerate over 500ppm systemic error, why worry abo
> ut
> > a second-order effect in the 10s of ppm's?
> 
> A few kernels ago, Linux kernel had problems in calibrating the system
> clock. It would be off by up to a few 100 PPM, and change from one boot
> to the next. Ie, this was a consistant drift error. It could be zeroed
> out using adjtimex, but ntpd is supposed to handle the clock, not demand
> people fixing things by hand. chrony had no problem. It uses both the
> frequency and the tick rate adjustments of admtimex. ntpd could have a
> problem if the linux clock was off by say 400PPM in which case it would
> leave little headroom for normal operation.
> Of course the "right" procedure would be to fix the kernel, and that was
> eventually done, but that eventually was on the order of a year or two. 
> Were all Linux people to give up disciplining their clocks while waiting
> for the kernel people to get their act together? That hardly seems
> sensible advice. 
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[David Taylor]

On 12/02/2015 17:00, William Unruh wrote:
[]

This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there, even
if you or I looking at the offsets could see that it is off by ms after
the first few poll intervals.

[]

Almost all of my NTP servers were restarted today after downloading and 
compiling NTP 4.3.0.  From the graphs plotting offset versus time:


  http://www.satsignal.eu/mrtg/performance_ntp.php

it seems to me that for the PPS-drived devices, 10 microseconds offset 
was reached within a few minutes, and full stability within an hour (say 
within a couple of microseconds).  Yes, it's not immediate, but it's not 
"many hours" that I see here.


--
Cheers,
David
Web: http://www.satsignal.eu

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Charles Swiger]

On Feb 12, 2015, at 1:56 AM, Rob  wrote:
> Charles Swiger  wrote:
>> On Feb 11, 2015, at 7:23 AM, Rob  wrote:
>>> But I see it has also been explained elsewhere in the thread: ntpd has
>>> a maximum on the momentary drift of 500ppm, no matter if it is static
>>> or dynamic or the sum of two.  I think that is not warranted.
>> 
>> Do you believe that a clock which loses or gains over a minute per day
>> should be assumed to be trustworthy?
>> 
>> Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz
>> waves from the AC line will do better than that.  While the power grid
>> frequency fluctuates in the short term due to load with similar magnitude of
>> error, the utilities make an effort to correct the time during non-peak
>> hours with slew rates of 200 - 333 ppm so that AC synchronous clocks
>> see 86400 seconds per day.
> 
> That cannot be compared at all!  The grid is locked to atomic clocks, a
> clock running on AC will on the average keep very good time.

The grid isn't-- can't be-- locked to atomic clocks during periods of high load.

That's aside from the key point, however.  At what point should you decide
that a potential timesource is not trustworthy?

> A computer clock is driven by a crystal and is not locked to anything
> until you use something like ntpd to lock it.

Yes.  However, before you can lock the local computer clock to a remote 
timesource,
you need to perform some level of sanity checking.  If you wait 1024 local 
seconds,
and the remote timesource agrees that ~1024 seconds plus or minus a fraction of
a second have passed, that's fine.

If the remote timesource thinks 1022 or 1026 seconds have passed, however,
one side or the other is exhibiting a ~5 minute per day error.

[ ... ]
>>> In practice a changing drift is often caused by changing temperature,
>>> and it would be better to take the first derivative into account as well.
>> 
>> Certainly it is true that changing temperature will cause a change in crystal
>> frequency, on the order of ppm's to tens of ppm's per 10 C temperature 
>> change.
>> 
>> But if you're willing to tolerate over 500ppm systemic error, why worry about
>> a second-order effect in the 10s of ppm's?
> 
> Those two things are not related.  I have some systems that I need to
> keep within a few microseconds (with PPS) and those do not have that
> 500ppm error (none of my systems do), they usually within about 30ppm.

Yes.  A drift of 30 ppm is reasonable and common for commodity hardware.

If you examined a hundred physical machines, I'd be surprised if you found
more than one or two which was worse than 100 ppm.

> However, what I observe is that the plots of the offset show the derivative
> of the environment temperature, which unfortunately cannot be controlled
> any better.  I am considering to locate the crystal that is responsible
> for the timing and see if it could be ovenized or replaced by a more
> temperature-stable oscillator.  However, one can argue that it could be
> fixed in software as well.  ntpd could sense a changing drift and extrapolate
> it, if necessary helped by input from a temperature sensor.

You're describing a TCXO; using a temperature sensor to compensate for thermal
drift would gain perhaps a factor of 5 accuracy.

Regards,
-- 
-Chuck


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Rob  wrote:
> William Unruh  wrote:
>> On 2015-02-12, Rob  wrote:
>>> Brian Inglis  wrote:
 On 2015-02-12 03:00, Rob wrote:
> catherine.wei1...@gmail.com  wrote:
>> Yes,I just tested it and found that the synchronization of NTP is really 
>> slow.
>
> That is because ntpd is not designed to correct arbitrary errors that
> you have applied externally.  It is designed to lock to the correct time
> and stay locked to that (within a few milliseconds when you use the 
> network,
> or within a few microseconds when you have a local reference).
>
> The typical "acceptance test" scenario of "let's set the clock one hour
> wrong while the system is running and see that ntpd corrects it" just is
> not going to work.  Drop that test, it should not be on the test list
> for ntpd.  When you need that test, use another product.

 The test should be:
 set the clock one hour wrong;
 start ntpd -g;
 measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of 
 UTC;
>>>
>>> Yes, that would work.  But that was obviously not how it was tested and
>>> I have seen this kind of posting here many times.  It is apparently a
>>> common (wrong) way of testing.
>>
>> She never said how she tested it, so making assumptions and then blaming
>> her on the basis of those assumptions is hardly fair. 
>
> She did.  It was written in the first post that the time on the system

OK, I did not remember that it was the same person. However, this comment
she made was not necessarily based on that same test. She might have
learned when she was disciplined by the group, and tried a different
test (eg set the clock wrong by 100ms and see how long it takes to
recover).

> clock was manually changed by one hour and then the offset was monitored.

Which should have waited for 900 sec, and then the clock was stepped. 
By the way, I do nt know whether ntpd suspends all clock discipline in
that 900 sec, or whether the discipline continues. Ie, in that 900 sec
does ntpd try to get rid of that offset by changing the drift rate or
does it hold any such drift changes in abayance while it waits to see if
this was just an anomaly?

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Philip Homburg]

In article ,
William Unruh   wrote:
>The complaint of the ntpd people is not the stability of the machine
>itself, but the stability of the network, where for example A could use
>B and B use A in determining its own time. Is the whole network stable
>under this kind of loop. And what happens to B when A suddenly begins to
>slew at 2000PPM?

This cannot happen (at least in my implementation). If A uses B as ref clock
and B uses A then you the same effect as a routing loop in a distance vector
routing protocol: counting to infinity.

In the case of NTP, infinity is 16 hops. After that both A and B consider
each other unusable.


-- 
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Charles Swiger]

On Feb 12, 2015, at 12:49 AM, William Unruh  wrote:
> On 2015-02-11, Charles Swiger mailto:cswi...@mac.com>> 
> wrote:
>> On Feb 11, 2015, at 7:23 AM, Rob > > wrote:
>>> But I see it has also been explained elsewhere in the thread: ntpd has
>>> a maximum on the momentary drift of 500ppm, no matter if it is static
>>> or dynamic or the sum of two.  I think that is not warranted.
>> 
>> Do you believe that a clock which loses or gains over a minute per day
>> should be assumed to be trustworthy?
[ ... ]
> A few kernels ago, Linux kernel had problems in calibrating the system
> clock. It would be off by up to a few 100 PPM, and change from one boot
> to the next. Ie, this was a consistant drift error.

Yes-- I had that specific kernel bug in mind.

> It could be zeroed out using adjtimex, but ntpd is supposed to handle the 
> clock,
> not demand people fixing things by hand. chrony had no problem.

chrony has a problem if it trusts an obviously broken clock!

> It uses both the
> frequency and the tick rate adjustments of admtimex. ntpd could have a
> problem if the linux clock was off by say 400PPM in which case it would
> leave little headroom for normal operation.

For what it's worth, real physical hardware on a non-broken OS seems to
do fine with only +/- 100 ppm tolerance almost all of the time.  I've
looked for counterexamples in a large fleet, but the only things I saw
with an ntp.drift value beyond 100ppm were VMs.

> Of course the "right" procedure would be to fix the kernel, and that was
> eventually done, but that eventually was on the order of a year or two. 

That's exactly right.  From that situation, I drew the conclusion that
precise timekeeping wasn't a priority for the Linux project.

> Were all Linux people to give up disciplining their clocks while waiting
> for the kernel people to get their act together? That hardly seems
> sensible advice. 

I recall advising anyone who cared about precise timekeeping to run
FreeBSD, NetBSD, or even maybe OpenSolaris instead of Linux.

And yes, I fully understand that some folks have a homogenous environment
and lack the flexibility to select the best platform for a particular purpose.
Been there, had thousands of java processes on Linux VMs get wonky with
the June 2012 leap second due to adjtimex() kernel hang.

Regards,
-- 
-Chuck


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

William Unruh  wrote:
> On 2015-02-12, Rob  wrote:
>> Brian Inglis  wrote:
>>> On 2015-02-12 03:00, Rob wrote:
 catherine.wei1...@gmail.com  wrote:
> Yes,I just tested it and found that the synchronization of NTP is really 
> slow.

 That is because ntpd is not designed to correct arbitrary errors that
 you have applied externally.  It is designed to lock to the correct time
 and stay locked to that (within a few milliseconds when you use the 
 network,
 or within a few microseconds when you have a local reference).

 The typical "acceptance test" scenario of "let's set the clock one hour
 wrong while the system is running and see that ntpd corrects it" just is
 not going to work.  Drop that test, it should not be on the test list
 for ntpd.  When you need that test, use another product.
>>>
>>> The test should be:
>>> set the clock one hour wrong;
>>> start ntpd -g;
>>> measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC;
>>
>> Yes, that would work.  But that was obviously not how it was tested and
>> I have seen this kind of posting here many times.  It is apparently a
>> common (wrong) way of testing.
>
> She never said how she tested it, so making assumptions and then blaming
> her on the basis of those assumptions is hardly fair. 

She did.  It was written in the first post that the time on the system
clock was manually changed by one hour and then the offset was monitored.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Rob  wrote:
> Charles Swiger  wrote:
>> On Feb 11, 2015, at 7:23 AM, Rob  wrote:
> Yes I would prefer that, but chrony does not support local references
> so it is useless to me.

Yes, it does and has for about 3 or 4 years now. 


>
>>> In practice a changing drift is often caused by changing temperature,
>>> and it would be better to take the first derivative into account as well.
>>
>> Certainly it is true that changing temperature will cause a change in crystal
>> frequency, on the order of ppm's to tens of ppm's per 10 C temperature 
>> change.
>>
>> But if you're willing to tolerate over 500ppm systemic error, why worry about
>> a second-order effect in the 10s of ppm's?
>
> Those two things are not related.  I have some systems that I need to
> keep within a few microseconds (with PPS) and those do not have that
> 500ppm error (none of my systems do), they usually within about 30ppm.
>
> However, what I observe is that the plots of the offset show the derivative
> of the environment temperature, which unfortunately cannot be controlled
> any better.  I am considering to locate the crystal that is responsible
> for the timing and see if it could be ovenized or replaced by a more
> temperature-stable oscillator.  However, one can argue that it could be
> fixed in software as well.  ntpd could sense a changing drift and extrapolate
> it, if necessary helped by input from a temperature sensor.

ntp is a very simple feedback loop. It does not have a memory except for
current drift. It never extrapolates. 
Note that versions of ntpd with temperature input have been created and
posted over the years, and they do result in a much tighter control of
the time. 
I do not have a reference to them but googling or waiting for others on
the list will supply the references quickly.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Philip Homburg  wrote:
> In article <54db57a8.4030...@oracle.com>,
> brian utterback   wrote:
>>Dr. Mills crafted a wonderful piece of software, amazing for its time,
>>but he no longer actively engages us much at all. I understand, that
>>isn't his fault. But no one who does actively engage really understands
>>it or knows how to improve it. Unruh has a point, we don't know if there
>>isn't a better way built on statistical analysis. Perhaps a hybrid
>>between the two approaches would be better still. But we don't even know
>>the consequences of changing a single constant with any degree of
>>certainty.
>
> Some time during the mid 90s, I created a new type of control loop and wrote
> an NTP implementation that uses it. In testing I verified that it is stable at
> slew rates of 10 ppm. No need to go beyond that. 
>
> But I have no way of proving that it is correct. At the time I felt it would
> take too much energy to convince Dave Mills to adopt it, and I didn't want to
> promote a competing NTP implementation either. So I'm just running it for
> my own ammusement.
>
> If people feel a strong need to go beyond what NTP does (and are willing to
> write the specs, code, etc.) then I can try to dig out what I still have
> in this area.

chrony already does this on Linux. It uses both the fine slew and the
tickadj on adjtimex to enable slew rate up to 10 ppm, the limit of
the tickadj.
The complaint of the ntpd people is not the stability of the machine
itself, but the stability of the network, where for example A could use
B and B use A in determining its own time. Is the whole network stable
under this kind of loop. And what happens to B when A suddenly begins to
slew at 2000PPM?
Note the "suddenly". Rarely is it the case that the drift rate of A will
suddenly change by 500PPM. But that A's clock could be stably out by
500PPM IS possible. ntpd does not differentiate between those cases. 

Also ntpd has to concern itself with cases in this it is not the kernel
that adjusts the drift, but ntp itself with its own "once per second"
internal slewing. That this takes place only once per second adds in an
additional problem. chrony does not have its own internal slew. It only
uses the kernel (adjtimex) to alter the clock rate.


>
>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, Rob  wrote:
> Brian Inglis  wrote:
>> On 2015-02-12 03:00, Rob wrote:
>>> catherine.wei1...@gmail.com  wrote:
 Yes,I just tested it and found that the synchronization of NTP is really 
 slow.
>>>
>>> That is because ntpd is not designed to correct arbitrary errors that
>>> you have applied externally.  It is designed to lock to the correct time
>>> and stay locked to that (within a few milliseconds when you use the network,
>>> or within a few microseconds when you have a local reference).
>>>
>>> The typical "acceptance test" scenario of "let's set the clock one hour
>>> wrong while the system is running and see that ntpd corrects it" just is
>>> not going to work.  Drop that test, it should not be on the test list
>>> for ntpd.  When you need that test, use another product.
>>
>> The test should be:
>> set the clock one hour wrong;
>> start ntpd -g;
>> measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC;
>
> Yes, that would work.  But that was obviously not how it was tested and
> I have seen this kind of posting here many times.  It is apparently a
> common (wrong) way of testing.

She never said how she tested it, so making assumptions and then blaming
her on the basis of those assumptions is hardly fair. 

A scenario where one could be out by a second is the leap second.
Suddenly the remote clock reports that your local time is out by a
second. Your local clock begins to slew to correct that, but after many
seconds your local ntpd decides to step, but its slew rate is now wrong,
and it must correct that. How long does it take to settle down again?
That is not only a valid test, but one that many many instances of ntpd
run into, because for example, their source does not properly report
leap seconds.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Philip Homburg]

In article <54db57a8.4030...@oracle.com>,
brian utterback   wrote:
>Dr. Mills crafted a wonderful piece of software, amazing for its time,
>but he no longer actively engages us much at all. I understand, that
>isn't his fault. But no one who does actively engage really understands
>it or knows how to improve it. Unruh has a point, we don't know if there
>isn't a better way built on statistical analysis. Perhaps a hybrid
>between the two approaches would be better still. But we don't even know
>the consequences of changing a single constant with any degree of
>certainty.

Some time during the mid 90s, I created a new type of control loop and wrote
an NTP implementation that uses it. In testing I verified that it is stable at
slew rates of 10 ppm. No need to go beyond that. 

But I have no way of proving that it is correct. At the time I felt it would
take too much energy to convince Dave Mills to adopt it, and I didn't want to
promote a competing NTP implementation either. So I'm just running it for
my own ammusement.

If people feel a strong need to go beyond what NTP does (and are willing to
write the specs, code, etc.) then I can try to dig out what I still have
in this area.


-- 
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-12, catherine.wei1...@gmail.com  wrote:
> On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote:
>> On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
>> > However, when I wait for several minutes, the time can be adjusted to
>> > the right time. I couldn't see the gradual changes of offset. Is that
>> > normal?
>> 
>> Assuming that you're using a minimalistic configuration: Yes.
>> 
>> ntpd would take almost three months to *gradually* eliminate (slew) one
>> hour of offset, so as soon as the
>> offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
>> gave up all hope for the universe and "just set the clock" hard (step).
>> 
>> Regards,
>>  J. Bern
>> -- 
>> *NEU* - NEC IT-Infrastruktur-Produkte im :
>> Server--Storage--Virtualisierung--Management SW--Passion for Performance
>> Jochen Bern, Systemingenieur --- LINworks GmbH 
>> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
>> PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
>> Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
>> Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel
>
>
>
> Yes,I just tested it and found that the synchronization of NTP is really slow.

There are two parts to this. The first is the large offset problem,
where delta t is many seconds. Here the 500PPM problem sets in and it
would take forever to fix that offset, so ntpd simply steps the clock if
the offset is greater than 128us, and quits if greater than 1000 sec
(unless you use the -g in which case it fixes that large an offset
once).
The other is if you have an offset of say 50ms, The ntpd takes a long
time because of design decisions. a) ntpd throws away about 7 out of 8
polls in order to "fix" the problem of wildly varying round trip times
even if there are no such wildly varying offset times. That makes the
effective poll interval 8 times longer than the actual poll interval.
And then ntpd only slowly changes to the drift rate to fix that offset
in order to keep the running of ntpd stable. The simply feedback loop
used by ntpd could go unstable if it changed the drift rate too quickly,
because the decision was to use an very simply  feedback mechanism to
run ntpd. (Probably on the KISS principle, and because it is easily
analysed to determine stability).
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there, even
if you or I looking at the offsets could see that it is off by ms after
the first few poll intervals. 
The decision to have stability and simplicity over speed was made a long
time ago by Mills.  It was not a bad decision, especially in the early
days when round trip times did fluctuate wildly sometimes, and where ms
resolution was doing well. Now that usec and nsec resolution is
possible, the design decisions are a bit more problematic.

>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

Brian Inglis  wrote:
> On 2015-02-12 03:00, Rob wrote:
>> catherine.wei1...@gmail.com  wrote:
>>> Yes,I just tested it and found that the synchronization of NTP is really 
>>> slow.
>>
>> That is because ntpd is not designed to correct arbitrary errors that
>> you have applied externally.  It is designed to lock to the correct time
>> and stay locked to that (within a few milliseconds when you use the network,
>> or within a few microseconds when you have a local reference).
>>
>> The typical "acceptance test" scenario of "let's set the clock one hour
>> wrong while the system is running and see that ntpd corrects it" just is
>> not going to work.  Drop that test, it should not be on the test list
>> for ntpd.  When you need that test, use another product.
>
> The test should be:
> set the clock one hour wrong;
> start ntpd -g;
> measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC;

Yes, that would work.  But that was obviously not how it was tested and
I have seen this kind of posting here many times.  It is apparently a
common (wrong) way of testing.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Thu, Feb 12, 2015 at 3:43 AM, William Unruh  wrote:

> It is hard to complain about a non-existant product.


As has been previously mentioned ntimed(-client) is in early release.  I've
been running it since late December.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Brian Inglis]

On 2015-02-12 03:00, Rob wrote:

catherine.wei1...@gmail.com  wrote:

Yes,I just tested it and found that the synchronization of NTP is really slow.


That is because ntpd is not designed to correct arbitrary errors that
you have applied externally.  It is designed to lock to the correct time
and stay locked to that (within a few milliseconds when you use the network,
or within a few microseconds when you have a local reference).

The typical "acceptance test" scenario of "let's set the clock one hour
wrong while the system is running and see that ntpd corrects it" just is
not going to work.  Drop that test, it should not be on the test list
for ntpd.  When you need that test, use another product.


The test should be:
set the clock one hour wrong;
start ntpd -g;
measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC;
measure offset, jitter, and wander throughout the next 24 hours;
perhaps load test with 1, 10, 100, ... clients running every 16...64 seconds,
while measuring process CPU and port 123 network loads.

Sounds like some work including setup, data collection, and analysis. ;^>
--
Take care. Thanks, Brian Inglis
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

catherine.wei1...@gmail.com  wrote:
> Yes,I just tested it and found that the synchronization of NTP is really slow.

That is because ntpd is not designed to correct arbitrary errors that
you have applied externally.  It is designed to lock to the correct time
and stay locked to that (within a few milliseconds when you use the network,
or within a few microseconds when you have a local reference).

The typical "acceptance test" scenario of "let's set the clock one hour
wrong while the system is running and see that ntpd corrects it" just is
not going to work.  Drop that test, it should not be on the test list
for ntpd.  When you need that test, use another product.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

Charles Swiger  wrote:
> On Feb 11, 2015, at 7:23 AM, Rob  wrote:
>> But I see it has also been explained elsewhere in the thread: ntpd has
>> a maximum on the momentary drift of 500ppm, no matter if it is static
>> or dynamic or the sum of two.  I think that is not warranted.
>
> Do you believe that a clock which loses or gains over a minute per day
> should be assumed to be trustworthy?
>
> Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz
> waves from the AC line will do better than that.  While the power grid
> frequency fluctuates in the short term due to load with similar magnitude of
> error, the utilities make an effort to correct the time during non-peak
> hours with slew rates of 200 - 333 ppm so that AC synchronous clocks
> see 86400 seconds per day.

That cannot be compared at all!  The grid is locked to atomic clocks, a
clock running on AC will on the average keep very good time.
A computer clock is driven by a crystal and is not locked to anything
until you use something like ntpd to lock it.
The actual frequency of the crystal has some tolerance, and with today's
race to the bottom in prices and quality one really cannot depend on the
accuracy.  For example, when I recently compared some soundcards (similar
issue), a 100ppm error appears to be the norm, even though a crystal
oscillator with some care should be within 10-20ppm.  However, the just
isn't any care anymore.

I personally don't experience problems due to the 500ppm limit right now,
but I would not preclude that it would happen to others, or to me in the
future.

>> There are also other problems with dealing with a variable drift.
>> I know from observations that ntpd does not attempt to handle a
>> changing drift, it only tries to lock in to the momentary drift and
>> when that is changing, it keeps chasing the drift (resulting in an offset).
>
> chrony supposedly chases the short-term offset more aggressively than
> ntpd does, if that's what you prefer.

Yes I would prefer that, but chrony does not support local references
so it is useless to me.

>> In practice a changing drift is often caused by changing temperature,
>> and it would be better to take the first derivative into account as well.
>
> Certainly it is true that changing temperature will cause a change in crystal
> frequency, on the order of ppm's to tens of ppm's per 10 C temperature change.
>
> But if you're willing to tolerate over 500ppm systemic error, why worry about
> a second-order effect in the 10s of ppm's?

Those two things are not related.  I have some systems that I need to
keep within a few microseconds (with PPS) and those do not have that
500ppm error (none of my systems do), they usually within about 30ppm.

However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better.  I am considering to locate the crystal that is responsible
for the timing and see if it could be ovenized or replaced by a more
temperature-stable oscillator.  However, one can argue that it could be
fixed in software as well.  ntpd could sense a changing drift and extrapolate
it, if necessary helped by input from a temperature sensor.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[catherine . wei1989]

On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote:
> On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
> > However, when I wait for several minutes, the time can be adjusted to
> > the right time. I couldn't see the gradual changes of offset. Is that
> > normal?
> 
> Assuming that you're using a minimalistic configuration: Yes.
> 
> ntpd would take almost three months to *gradually* eliminate (slew) one
> hour of offset, so as soon as the
> offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
> gave up all hope for the universe and "just set the clock" hard (step).
> 
> Regards,
>   J. Bern
> -- 
> *NEU* - NEC IT-Infrastruktur-Produkte im :
> Server--Storage--Virtualisierung--Management SW--Passion for Performance
> Jochen Bern, Systemingenieur --- LINworks GmbH 
> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
> PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
> Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
> Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel



Yes,I just tested it and found that the synchronization of NTP is really slow.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-11, Paul  wrote:
> On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn  wrote:
>
>> There are times "repair" is perfectly acceptable, and we do that.
>>
>> There are times "replace" is better, and we do that.
>>
>
> My point is a long drawn-out discussion of changes to the core of ntp seem
> less than productive when the announced way forward is Ntimed (despite
> mentions of NTP5).  Another way of looking at this is that it's time for
> nomail@example and unruh@invalid to start complaining about Ntimed rather
> than ntpd.

It is hard to complain about a non-existant product. 
And I have also let my opinions on the way ntpd works be known, and
would have expected ntimed to either consider them or ignore them a long
time ago.

>
> I certainly expect patches to continue for the NTP v4 branch.

I do agree that this is more than patches. It goes to the design
philosophy of ntp, which is not going to be handled by patches. 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-11, Charles Swiger  wrote:
> On Feb 11, 2015, at 7:23 AM, Rob  wrote:
>> But I see it has also been explained elsewhere in the thread: ntpd has
>> a maximum on the momentary drift of 500ppm, no matter if it is static
>> or dynamic or the sum of two.  I think that is not warranted.
>
> Do you believe that a clock which loses or gains over a minute per day
> should be assumed to be trustworthy?
>
> Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz
> waves from the AC line will do better than that.  While the power grid
> frequency fluctuates in the short term due to load with similar magnitude of
> error, the utilities make an effort to correct the time during non-peak
> hours with slew rates of 200 - 333 ppm so that AC synchronous clocks
> see 86400 seconds per day.
>
>> There are also other problems with dealing with a variable drift.
>> I know from observations that ntpd does not attempt to handle a
>> changing drift, it only tries to lock in to the momentary drift and
>> when that is changing, it keeps chasing the drift (resulting in an offset).
>
> chrony supposedly chases the short-term offset more aggressively than
> ntpd does, if that's what you prefer.
>
>> In practice a changing drift is often caused by changing temperature,
>> and it would be better to take the first derivative into account as well.
>
> Certainly it is true that changing temperature will cause a change in crystal
> frequency, on the order of ppm's to tens of ppm's per 10 C temperature change.
>
> But if you're willing to tolerate over 500ppm systemic error, why worry about
> a second-order effect in the 10s of ppm's?

A few kernels ago, Linux kernel had problems in calibrating the system
clock. It would be off by up to a few 100 PPM, and change from one boot
to the next. Ie, this was a consistant drift error. It could be zeroed
out using adjtimex, but ntpd is supposed to handle the clock, not demand
people fixing things by hand. chrony had no problem. It uses both the
frequency and the tick rate adjustments of admtimex. ntpd could have a
problem if the linux clock was off by say 400PPM in which case it would
leave little headroom for normal operation.
Of course the "right" procedure would be to fix the kernel, and that was
eventually done, but that eventually was on the order of a year or two. 
Were all Linux people to give up disciplining their clocks while waiting
for the kernel people to get their act together? That hardly seems
sensible advice. 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

Paul writes:
> On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn  wrote:
> 
> > There are times "repair" is perfectly acceptable, and we do that.
> >
> > There are times "replace" is better, and we do that.
> 
> My point is a long drawn-out discussion of changes to the core of ntp seem
> less than productive when the announced way forward is Ntimed (despite
> mentions of NTP5).

NTPv5 is a protocol and standards effort that includes software.

That software may include ntimed, it may include the current NTP
codebase.

The reason for this is that most standards can be implemented by
consensus, while folks are figuring out what they want.

That doesn't work with NTP.  With NTP, we have traditionally "made it
work" in the software, then written the spec, and folks study the hell
out of the code and spec to find any places they disagree.  When cases
are found, they are studied and the issue is fixed.  When all of this is
done, we advance the Standard.

But since network time is a meshed network of participating hosts,
having some folks play by different rules can cause problems.  That's
OK, as the system must be robust enough to handle this case.  But it
goes to making sure that what is implemented is sufficient to identify
and deal with a variety of use-cases.

Right now, ntimed is pre-release as a leaf-only client.

That's a far call from everything else the full-on existing NTP codebase
will do.

And we are just about to see if there will be continued funding for NTP
and Ntimed.

> Another way of looking at this is that it's time for nomail@example
> and unruh@invalid to start complaining about Ntimed rather than ntpd.

That's one choice...

> I certainly expect patches to continue for the NTP v4 branch.

The NTPv4 spec hasn't been finalized in the IETF yet either.

No matter which way you look, there is a *lot* of work to do.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Charles Swiger]

On Feb 11, 2015, at 7:23 AM, Rob  wrote:
> But I see it has also been explained elsewhere in the thread: ntpd has
> a maximum on the momentary drift of 500ppm, no matter if it is static
> or dynamic or the sum of two.  I think that is not warranted.

Do you believe that a clock which loses or gains over a minute per day
should be assumed to be trustworthy?

Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz
waves from the AC line will do better than that.  While the power grid
frequency fluctuates in the short term due to load with similar magnitude of
error, the utilities make an effort to correct the time during non-peak
hours with slew rates of 200 - 333 ppm so that AC synchronous clocks
see 86400 seconds per day.

> There are also other problems with dealing with a variable drift.
> I know from observations that ntpd does not attempt to handle a
> changing drift, it only tries to lock in to the momentary drift and
> when that is changing, it keeps chasing the drift (resulting in an offset).

chrony supposedly chases the short-term offset more aggressively than
ntpd does, if that's what you prefer.

> In practice a changing drift is often caused by changing temperature,
> and it would be better to take the first derivative into account as well.

Certainly it is true that changing temperature will cause a change in crystal
frequency, on the order of ppm's to tens of ppm's per 10 C temperature change.

But if you're willing to tolerate over 500ppm systemic error, why worry about
a second-order effect in the 10s of ppm's?

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn  wrote:

> There are times "repair" is perfectly acceptable, and we do that.
>
> There are times "replace" is better, and we do that.
>

My point is a long drawn-out discussion of changes to the core of ntp seem
less than productive when the announced way forward is Ntimed (despite
mentions of NTP5).  Another way of looking at this is that it's time for
nomail@example and unruh@invalid to start complaining about Ntimed rather
than ntpd.

I certainly expect patches to continue for the NTP v4 branch.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

Paul writes:
> On Wed, Feb 11, 2015 at 8:22 AM, brian utterback  > wrote:
> 
> > But no one who does actively engage really understands
> > it or knows how to improve it. Unruh has a point, we don't know if there
> > isn't a better way built on statistical analysis.
> >
> >
> Since it seems the NTF "proposal" is to replace rather than repair
> shouldn't this line of discussion be directed toward the new  software?

There are times "repair" is perfectly acceptable, and we do that.

There are times "replace" is better, and we do that.

H

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-11, Terje Mathisen  wrote:
> William Unruh wrote:
>> On 2015-02-11, Harlan Stenn  wrote:
>>> William Unruh writes:
 On 2015-02-10, Terje Mathisen  wrote:
 And as far as I can see, 500 or 5000 makes little
 difference to the control loop. Yes, it is harder for other systems to
 follow one with a large drift, but it is even harder to follow one that
 jumps, which is what we get now.
>>>
>>> So what's the difference between following a jump and following a
>>> system that applies changes faster than the 500ppm that NTP is designed
>>> for?
>>>
>>> And given that reality bites, what are the tradeoffs between re-synching
>>> after a step and slowly dealing with a know offset error?
>>>
>>> We're talking about choices, and the different effects of these choices.
>>>
>>> It's one thing if a system rarely steps.  It's a bit different if those
>>> steps happen more frequently.
>>
>> Yes. And it is either equally rare that the system will go over 500PPM,
>> but sometimes a computer can have a large "natural" drift, (even over
>> 500PPM) and that will drastically reduce the "headroom" to deal with
>> unusual situations. (ie, if the computers normal drift is 400PPM, that
>> means that the effective cap is only 100PPM, not 500).
>> stepping is much worse than high PPM since it is infinite PPM.
>>
>> Note that were ntpd designed for 5000 PPM then anything else could
>> follow it since it could also do 5000 PPM.
>>
>> Yes, we are talking about choices. And all I was saying was that this
>> particular choice was somewhat arbitrary.
>
> What you seem to disregard is the need for client computers to track a 
> server when that server (or some other up-stream source) is slewing at a 
> larger than 500 ppm rate. (Alternatively, when something happens on the 
> client computer to cause the local clock to start drifting away at high 
> rates.)

Again, I was hypothesising a static drift, not a slew. Yes, other clocks
might have trouble following a 500PPM/minute slew. But also a
100PPM/million one. But they would have no trouble with a 500PPM static
drift.

>
> Let's take your 5000 ppm as a starting point: Independent of the polling 
> interval it will take multiple polls to realize that the server has 
> started to slew, right?

Especially the way ntpd is designed, yes. 

>
> At 5000 ppm we are adjusting by 5 ms every second, which corresponds to 
> over 5 seconds over a single polling period, i.e. far more than the 128 
> ms maximum threshold.

That is why you have a mechanisn to drop the polling period, and 500PPM
in a minute is only 30ms. 
If your clock source has such a severe slew, you have trouble even if it
is only 10PPM/min.

>
> In fact, even a 500 ppm frequency delta means 512 ms over that single 
> poll, so you cannot track any fast changes in frequency if your clock 
> has currently stabilized at 1024 s polls.

That is why ntpd has the ability to change poll intervals. 

>
> With the default minimum poll of 64 sec however, 500 ppm results in just 
> 32 ms of offset, which means that you have 4 full polling periods to 
> realize that you have to adjust the local clock and thereby avoid the 
> 128 ms limit.
>
> It should by now be obvious that the numbers 64 sec, 500 ppm, half of 
> the last 8 samples and 128 ms are all very closely related!

Oh, I do not doubt that they are related. But that does not mean that
they cannot all be changed. 

>
> Yes, it is possible to slew much faster, but only if you start gradually 
> enough that all clients will realize that the dispersion is increasing 
> and that they must reduce the polling interval, and only if you spend at 
> least 4 polling periods for each 500ppm of frequency adjustment you want 
> to apply.

To get back to the discussion, it was on a static drift, not on a wildly
slewing system. 

>
> Terje

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-11, Harlan Stenn  wrote:
> William Unruh writes:
>> On 2015-02-11, Harlan Stenn  wrote:
>> > It's one thing if a system rarely steps.  It's a bit different if those
>> > steps happen more frequently.
>> 
>> Yes. And it is either equally rare that the system will go over 500PPM,
>> but sometimes a computer can have a large "natural" drift, (even over
>> 500PPM) and that will drastically reduce the "headroom" to deal with
>> unusual situations. (ie, if the computers normal drift is 400PPM, that
>> means that the effective cap is only 100PPM, not 500). 
>> stepping is much worse than high PPM since it is infinite PPM. 
>
> Where would you get the idea that a 400ppm swing would be "normal"?
> Or even 200PPM?

I did NOT say a 400PPM swing. I said a static 400PPM drift. That would
then only allow a 100PPM headroom for dynamic drifts. Or if one had a
498PPM static drift, one would be left with a 2PPM headroom. 

>
>> Note that were ntpd designed for 5000 PPM then anything else could
>> follow it since it could also do 5000 PPM. 
>
> Sure, and if it was designed for 10S/S it would handle 10S/S swings.  But
> none of this has been shown to be normal or useful.

Most drifts are static drifts, not swings. ntpd does not differentiate.

>
>> Yes, we are talking about choices. And all I was saying was that this
>> particular choice was somewhat arbitrary. 
>
> That depends on your definition of "somewhat".
>
> More or less, "everything tastes like chicken".  More or less...
>
> H

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-11, Jochen Bern  wrote:
> On 02/11/2015 10:01 AM, Rob wrote:
>> Terje Mathisen  wrote:
>>> The 500 ppm limit is not at all arbitrary!
>>>
>>> In fact, it was originally just 100 ppm, but when too many systems 
>>> turned up with a system clock which was a bit too far out, Prof Mills 
>>> redid the control loop to allow a 500 ppm range.
>>>
>>> It could have been a lot more, but the ultimate stability of the control 
>>> loop is supposed to be better this way.
>> 
>> I think it is hogwash.  The static drift cannot have any influence
>> on the stability of the control loop.  A static drift is just a frequency
>> error that is determined once and can then be forgotten about.
>
> The limit is said to be required in the original mathematical proof of
> the stability of NTP networks. Unlike the typical setup today, this
> included *fully meshed* networks of nodes *peering* with each other,
> with ample potential of feedback loops through several of them leading
> to oscillation.

Certainly if A relies on B and B relies on A, then loops can form, and
one must be careful. But that is not the dominant setup today. Thus if
ntpd had a fudge which allowed say 5000 ppm with that being setable to
500PPM or 100ppm in very very special circumstances, I cannot see how
this would harm anything.  But in the same situation, the stepping of
the clocks in current ntpd could also lead to instability. 


>
> (Disclaimer: I never found it necessary to verify, or even read, the
> math myself.)
>
>> I remember that in the past sometimes a specific adjtime command was
>> used to pre-configure a static error so that ntpd would not see it.
>> No idea if this still works.
>
> At least on the (Linux) systems where I found it necessary to use it to
> counter a bad clock, changing the tick value has worked so far. (Bar one
> stone-age busybox-based server where the devel environment had been lost
> in time and nobody could compile tickadj or any other tool that'ld allow
> me to touch tick in the first place.)
>
> Note that the default value of tick on Linux boxen is 1, so changing
> this integer value by one theoretically effects a 100 PPM shift. (For
> whatever reasons, my practical experience is more like 120 to 150 PPM
> ...) There's your valid reason why raising the NTP limit from 100 to 500
> made more sense than raising it further to 5000 or whatever.

Well, actually, Mills was heavily involved I believe in setting up the
kernel sortware to driving the clocks. Ie, I believe it was he that
helped determine the "tickadjust" and drift adjust mechanism, and the
500PPM limit of the latter. Yes, the tickadjust fascility is a coarse
adjust so needs only to be a bit finer thyan the limits of the drift
adjust ( which is 500PPM-- surpise).

>
> However, I've also seen hardware occasionally flip-flopping from -900 to
> +1100 and back, complete with the developers of the firmware blaming "a
> bug in ntpd" for failure to discipline *that*. Would I want ntpd to
> cater for such cases? Heck, no. It would *never* be able to keep *that*
> clock in sync to the quality standards of proper NTP servers, and
> "standard tools *refuse* this pile of clockwork rejects" provides the
> push to the only *proper* solution, namely, to fix the hardware.

I agree. If that is how the hardware behaves, then there is nothing any
clock discipline software could do, especially ntpd which is not
particularly agile in correcting anything (and was not designed to be). 

>
> Regards,
>   J. Bern

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

Jochen Bern  wrote:
> However, I've also seen hardware occasionally flip-flopping from -900 to
> +1100 and back, complete with the developers of the firmware blaming "a
> bug in ntpd" for failure to discipline *that*.

Ok that is different, it is not a static drift.

But I see it has also been explained elsewhere in the thread: ntpd has
a maximum on the momentary drift of 500ppm, no matter if it is static
or dynamic or the sum of two.  I think that is not warranted.

There are also other problems with dealing with a variable drift.
I know from observations that ntpd does not attempt to handle a
changing drift, it only tries to lock in to the momentary drift and
when that is changing, it keeps chasing the drift (resulting in an offset).

In practice a changing drift is often caused by changing temperature,
and it would be better to take the first derivative into account as well.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Jochen Bern]

On 02/11/2015 10:01 AM, Rob wrote:
> Terje Mathisen  wrote:
>> The 500 ppm limit is not at all arbitrary!
>>
>> In fact, it was originally just 100 ppm, but when too many systems 
>> turned up with a system clock which was a bit too far out, Prof Mills 
>> redid the control loop to allow a 500 ppm range.
>>
>> It could have been a lot more, but the ultimate stability of the control 
>> loop is supposed to be better this way.
> 
> I think it is hogwash.  The static drift cannot have any influence
> on the stability of the control loop.  A static drift is just a frequency
> error that is determined once and can then be forgotten about.

The limit is said to be required in the original mathematical proof of
the stability of NTP networks. Unlike the typical setup today, this
included *fully meshed* networks of nodes *peering* with each other,
with ample potential of feedback loops through several of them leading
to oscillation.

(Disclaimer: I never found it necessary to verify, or even read, the
math myself.)

> I remember that in the past sometimes a specific adjtime command was
> used to pre-configure a static error so that ntpd would not see it.
> No idea if this still works.

At least on the (Linux) systems where I found it necessary to use it to
counter a bad clock, changing the tick value has worked so far. (Bar one
stone-age busybox-based server where the devel environment had been lost
in time and nobody could compile tickadj or any other tool that'ld allow
me to touch tick in the first place.)

Note that the default value of tick on Linux boxen is 1, so changing
this integer value by one theoretically effects a 100 PPM shift. (For
whatever reasons, my practical experience is more like 120 to 150 PPM
...) There's your valid reason why raising the NTP limit from 100 to 500
made more sense than raising it further to 5000 or whatever.

However, I've also seen hardware occasionally flip-flopping from -900 to
+1100 and back, complete with the developers of the firmware blaming "a
bug in ntpd" for failure to discipline *that*. Would I want ntpd to
cater for such cases? Heck, no. It would *never* be able to keep *that*
clock in sync to the quality standards of proper NTP servers, and
"standard tools *refuse* this pile of clockwork rejects" provides the
push to the only *proper* solution, namely, to fix the hardware.

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Paul]

On Wed, Feb 11, 2015 at 8:22 AM, brian utterback  wrote:

> But no one who does actively engage really understands
> it or knows how to improve it. Unruh has a point, we don't know if there
> isn't a better way built on statistical analysis.
>
>
Since it seems the NTF "proposal" is to replace rather than repair
shouldn't this line of discussion be directed toward the new  software?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Terje Mathisen]

William Unruh wrote:

On 2015-02-11, Harlan Stenn  wrote:

William Unruh writes:

On 2015-02-10, Terje Mathisen  wrote:
And as far as I can see, 500 or 5000 makes little
difference to the control loop. Yes, it is harder for other systems to
follow one with a large drift, but it is even harder to follow one that
jumps, which is what we get now.


So what's the difference between following a jump and following a
system that applies changes faster than the 500ppm that NTP is designed
for?

And given that reality bites, what are the tradeoffs between re-synching
after a step and slowly dealing with a know offset error?

We're talking about choices, and the different effects of these choices.

It's one thing if a system rarely steps.  It's a bit different if those
steps happen more frequently.


Yes. And it is either equally rare that the system will go over 500PPM,
but sometimes a computer can have a large "natural" drift, (even over
500PPM) and that will drastically reduce the "headroom" to deal with
unusual situations. (ie, if the computers normal drift is 400PPM, that
means that the effective cap is only 100PPM, not 500).
stepping is much worse than high PPM since it is infinite PPM.

Note that were ntpd designed for 5000 PPM then anything else could
follow it since it could also do 5000 PPM.

Yes, we are talking about choices. And all I was saying was that this
particular choice was somewhat arbitrary.


What you seem to disregard is the need for client computers to track a 
server when that server (or some other up-stream source) is slewing at a 
larger than 500 ppm rate. (Alternatively, when something happens on the 
client computer to cause the local clock to start drifting away at high 
rates.)


Let's take your 5000 ppm as a starting point: Independent of the polling 
interval it will take multiple polls to realize that the server has 
started to slew, right?


At 5000 ppm we are adjusting by 5 ms every second, which corresponds to 
over 5 seconds over a single polling period, i.e. far more than the 128 
ms maximum threshold.


In fact, even a 500 ppm frequency delta means 512 ms over that single 
poll, so you cannot track any fast changes in frequency if your clock 
has currently stabilized at 1024 s polls.


With the default minimum poll of 64 sec however, 500 ppm results in just 
32 ms of offset, which means that you have 4 full polling periods to 
realize that you have to adjust the local clock and thereby avoid the 
128 ms limit.


It should by now be obvious that the numbers 64 sec, 500 ppm, half of 
the last 8 samples and 128 ms are all very closely related!


Yes, it is possible to slew much faster, but only if you start gradually 
enough that all clients will realize that the dispersion is increasing 
and that they must reduce the polling interval, and only if you spend at 
least 4 polling periods for each 500ppm of frequency adjustment you want 
to apply.


Terje
--
- 
"almost all programming can be viewed as an exercise in caching"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[brian utterback]

On 2/11/2015 2:12 AM, Harlan Stenn wrote:
> William Unruh writes:
>> > On 2015-02-10, Terje Mathisen  wrote:
>>> > > William Unruh wrote:
 > >> No. It only does that for "offsets from Hades". The Ones from Hell, 
 > >> ntpd
 > >> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
 > >>   >1000 sec)
 > >> Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- 
 > >> as
 > >> far as I can see a completely arbitrary limit Mills decided on decades
>>> > >
>>> > > The 500 ppm limit is not at all arbitrary!
>>> > >
>>> > > In fact, it was originally just 100 ppm, but when too many systems 
>>> > > turned up with a system clock which was a bit too far out, Prof Mills 
>>> > > redid the control loop to allow a 500 ppm range.
>>> > >
>>> > > It could have been a lot more, but the ultimate stability of the 
>>> > > control 
>>> > > loop is supposed to be better this way.
>>> > >
>>> > > My own control theory math was back around 1980, so I have forgotten 
>>> > > most of it. :-(
>>> > >
>> > 
>> > As you state, it is arbitrary.
> Is not! Is so! ...
>
>> > If it can be changed from 100 to 500
>> > after complaints, it indicates that the number was not picked to
>> > optimise anything.
> I'm not sure that logically follows...
>

Well, it indicates that it can be changed, not how easy it is nor what
it entails nor the consequences. As I recall, the choice of PPM limit
directly affects the maximum error budget. In Mills book he explains
that the control loop is carefully crafted to simplify the calculations
and to be provably correct and stable. With today's systems I am not
sure simplifying implementation at the expense of clarity is necessary
and provably correct is a goal that most of us worry about.

Dr. Mills crafted a wonderful piece of software, amazing for its time,
but he no longer actively engages us much at all. I understand, that
isn't his fault. But no one who does actively engage really understands
it or knows how to improve it. Unruh has a point, we don't know if there
isn't a better way built on statistical analysis. Perhaps a hybrid
between the two approaches would be better still. But we don't even know
the consequences of changing a single constant with any degree of
certainty.

-- 
Brian Utterback
Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterb...@oracle.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

William Unruh writes:
> On 2015-02-11, Harlan Stenn  wrote:
> > It's one thing if a system rarely steps.  It's a bit different if those
> > steps happen more frequently.
> 
> Yes. And it is either equally rare that the system will go over 500PPM,
> but sometimes a computer can have a large "natural" drift, (even over
> 500PPM) and that will drastically reduce the "headroom" to deal with
> unusual situations. (ie, if the computers normal drift is 400PPM, that
> means that the effective cap is only 100PPM, not 500). 
> stepping is much worse than high PPM since it is infinite PPM. 

Where would you get the idea that a 400ppm swing would be "normal"?
Or even 200PPM?

> Note that were ntpd designed for 5000 PPM then anything else could
> follow it since it could also do 5000 PPM. 

Sure, and if it was designed for 10S/S it would handle 10S/S swings.  But
none of this has been shown to be normal or useful.

> Yes, we are talking about choices. And all I was saying was that this
> particular choice was somewhat arbitrary. 

That depends on your definition of "somewhat".

More or less, "everything tastes like chicken".  More or less...

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

Terje Mathisen  wrote:
> The 500 ppm limit is not at all arbitrary!
>
> In fact, it was originally just 100 ppm, but when too many systems 
> turned up with a system clock which was a bit too far out, Prof Mills 
> redid the control loop to allow a 500 ppm range.
>
> It could have been a lot more, but the ultimate stability of the control 
> loop is supposed to be better this way.

I think it is hogwash.  The static drift cannot have any influence
on the stability of the control loop.  A static drift is just a frequency
error that is determined once and can then be forgotten about.

What is important is the short-time changes in the drift, the unstability
of the frequency.  THAT can influence the control loopt.  But that is not
at all what NTP restricts.

I can fully understand that ntpd cannot control a clock that is -500ppm
now and +500ppm the next hour, but it should not have any problem
controlling a clock that has a +5000ppm error that stays the same all
the time.  In fact, it is mostly the job of the kernel to do that.

I remember that in the past sometimes a specific adjtime command was
used to pre-configure a static error so that ntpd would not see it.
No idea if this still works.

Note that that "carefully designed control loop" does not even handle
the derivative of the drift.  When everything is stable the offset neatly
wobbles around zero, but when there is a linear change in temperature that
results in a linear change in drift, the control loop maintains a constant
error (determined by the gain of the loop), it does not realize that it
is handling a changing drift and pre-compensate for it.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-11, Harlan Stenn  wrote:
> William Unruh writes:
>> On 2015-02-10, Terje Mathisen  wrote:
>> > William Unruh wrote:
>> >> No. It only does that for "offsets from Hades". The Ones from Hell, ntpd
>> >> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
>> >>   >1000 sec)
>> >> Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- as
>> >> far as I can see a completely arbitrary limit Mills decided on decades
>> >
>> > The 500 ppm limit is not at all arbitrary!
>> >
>> > In fact, it was originally just 100 ppm, but when too many systems 
>> > turned up with a system clock which was a bit too far out, Prof Mills 
>> > redid the control loop to allow a 500 ppm range.
>> >
>> > It could have been a lot more, but the ultimate stability of the control 
>> > loop is supposed to be better this way.
>> >
>> > My own control theory math was back around 1980, so I have forgotten 
>> > most of it. :-(
>> >
>> 
>> As you state, it is arbitrary.
>
> Is not! Is so! ...
>
>> If it can be changed from 100 to 500
>> after complaints, it indicates that the number was not picked to
>> optimise anything.
>
> I'm not sure that logically follows...
>
>> And as far as I can see, 500 or 5000 makes little
>> difference to the control loop. Yes, it is harder for other systems to
>> follow one with a large drift, but it is even harder to follow one that
>> jumps, which is what we get now. 
>
> So what's the difference between following a jump and following a
> system that applies changes faster than the 500ppm that NTP is designed
> for?
>
> And given that reality bites, what are the tradeoffs between re-synching
> after a step and slowly dealing with a know offset error?
>
> We're talking about choices, and the different effects of these choices.
>
> It's one thing if a system rarely steps.  It's a bit different if those
> steps happen more frequently.

Yes. And it is either equally rare that the system will go over 500PPM,
but sometimes a computer can have a large "natural" drift, (even over
500PPM) and that will drastically reduce the "headroom" to deal with
unusual situations. (ie, if the computers normal drift is 400PPM, that
means that the effective cap is only 100PPM, not 500). 
stepping is much worse than high PPM since it is infinite PPM. 

Note that were ntpd designed for 5000 PPM then anything else could
follow it since it could also do 5000 PPM. 

Yes, we are talking about choices. And all I was saying was that this
particular choice was somewhat arbitrary. 

>
> H

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Harlan Stenn]

William Unruh writes:
> On 2015-02-10, Terje Mathisen  wrote:
> > William Unruh wrote:
> >> No. It only does that for "offsets from Hades". The Ones from Hell, ntpd
> >> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
> >>   >1000 sec)
> >> Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- as
> >> far as I can see a completely arbitrary limit Mills decided on decades
> >
> > The 500 ppm limit is not at all arbitrary!
> >
> > In fact, it was originally just 100 ppm, but when too many systems 
> > turned up with a system clock which was a bit too far out, Prof Mills 
> > redid the control loop to allow a 500 ppm range.
> >
> > It could have been a lot more, but the ultimate stability of the control 
> > loop is supposed to be better this way.
> >
> > My own control theory math was back around 1980, so I have forgotten 
> > most of it. :-(
> >
> 
> As you state, it is arbitrary.

Is not! Is so! ...

> If it can be changed from 100 to 500
> after complaints, it indicates that the number was not picked to
> optimise anything.

I'm not sure that logically follows...

> And as far as I can see, 500 or 5000 makes little
> difference to the control loop. Yes, it is harder for other systems to
> follow one with a large drift, but it is even harder to follow one that
> jumps, which is what we get now. 

So what's the difference between following a jump and following a
system that applies changes faster than the 500ppm that NTP is designed
for?

And given that reality bites, what are the tradeoffs between re-synching
after a step and slowly dealing with a know offset error?

We're talking about choices, and the different effects of these choices.

It's one thing if a system rarely steps.  It's a bit different if those
steps happen more frequently.

H
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-10, Brian Inglis  wrote:
> On 2015-02-10 13:26, William Unruh wrote:
>> However if this is the first time this running of ntpd has encountered
>> this, eg at startup, if you use -x option it will jump the time even if the
>-g (panicGate)

Oops, you are perfectly correct. -x changes the threshold of how long it
waits with an offset greater than 128ms befor jumping. 


>> offset is >1000 sec.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-10, Terje Mathisen  wrote:
> William Unruh wrote:
>> On 2015-02-10, Jochen Bern  wrote:
>>> On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
 However, when I wait for several minutes, the time can be adjusted to
 the right time. I couldn't see the gradual changes of offset. Is that
 normal?
>>>
>>> Assuming that you're using a minimalistic configuration: Yes.
>>>
>>> ntpd would take almost three months to *gradually* eliminate (slew) one
>>> hour of offset, so as soon as the
>>> offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
>>> gave up all hope for the universe and "just set the clock" hard (step).
>>
>> No. It only does that for "offsets from Hades". The Ones from Hell, ntpd
>> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
>>   >1000 sec)
>> Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- as
>> far as I can see a completely arbitrary limit Mills decided on decades
>
> The 500 ppm limit is not at all arbitrary!
>
> In fact, it was originally just 100 ppm, but when too many systems 
> turned up with a system clock which was a bit too far out, Prof Mills 
> redid the control loop to allow a 500 ppm range.
>
> It could have been a lot more, but the ultimate stability of the control 
> loop is supposed to be better this way.
>
> My own control theory math was back around 1980, so I have forgotten 
> most of it. :-(
>

As you state, it is arbitrary. If it can be changed from 100 to 500
after complaints, it indicates that the number was not picked to
optimise anything. And as far as I can see, 500 or 5000 makes little
difference to the control loop. Yes, it is harder for other systems to
follow one with a large drift, but it is even harder to follow one that
jumps, which is what we get now. 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Terje Mathisen]

William Unruh wrote:

On 2015-02-10, Jochen Bern  wrote:

On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:

However, when I wait for several minutes, the time can be adjusted to
the right time. I couldn't see the gradual changes of offset. Is that
normal?


Assuming that you're using a minimalistic configuration: Yes.

ntpd would take almost three months to *gradually* eliminate (slew) one
hour of offset, so as soon as the
offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
gave up all hope for the universe and "just set the clock" hard (step).


No. It only does that for "offsets from Hades". The Ones from Hell, ntpd
abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
  >1000 sec)
Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- as
far as I can see a completely arbitrary limit Mills decided on decades


The 500 ppm limit is not at all arbitrary!

In fact, it was originally just 100 ppm, but when too many systems 
turned up with a system clock which was a bit too far out, Prof Mills 
redid the control loop to allow a 500 ppm range.


It could have been a lot more, but the ultimate stability of the control 
loop is supposed to be better this way.


My own control theory math was back around 1980, so I have forgotten 
most of it. :-(


Terje


ago). If >128ms but <1000s it will, after being sure that that is not
just some measurement error, jump the time (ie infinite PPM) If >1000 it
assumes something is very very very badly wrong, and aborts.

However if this is the first time this running of ntpd has encountered
this, eg at startup, if you use -x option it will jump the time even if the
offset is >1000 sec.




Regards,
J. Bern



--
- 
"almost all programming can be viewed as an exercise in caching"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Brian Inglis]

On 2015-02-10 13:26, William Unruh wrote:

However if this is the first time this running of ntpd has encountered
this, eg at startup, if you use -x option it will jump the time even if the

  -g (panicGate)

offset is >1000 sec.

--
Take care. Thanks, Brian Inglis
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[William Unruh]

On 2015-02-10, Jochen Bern  wrote:
> On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
>> However, when I wait for several minutes, the time can be adjusted to
>> the right time. I couldn't see the gradual changes of offset. Is that
>> normal?
>
> Assuming that you're using a minimalistic configuration: Yes.
>
> ntpd would take almost three months to *gradually* eliminate (slew) one
> hour of offset, so as soon as the
> offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
> gave up all hope for the universe and "just set the clock" hard (step).

No. It only does that for "offsets from Hades". The Ones from Hell, ntpd
abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
 >1000 sec)
Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- as
far as I can see a completely arbitrary limit Mills decided on decades
ago). If >128ms but <1000s it will, after being sure that that is not
just some measurement error, jump the time (ie infinite PPM) If >1000 it
assumes something is very very very badly wrong, and aborts.

However if this is the first time this running of ntpd has encountered
this, eg at startup, if you use -x option it will jump the time even if the
offset is >1000 sec. 


>
> Regards,
>   J. Bern

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Jochen Bern]

On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
> However, when I wait for several minutes, the time can be adjusted to
> the right time. I couldn't see the gradual changes of offset. Is that
> normal?

Assuming that you're using a minimalistic configuration: Yes.

ntpd would take almost three months to *gradually* eliminate (slew) one
hour of offset, so as soon as the
offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
gave up all hope for the universe and "just set the clock" hard (step).

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[David Woolley]

On 10/02/15 05:15, catherine.wei1...@gmail.com wrote:

Hi, I'm using the ntpd to sync time. When I change the current date for exampe to 
0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10 03:02, then I run 
"ntpq -p" for several times, the offset doesn't change at all.


Garbage In Garbage Out.

ntpd is intended in environments where time behaves like time.  It 
should actually abort in the case you describe, as something has clearly 
broken so badly that it is no longer safer to try and discipline the clock.


People often try this as a test, but it is not a valid test.

Basically, up to a lower limit (default 128ms, but significantly 
increased by -x) ntpd will slew to correct.  Above that limit, up to a 
second limit (which I seem to remember to be 10 minutes) it will wait 
about 15 minutes to confirm that it really is seeing a step change, then 
restart the initial synchronisation and step.  Above the second limits, 
it should abort, except if you enable an option to allow one such step 
and it is the first one.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[Rob]

catherine.wei1...@gmail.com  wrote:
> Hi, I'm using the ntpd to sync time. When I change the current date for 
> exampe to 0210020215 (2015-02-10 02:02), the actually current time is 
> 2015-02-10 03:02, then I run "ntpq -p" for several times, the offset doesn't 
> change at all.

ntpd is not designed to handle deliberate tampering with the local time.

Apparently many companies write acceptance test scenarios like "setup
ntp, then put a different time in the clock and see how ntp corrects it"
but this just isn't going to work.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP offset doesn't change.

[catherine . wei1989]

By the way, the ntp version I'm using is 4.2.8p1.
Catherine.

On Tuesday, February 10, 2015 at 1:15:21 PM UTC+8, catherin...@gmail.com wrote:
> Hi, I'm using the ntpd to sync time. When I change the current date for 
> exampe to 0210020215 (2015-02-10 02:02), the actually current time is 
> 2015-02-10 03:02, then I run "ntpq -p" for several times, the offset doesn't 
> change at all.
>  ~ # ntpq -p
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *zse18adnss1.ea. 10.6.151.123 2 u58  377  280.663  2520785  16.037
> 
> ~ # ntpq -p
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *ns3.swelin.arri 10.6.151.123 2 u38  377  280.774  2520785  16.089
> 
> However, when I wait for several minutes, the time can be adjusted to the 
> right time. I couldn't see the gradual changes of offset. Is that normal?
> 
> Appreciate your help, thank you.
> Catherine.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions