BG wrote:

> What is the limitation on the time difference of a client clock at ntp
> startup? Is it 1000 sec? Is there an option to increase this or a
> 'commercial' version of NTP that will allow greater differences? e.g.
> years
>
> I have a local network set up with a GPS connected to one pc acting as
> a ntp server. The GPS synchronizes the system clock of this pc. NTP
> distributes the time to another pc on the network. It appears that I
> can not change the client pc time/date more than 1000 sec or ntp will
> not correct the client clock.
>
> thank you
>

Then don't change the time on the client!!! This is a non-issue in a
properly configure NTP network.

The limit is 1024 seconds and I doubt that anyone is willing to change
it. You can start ntpd on the client with the -g option and it will set
the client's clock on a one time basis. Thereafter, ntpd should be able
to keep it synchronized. If not, there is something very wrong with,
most probably, the client or (barely possible) the server.

When ntpd is synchronizing the client, no one should be trying to change
the client's clock!!!

Thank you. The reason I need to change the client clock is to 'prove'
to skeptics that it is working.

B Gillcrist


Richard B. Gilbert wrote:
> BG wrote:
>
> > What is the limitation on the time difference of a client clock at ntp
> > startup? Is it 1000 sec? Is there an option to increase this or a
> > 'commercial' version of NTP that will allow greater differences? e.g.
> > years
> >
> > I have a local network set up with a GPS connected to one pc acting as
> > a ntp server. The GPS synchronizes the system clock of this pc. NTP
> > distributes the time to another pc on the network. It appears that I
> > can not change the client pc time/date more than 1000 sec or ntp will
> > not correct the client clock.
> >
> > thank you
> >
>
> Then don't change the time on the client!!! This is a non-issue in a
> properly configure NTP network.
>
> The limit is 1024 seconds and I doubt that anyone is willing to change
> it. You can start ntpd on the client with the -g option and it will set
> the client's clock on a one time basis. Thereafter, ntpd should be able
> to keep it synchronized. If not, there is something very wrong with,
> most probably, the client or (barely possible) the server.
>
> When ntpd is synchronizing the client, no one should be trying to change
> the client's clock!!!

I can get ntp to run by typing in ntpd -n -g in a console window but
for this application I don't want to keep a console window visible. Is
there a way to automatically start ntp with the options and you see the
service running in the services window?


Richard B. Gilbert wrote:
> BG wrote:
>
> > What is the limitation on the time difference of a client clock at ntp
> > startup? Is it 1000 sec? Is there an option to increase this or a
> > 'commercial' version of NTP that will allow greater differences? e.g.
> > years
> >
> > I have a local network set up with a GPS connected to one pc acting as
> > a ntp server. The GPS synchronizes the system clock of this pc. NTP
> > distributes the time to another pc on the network. It appears that I
> > can not change the client pc time/date more than 1000 sec or ntp will
> > not correct the client clock.
> >
> > thank you
> >
>
> Then don't change the time on the client!!! This is a non-issue in a
> properly configure NTP network.
>
> The limit is 1024 seconds and I doubt that anyone is willing to change
> it. You can start ntpd on the client with the -g option and it will set
> the client's clock on a one time basis. Thereafter, ntpd should be able
> to keep it synchronized. If not, there is something very wrong with,
> most probably, the client or (barely possible) the server.
>
> When ntpd is synchronizing the client, no one should be trying to change
> the client's clock!!!

BG wrote:
> I can get ntp to run by typing in ntpd -n -g in a console window but
> for this application I don't want to keep a console window visible. Is
> there a way to automatically start ntp with the options and you see the
> service running in the services window?
>

In just about any environment but Windoze, it's not difficult. System
startup runs a script that starts ntpd with options. You could try
autoexec.bat but I have serious doubts that it would work as you hope.
It would start ntpd with command line options but probably far too early
for the TCP/IP stack to be up and running. So ntpd fails to resolve the
IP addresses of the servers or something.

I don't use ntpd on Windoze; w32time keeps the clock close enough for
govenment work.

BG wrote:
> I can get ntp to run by typing in ntpd -n -g in a console window but
> for this application I don't want to keep a console window visible. Is
> there a way to automatically start ntp with the options and you see the
> service running in the services window?
>

Assuming you are talking about windows, yes. You didn't say what version
you are using. The newer versions, such as 4.2.2, support this in the
imagepath for the service just by adding the command line options.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

BG wrote:
> I can get ntp to run by typing in ntpd -n -g in a console window but
> for this application I don't want to keep a console window visible. Is
> there a way to automatically start ntp with the options and you see the
> service running in the services window?
>


Our current Windows NTP installer (free) is capable of using the "-g"
option (the corresponding installer checkbox is labelled "allow big
initial timesteps"). But -g works only once, at startup. If you want to
show that you can change the time to 2003 and it is corrected
automagically, this won't work (ntp will exit and you have to restart it
yourself, losing all that "automagic" ...).

If you combine it with our free NTP Time Monitor - which can be set up
to automatically restart NTP in case it dies - your problem would be solved.

For your presentation I would use ntpdate and let it run once a minute
using the task scheduler of Windows ... :-)

Best regards,
Heiko



>
> Richard B. Gilbert wrote:
>> BG wrote:
>>
>>> What is the limitation on the time difference of a client clock at ntp
>>> startup? Is it 1000 sec? Is there an option to increase this or a
>>> 'commercial' version of NTP that will allow greater differences? e.g.
>>> years
>>>
>>> I have a local network set up with a GPS connected to one pc acting as
>>> a ntp server. The GPS synchronizes the system clock of this pc. NTP
>>> distributes the time to another pc on the network. It appears that I
>>> can not change the client pc time/date more than 1000 sec or ntp will
>>> not correct the client clock.
>>>
>>> thank you
>>>
>> Then don't change the time on the client!!! This is a non-issue in a
>> properly configure NTP network.
>>
>> The limit is 1024 seconds and I doubt that anyone is willing to change
>> it. You can start ntpd on the client with the -g option and it will set
>> the client's clock on a one time basis. Thereafter, ntpd should be able
>> to keep it synchronized. If not, there is something very wrong with,
>> most probably, the client or (barely possible) the server.
>>
>> When ntpd is synchronizing the client, no one should be trying to change
>> the client's clock!!!
>

In article <1156282058.994857.239810@p79g2000cwp.googlegroups. com>,
"BG" wrote:

> Thank you. The reason I need to change the client clock is to 'prove'
> to skeptics that it is working.

But it doesn't prove that it is working. All it demonstrates is
an error recovery path, working at a precision that could be achieved
using very crude time synchronisation protocols, is working. If you
really want to demonstrate that ntpd is working, you would need to do
something like heating or cooling the crystal oscillator on the
motherboard (assuming you are in an air conditioned room and can't
do this for the whole machine) and demonstrate that the frequency error
is compensated correctly.

In reality, ntpd has no need to be able to handle errors of more than
about 30 seconds, as that is about the maximum error in a watch used to
set the initial time.

> BG wrote:
>
> > What is the limitation on the time difference of a client clock at ntp
> > startup? Is it 1000 sec? Is there an option to increase this or a

It's unlimited if you use the -g option, but only for the first
correction.

> > 'commercial' version of NTP that will allow greater differences? e.g.
> > years

The reference version is much easier to change in this respect than any
commercial version, as you can just change the limit constant in the
source code. You don't even need to change the source code, as there is
a tinker option documented that allows you to change or disable this
check.

However, make sure that you change it back after the admirals
have left.

> > distributes the time to another pc on the network. It appears that I
> > can not change the client pc time/date more than 1000 sec or ntp will
> > not correct the client clock.

This is not startup, though.

David,

Classic way to test NTP functionality is to stop ntpd, set the time by
some other means within 68 years of the correct time, then start ntpd
with -g.

Dave

David Woolley wrote:
> In article <1156282058.994857.239810@p79g2000cwp.googlegroups. com>,
> "BG" wrote:
>
>
>>Thank you. The reason I need to change the client clock is to 'prove'
>>to skeptics that it is working.
>
>
> But it doesn't prove that it is working. All it demonstrates is
> an error recovery path, working at a precision that could be achieved
> using very crude time synchronisation protocols, is working. If you
> really want to demonstrate that ntpd is working, you would need to do
> something like heating or cooling the crystal oscillator on the
> motherboard (assuming you are in an air conditioned room and can't
> do this for the whole machine) and demonstrate that the frequency error
> is compensated correctly.
>
> In reality, ntpd has no need to be able to handle errors of more than
> about 30 seconds, as that is about the maximum error in a watch used to
> set the initial time.
>
>
>>BG wrote:
>>
>>
>>>What is the limitation on the time difference of a client clock at ntp
>>>startup? Is it 1000 sec? Is there an option to increase this or a
>
>
> It's unlimited if you use the -g option, but only for the first
> correction.
>
>
>>>'commercial' version of NTP that will allow greater differences? e.g.
>>>years
>
>
> The reference version is much easier to change in this respect than any
> commercial version, as you can just change the limit constant in the
> source code. You don't even need to change the source code, as there is
> a tinker option documented that allows you to change or disable this
> check.
>
> However, make sure that you change it back after the admirals
> have left.
>
>
>>>distributes the time to another pc on the network. It appears that I
>>>can not change the client pc time/date more than 1000 sec or ntp will
>>>not correct the client clock.
>
>
> This is not startup, though.

In article ,
David L. Mills wrote:

> Classic way to test NTP functionality is to stop ntpd, set the time by

This isn't a classic way because it hasn't been an available option for
long enough. It's also not classic because it is not what people actually
do; what they actually do is to change the time on a running client (or,
if they are using an undisciplined local clock on the server, change the
time on a running server).

As I pointed out, it is also not a valid test because it fails to demonstrate
the phase locked loop in ntpd, which is the main part of ntpd, except in as
much that someone more knowldedgeable than the sort of person for which this
sort of demonstration is done, may be able to see the final convergence onto
the correct time and frequency.

If you really think it is a good test, I'm surprised that you have let so
many regulars here criticise people for doing these step change tests in the
past.

> some other means within 68 years of the correct time, then start ntpd
> with -g.

In article david@djwhome.demon.co.uk
(David Woolley) writes:
>In article ,
>David L. Mills wrote:
>
>> Classic way to test NTP functionality is to stop ntpd, set the time by
>
>This isn't a classic way because it hasn't been an available option for
>long enough.

The option of stopping ntpd?:-) If you mean -g, I think it has been
around since xntpd/v3 days, though possibly with slightly different
semantics back then (I'm not sure if it was limited to *one* step).
Note, I'm not saying it was *documented*.:-)

--Per Hedeland
per@hedeland.org

David,

I have no idea whatsoever what you are talking about. If you need to
test whether the clock state machine correctly responds to large time
offsets, then my suggested scheme is exactly what you need. I have
tested every NTP version since 1982 in just that way, most recently to
confirm the clock is set correctly after the 2036 roll.

Using a large time step offset is not the way to test the PLL/FLL
functionality, and I did not intend the "classic" scheme to test it thar
way. The PLL/FLL loop is pseudo-linear and needs to be perturbed by a
small offset less than the step threshold (128 ms). Either that or
change the step threshold to something large and set the offset manually.

I test by setting the frequency to something large, like 500 PPM and
running the daemon (or kernel) for a few minutes in order to accumulate
a modest error, like 100 ms. Then, restore the original frequency file
or delete it, as required and restart the daemon. The intent is to
confirm the zero crossing as the loop converges (about one hour) and to
confirm the overshoot is modest (less than 6 percent). All this with a
64-s poll interval.

Your last comment is confusing. I have never criticized folks for doing
tests involving step or linear adjustments. What I have done is question
the wisdom of forcing the step threshold to very large values in order
to insure monotonic adjustments. The reasons for this are explained in
the white papers at the NTP project site.

Dave

David Woolley wrote:
> In article ,
> David L. Mills wrote:
>
>
>>Classic way to test NTP functionality is to stop ntpd, set the time by
>
>
> This isn't a classic way because it hasn't been an available option for
> long enough. It's also not classic because it is not what people actually
> do; what they actually do is to change the time on a running client (or,
> if they are using an undisciplined local clock on the server, change the
> time on a running server).
>
> As I pointed out, it is also not a valid test because it fails to demonstrate
> the phase locked loop in ntpd, which is the main part of ntpd, except in as
> much that someone more knowldedgeable than the sort of person for which this
> sort of demonstration is done, may be able to see the final convergence onto
> the correct time and frequency.
>
> If you really think it is a good test, I'm surprised that you have let so
> many regulars here criticise people for doing these step change tests in the
> past.
>
>
>>some other means within 68 years of the correct time, then start ntpd
>>with -g.

Per,

I may have to wash out my mouth with soap after telling you this.

The xntp daemon maintained two timescales, one for the daemon and the
other for the kernel. There could be a large discrepancy between these
timescales that was not revealed by the monitoring functions. Secondly,
late xntpd and and eraly ntpd used two independent loops, one for "slew"
mode and the other for "normal" modes. This was a mistake; the slew is
now incorporated in the normal model. The only difference is that slew
normally means simply increasing the step threshold; the loop functions
remain the same.

Note that some systems, including Solaris, have modified the adjtime()
syscall function to more quickly respond to large adjustments. This adds
an extra poll to the feedback loop response. Setting a large step
threshold can result in large overshoot and possible unstable behavior.

Dave

Per Hedeland wrote:

> In article david@djwhome.demon.co.uk
> (David Woolley) writes:
>
>>In article ,
>>David L. Mills wrote:
>>
>>
>>>Classic way to test NTP functionality is to stop ntpd, set the time by
>>
>>This isn't a classic way because it hasn't been an available option for
>>long enough.
>
>
> The option of stopping ntpd?:-) If you mean -g, I think it has been
> around since xntpd/v3 days, though possibly with slightly different
> semantics back then (I'm not sure if it was limited to *one* step).
> Note, I'm not saying it was *documented*.:-)
>
> --Per Hedeland
> per@hedeland.org

In article ,
"user@domain.invalid" (suspected to be Dave Mills) wrote:

> I have no idea whatsoever what you are talking about. If you need to

I have no idea which point you are responding to, as you have used
a pure top post.

> test whether the clock state machine correctly responds to large time
> offsets, then my suggested scheme is exactly what you need. I have

No. What people actually want to do is to create an acceptance test
plan that will be understood by someone who doesn't understand what ntpd
really does, and, quite possibly, to do so when they don't understand
it themselves.

This might be a formal acceptance test plan, or it might be an informal
one in which they demonstrate, to senior management, that ntpd can correct
time errors.

Testing the specific step response behaviour in these cases assumes a
much higher level of technical knowledge than the questions generally
exhibit.