Hi all.



I have notice that ntpd does not step the time, if the clients clock is
within the +- 128 ms range.

If I use the options -qg, then ntpd set -or slew the time, and exist.



Is there some other options, which will force ntpd to set time first time,
and continue normal work afterwards - regardless of the 128ms range?.



My ntp-clients are only on the network for only short time (mainly to
synchronize time). The ntp server is setup in broadcast mode.

What I would like is that those clients are forced a time from ntp server
first time they see a ntp broadcast. The rest of time they are on network
they should do normal ntp clock discipline.

 It works fine, expect if they client are within the +-128 ms range to start
with, and then it takes time for ntp to "adjust the clock".



I have tried with the "tinker" options with "step" and "stepout" parameters
in ntp.conf, but truth is, I don't know what consequent this will have on
the time synchronization.



Thanks

Sarbjit Singh

Adrian 'Dagurashibanipal',



Well, you can say we are too sanity about the precision. That is correct. In
our product we like to achieve +- 1ms within short time.



The ntpdate program can't run when the ntpd is running on the clients since
the port is used by ntpd. I would then need to stop ntpd before running
ntpdate. This will give various support issues with different operating
systems, and versions.




"Adrian 'Dagurashibanipal' von Bidder" <varys@fortytwo.ch> wrote in message
news:1750205.XYWth8do2b@altfrangg.fortytwo.ch...
> Clinging to sanity, Sarbjit Singh mumbled in his beard:
>
> > Hi all.
> >
> >
> >
> > I have notice that ntpd does not step the time, if the clients clock is
> > within the +- 128 ms range.
> >
> > If I use the options -qg, then ntpd set -or slew the time, and exist.
> >
> >
> >
> > Is there some other options, which will force ntpd to set time first
time,
> > and continue normal work afterwards - regardless of the 128ms range?.
> >
> >
> >
> > My ntp-clients are only on the network for only short time (mainly to
> > synchronize time). [...]
>
> Seems to me a perfect application for ntpdate.
>
> -- vbi
>
>
> -- 
> sendmail: a nice OS, but lacks a decent MTA
>

Sarbjit wrote:
> The ntpdate program can't run when the ntpd is running on the clients since
> the port is used by ntpd. I would then need to stop ntpd before running
> ntpdate. This will give various support issues with different operating
> systems, and versions.

ntpdate -b

Please read at least the manual before causing unnecessary load for
thousands of people.

> "Adrian 'Dagurashibanipal' von Bidder" <varys@fortytwo.ch> wrote in message
> news:1750205.XYWth8do2b@altfrangg.fortytwo.ch...
[...]

Why do you include all this if you're not referring to it in detail?

Marc

-- 
  _ _    Marc A. Donges                      +49 721 6904-2130
  'v'    Klosterweg 28 / E110
 /   \   76131 Karlsruhe          PGP-Key(RSA): 1024R/429D9719
  W W                      http://www.hadiko.de/~marc/marc.asc

"Marc A. Donges" <filter.marc.usenet-200212@defiant.hadiko.de> wrote in
message news:slrnblt9v8.nbg.filter.marc.usenet-200212@defiant.hadiko.de...
> Sarbjit wrote:
> > The ntpdate program can't run when the ntpd is running on the clients
since
> > the port is used by ntpd. I would then need to stop ntpd before running
> > ntpdate. This will give various support issues with different operating
> > systems, and versions.
>
> ntpdate -b
>
> Please read at least the manual before causing unnecessary load for
> thousands of people.
>
Yes I have read the official documentation ntpdate. In the beginning of this
documentation it points to not to use the ntpdate, but use ntpd. The ntpdate
program will retire from distribution some time in the future. Functionality
of ntpdate has been build into ntpd. That is the main reason not to use
ntpdate.



So I still looking for how to force ntpd to reset time first time it start,
and continuing to discipline the clock afterwards. That would achieve our
goal to having a precision of +-1 ms after short time.


> > "Adrian 'Dagurashibanipal' von Bidder" <varys@fortytwo.ch> wrote in
message
> > news:1750205.XYWth8do2b@altfrangg.fortytwo.ch...
> [...]
>
> Why do you include all this if you're not referring to it in detail?
Sorry, will not happen again.

Sarbjit Singh wrote:
> So I still looking for how to force ntpd to reset time first time it start,
> and continuing to discipline the clock afterwards. That would achieve our
> goal to having a precision of +-1 ms after short time.

Recompile ntpd with a different reset limit, say 2-10 ms.

If it is so important to get within a couple of ms almost immediately, 
you'll have to accept a lot more steps until the algorithm settles down.

OTOH, as soon as you do drop out of the capture range, you will get a 
step back. I.e. your clock will be a lot less stable, but the maximum 
absolute error would probably be lower.

It would probably be good to also run with much lower poll intervals if 
you want to do this, and you'll have to redo the stability calculations.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Barbjit,

You can force ntpd to set the time directly and avoid slew upon startup
by simply removing the ntp.drift file. However, you will not like the
result, as it will take hours to recompute and refine the intrinsic
frequency correction, and it will not necessarily result in accuracy
within the millisecond at or shortly after startup.

The NTP clock discipline is essentially a feedback loop with a carefully
contrived impulse response. If you really must bound the residual error
quickly, you will have to (a) use kernel support to allow discipline at
every timer interupt and (b) re-engineer the impulse response for a
quicker risetime. This would mean reducing the poll interval much below
the 16-s lower limit now required by the adjustment process.

Dave

I think you want ntpd -gN, and use the "iburst" option for your server
and peers.

This is all documented at twiki.ntp.org, in the StartingNTP area.

H

Harlan,

No, this is misleading. The problem is much more basic than that,
notwithstanding the iburst consideration. Unless you know the intrinsic
frequency offset, simply jamming the time correction in the discipline
loop will not always result in a specific time offset bound, especially
if the poll interval is allowed to increase above 64 s, which is
normally the case.

I'm really concerned that the simplistic advice offered by quick and
dirty references like the twichy frequently disguises the engineering
principles involved. There are things you can and cannot do based on
solid engineering principles, some of which apply in this case. The
twichy and even the faq needs to know when casual advice does not apply
and reference to ugly and boring documentation really and truly is
required. In this case, the principles are based on physics and
engineering principles of feedback loop theory and analysis.

Let's say you are driving a car and join a train of cars heading
downtown to work. You are told to join the train and follow the car in
front of you within a tolerance of one inch and do that within five
seconds of joining the train. The feedback loop consists of your eyeball
as phase detector, the engine and drive train as variable frequency
oscillator and your brain as loop filter. Can you do that within one
inch and five seconds, two inches and ten seconds? Does this get my
point across?

Dave

Harlan Stenn wrote:
> 
> I think you want ntpd -gN, and use the "iburst" option for your server
> and peers.
> 
> This is all documented at twiki.ntp.org, in the StartingNTP area.
> 
> H

Mills,



The drift file has a very good function. As you expected, I don't want to
delete this file. :)





Since the ntpdate will be retired from distribution someday, many users will
miss the -b option. Maybe you could ask someone in the development team to
migrate the -b option from ntpdate, and make this official available in
ntpd.?



I think that alot of users could benefit of this option in ntpd.



Sarbjit