Re: offset values from ntpq and ntptrace
- From: Brian Utterback <brian.utterback@xxxxxxxxxxxxxxxx>
- Date: Mon, 03 Apr 2006 10:47:21 -0400
Thanks all of you for your answer, it has helped me to understand some
things... For David Wooley, here is my typical configuration:
- My company is building embedded switch router card wich is supposed
to implementent NTP protocol for synchronising its LAN... actually, my
boss want that I make a document for potentiel customer that will use
NTP for explaining them how does It work and when can they use NTP...
so It's a very open question because for example, my card may be not
connected to the Internet and may not have any reference clock (like
radio clock for example). So I have isolated 4 particular
1 - The card is connected to the Internet and we use a public server
for synchronizing the card.
2 - The card isnt connected and use its own clock as reference clock (I
know that it's not recommanded but...)
3 - The card isnt connected to the Internet and it use a reference
clock like GPS receiver.
4 - The card is sometimes connected to the Internet but mainly uses Its
own clock to synchronise itself.
Here are my early conclusions:
For configuration 1: We can use this configuration if we want to
synchronize our LAN not very accurately... approximately 10ms accuracy
to UTC time can be expected if everything is OK...
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.
For configuration 2: We can use this configuration only for maintening
our LAN synchronized but without any accuracy to UTC time expected. We
can only say that our LAN will have clock that differed from each other
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.
For configuration 3: I havent said a lot of thing because its depend on
the reference clock that we choose but it can guarentee an accuracy of
For configuration 4: It's a bad configuration because when the card are
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.
Are my conclusions right???
Anyone can say more about that?
My boss is also asking myself especially precision for configuration 2,
wich is the typical configuration where our card will be used. He knows
that we wont have any accuracy compared to UTC time, but the only
things he wants is that our LAN is synchronised thanks to the card. So
he wants to know what are the parameters that are important for
allowing that. I answer:
- drift difference between card's clock and client clock should not be
higher that 500PPM
- card's clock should be thermal stability
- card OS shouldn't be windows NT but rather Unix moder system or Linux
wich have greater resolution...
are you alright?
One last thing, I heard a lot about PPS, and I think that there is no
use for PPS unless to have its own reference clock? Am I right? Thank
you very much, and sorry for my english but technical conversation are
sometimes difficult for a non-english guy...
Quidquid latine dictum sit, altum sonatur.
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
- Re: offset values from ntpq and ntptrace
- From: Tim
- Re: offset values from ntpq and ntptrace
- Prev by Date: Re: offset values from ntpq and ntptrace
- Next by Date: Re: offset values from ntpq and ntptrace
- Previous by thread: Re: offset values from ntpq and ntptrace
- Next by thread: Re: offset values from ntpq and ntptrace