Hi,
Scenario:
- I'm in control of a NTP server and can change the time on this
server as I please (this server is "sync'ed to the hw-clock)
- I have a client that is sync'ed with the server above (and only that
server)

What happens if I change the time on the server, lets say 5 years
forward? Will the client sync to the server? and If so, how? big leap?
small steps? Will the flag "-g" affect how the client reacts to this
changes?

Yes, I do realise that this scenario is stupid in many ways. Only one
server, big time changes on the server etc etc, and I do know how to
fix ti, but this is the scenario that I need an answer to.

Any input welcome!

BR,
Fredrik

Hi--

On Feb 9, 2012, at 1:36 PM, bombjack wrote:
> What happens if I change the time on the server, lets say 5 years
> forward? Will the client sync to the server? and If so, how? big leap?
> small steps? Will the flag "-g" affect how the client reacts to this
> changes?

Exactly.  If the server reports a time that is further than the panic threshold from the client's clock (which defaults to 1000 seconds) then it will reject the server and exit.  A human is then expected to manually inspect the situation and set the clock to something reasonably close.  The -g flag lets you disable this sanity check.

Regards,
-- 
-Chuck

On Feb 9, 2012, at 4:05 PM, Chris Albertson wrote:
>> Exactly.  If the server reports a time that is further than the panic threshold from the client's clock (which defaults to 1000 seconds) then it will reject the server and exit.  A human is then expected to manually inspect the situation and set the clock to something reasonably close.  The -g flag lets you disable this sanity check.
> 
> I think what you describe applies to the case where a client NTP
> starts up and notice the time is very far "off".    But I think (??)
> the question was that the client is in sync and then the server's time
> jumps.  I thought -g only applied to start up logic.  I could be
> wrong.   This situation would never happen on a properly configured
> network.

Ah, yes, my response was in the context of client starting up when there is a single server, and it is very far off from what the client believes is the current time.  From what I recall in earlier testing, if ntpd is running and synched, and the remote side does something crazy like a multi-year jump, then it is promptly marked and ignored as a falseticker.  I'm not sure that I've ever tried doing this with just a single server specified, though.

I think that -x specifies the max deviation allowed when doing a step via settimeofday() rather than slewing the clock with adjtime(), and it is limited to a max permissible jump of 600 seconds, except for possibly a one-time "big" jump at startup allowed by -g.

Regards,
-- 
-Chuck

On 2012-02-09, bombjack <bombjack99@gmail.com> wrote:

> - I'm in control of a NTP server and can change the time on this
> server as I please (this server is "sync'ed to the hw-clock)

ntpd never "syncs to the hardware clock".

If you use the Undisciplined Local Clock driver (127.127.1.x) ntpd will
accept the kernel clock's notion of time and will pretend that it is
synced to a real time source. However ntpd will follow the kernel clock
as it drifts.

-- 
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

On Fri, Feb 10, 2012 at 00:16, Chuck Swiger <cswiger@mac.com> wrote:
> On Feb 9, 2012, at 4:05 PM, Chris Albertson wrote:
>> I think what you describe applies to the case where a client NTP
>> starts up and notice the time is very far "off". =A0 =A0But I think (??)
>> the question was that the client is in sync and then the server's time
>> jumps. =A0I thought -g only applied to start up logic. =A0I could be
>> wrong. =A0 This situation would never happen on a properly configured
>> network.
>
> Ah, yes, my response was in the context of client starting up when
> there is a single server, and it is very far off from what the client
> believes is the current time. =A0From what I recall in earlier testing, if
> ntpd is running and synched, and the remote side does something
> crazy like a multi-year jump, then it is promptly marked and ignored
> as a falseticker. =A0I'm not sure that I've ever tried doing this with ju=
st
> a single server specified, though.

Close but no cigar -- -g allows a single step exceeding the panic
threshold, not necessarily at startup.  So if the client didn't need
to step more than the panic threshold at startup, a single subsequent
panic-exceeding step is allowed.  A second such incident would then
cause the client ntpd to exit.

> I think that -x specifies the max deviation allowed when doing a step
> via settimeofday() rather than slewing the clock with adjtime(), and it
> is limited to a max permissible jump of 600 seconds, except for
> possibly a one-time "big" jump at startup allowed by -g.

-x is equivalent to "tinker step 600", as explained in

http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html

This changes the step threshold from 0.128 to 600, and as noted in

http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#tinker

any step threshold greater than 0.500 disables the kernel clock
discipline loop (as does "disable kernel").

Let me RTFM that for you,
Dave Hart

On Feb 9, 2012, at 6:32 PM, Dave Hart wrote:
> Let me RTFM that for you,

If doing so makes you feel happier, by all means.

However, since there tends to be some divergence between what software actually does and what the documentation claims it does, experience gained from real-world testing would be more valuable than even the finest of manual reading.  

-- 
-Chuck

On 2/9/2012 4:36 PM, bombjack wrote:
> Hi,
> Scenario:
> - I'm in control of a NTP server and can change the time on this
> server as I please (this server is "sync'ed to the hw-clock)
> - I have a client that is sync'ed with the server above (and only that
> server)
>
> What happens if I change the time on the server, lets say 5 years
> forward? Will the client sync to the server? and If so, how? big leap?

Yes, BIG LEAP!  But WHAT PROBLEM are you trying to solve??????

It will take long time, perhaps as long as eight or ten hours to recover
from this exercise

> small steps? Will the flag "-g" affect how the client reacts to this
> changes?
>
> Yes, I do realise that this scenario is stupid in many ways. Only one
> server, big time changes on the server etc etc, and I do know how to
> fix ti, but this is the scenario that I need an answer to.
>
> Any input welcome!
>
> BR,
> Fredrik

bombjack wrote:
)
> 
> What happens if I change the time on the server, lets say 5 years
> forward? Will the client sync to the server? and If so, how? big leap?

You should get all access privileges to the server revoked!

Although people are saying what the reference implementation of NTP will 
do, in no way is NTP specified for use in an environment where this sort 
of thing can happen.

bombjack <bombjack99@gmail.com> wrote:
> Yes, I do realise that this scenario is stupid in many ways. Only one
> server, big time changes on the server etc etc, and I do know how to
> fix ti, but this is the scenario that I need an answer to.

Then setup your server and client and see for yourself what happens!!

It will not only depend on what software you use, but also on its exact
version number and its configuration.   So it is impossible to answer
your question without knowing those.

On 2012-02-09, bombjack <bombjack99@gmail.com> wrote:
> Hi,
> Scenario:
> - I'm in control of a NTP server and can change the time on this
> server as I please (this server is "sync'ed to the hw-clock)
> - I have a client that is sync'ed with the server above (and only that
> server)
>
> What happens if I change the time on the server, lets say 5 years
> forward? Will the client sync to the server? and If so, how? big leap?
> small steps? Will the flag "-g" affect how the client reacts to this
> changes?

No. If ntp finds the time out by >128ms, it steps the clock. If it finds
it out by 1000(?) sec it says "Something is horribly wrong here" and
abandons ship. (ntpd exits).


>
> Yes, I do realise that this scenario is stupid in many ways. Only one
> server, big time changes on the server etc etc, and I do know how to
> fix ti, but this is the scenario that I need an answer to.
>
> Any input welcome!
>
> BR,
> Fredrik

On Sat, Feb 11, 2012 at 01:03, unruh <unruh@invalid.ca> wrote:
> On 2012-02-09, bombjack <bombjack99@gmail.com> wrote:
>> What happens if I change the time on the server, lets say 5 years
>> forward? Will the client sync to the server? and If so, how? big leap?
>> small steps? Will the flag "-g" affect how the client reacts to this
>> changes?
>
> No. If ntp finds the time out by >128ms, it steps the clock. If it finds
> it out by 1000(?) sec it says "Something is horribly wrong here" and
> abandons ship. (ntpd exits).

Don't let facts get in the way of your recollections, I suppose.
Quoting myself from this very thread: "-g allows a single step
exceeding the panic threshold, not necessarily at startup."  The panic
threshold defaults to 1000 s.  But don't take my word for it -- see
the docs.

Cheers,
Dave Hart

On 2012-02-11, Dave Hart <hart@ntp.org> wrote:
> On Sat, Feb 11, 2012 at 01:03, unruh <unruh@invalid.ca> wrote:
>> On 2012-02-09, bombjack <bombjack99@gmail.com> wrote:
>>> What happens if I change the time on the server, lets say 5 years
>>> forward? Will the client sync to the server? and If so, how? big leap?
>>> small steps? Will the flag "-g" affect how the client reacts to this
>>> changes?
>>
>> No. If ntp finds the time out by >128ms, it steps the clock. If it finds
>> it out by 1000(?) sec it says "Something is horribly wrong here" and
>> abandons ship. (ntpd exits).
>
> Don't let facts get in the way of your recollections, I suppose.
> Quoting myself from this very thread: "-g allows a single step
> exceeding the panic threshold, not necessarily at startup."  The panic
> threshold defaults to 1000 s.  But don't take my word for it -- see
> the docs.

??? a) that -g is typically used at startup and was introduced in order
to handle wildly out of sync clocks at starup. I suspect that the fact
that -g will also works if startup has been OK, but 17 days into running
it suddenly finds the clock out by 5 days is a bug in the implimentation
of -g. 
And my recollection seems to have been dead on. 
>
> Cheers,
> Dave Hart

On Sat, Feb 11, 2012 at 19:02, unruh <unruh@invalid.ca> wrote:
> On 2012-02-11, Dave Hart <hart@ntp.org> wrote:
>> On Sat, Feb 11, 2012 at 01:03, unruh <unruh@invalid.ca> wrote:
>>> On 2012-02-09, bombjack <bombjack99@gmail.com> wrote:
>>>> What happens if I change the time on the server, lets say 5 years
>>>> forward? Will the client sync to the server? and If so, how? big leap?
>>>> small steps? Will the flag "-g" affect how the client reacts to this
>>>> changes?
>>>
>>> No. If ntp finds the time out by >128ms, it steps the clock. If it finds
>>> it out by 1000(?) sec it says "Something is horribly wrong here" and
>>> abandons ship. (ntpd exits).
>>
>> Don't let facts get in the way of your recollections, I suppose.
>> Quoting myself from this very thread: "-g allows a single step
>> exceeding the panic threshold, not necessarily at startup." =A0The panic
>> threshold defaults to 1000 s. =A0But don't take my word for it -- see
>> the docs.
>
> ???
> a) that -g is typically used at startup and was introduced in order
> to handle wildly out of sync clocks at starup. I suspect that the fact
> that -g will also works if startup has been OK, but 17 days into running
> it suddenly finds the clock out by 5 days is a bug in the implimentation
> of -g.

I discovered today while looking at another issue that the ntpd -g
explanation in ntpd.html and ntpd --help are both subtly wrong, and
have been since -g was introduced in the earliest ntpd 4.x releases.
As one might hope from a practical point of view, -g will not allow a
panic-exceeding step except the first sync.  The docs make no mention
of first sync or startup or anything similar.

> And my recollection seems to have been dead on.

Yes, indeed.  When I wrote the above, I assumed the docs correctly
described the code's behavior and didn't verify by testing or code
inspection.

Cheers,
Dave Hart