[ntp:questions] Re: offset values from ntpq and ntptrace
Tanguy.ropitault at gmail.com
Mon Apr 3 15:34:57 UTC 2006
>How are you determining which server to use? Is there a default, and if
>so, is it easily changeable? Ideally, you should be providing the
>NTP server yourself, or better still, a set of servers. If you do not
>provide your own servers, and there is a default set configured, you
>absolutely *MUST* get permission from the owners before building them
>into your product, even if the server is open access for normal use.
>If you do not provide a preset default and require hand configuration,
>it is still advisable to get permission from the server owner if you
>provide your customers with a list of recommended servers before you
>include a server on the list. Do not build a product that does not
>allow changing the server.
I am aware of theses problems. And of course, NTP server can be changer
easily. Actually, there will be no public NTP server set by default,
the user must set one. And the documention will warn product's user
that for using NTP server, you have to get permission from the owner.
>Not sure what accuracy you are expressing here. What range of drift
>rates has your product shown under the range of operational
>environments? How stable is the clock? This will determine the
>desirability of this configuration.
By accuracy in this case, I mean the real difference between my
embedded card and the real UTC time... However, I dont understand what
you means by how stable is your clock... I dont know for the moment the
range of drift rates of my product but I guess that you want to say
that I must absolutely use clock with drift inferior to 500PPM... but I
have read elsewhere that ideally, I must use clock with drift inferior
> For configuration 4: It's a bad configuration because when the card
> synchronizing itself on its reference clock, it drifts from UTC time
> and when you connect the card to Internet, bad things can happen like a
> higher difference of 128ms between the card and public's server time so
> it's a bad configuration.
>>No, this is dependent on how the device adjusts its clock and how often
>>you can expect to connect. If the clock is reasonably stable, and you
>>connect fairly often and the device slews rather than steps the clock,
>>then this might be a very good configuration. If the clock is reasonably
>>stable, once the correct drift rate has been determined, it might end
>>up pretty accurate, even between connections.
I agree with you... in fact, I have said in my doc that this case will
happen only in very bad case but can happen. But you're right, this is
one thing that I dont really know about NTP.. when the frequency drift
rate is estimated, NTP will correct my machine even if it's not
connected, so the only thing that can make my clock drift even is the
frequency drift is corrected is the fact that the clock is unstable,
that's it? that's why I need to poll server? I know this is the base of
More information about the questions