[ntp:questions] Re: offset values from ntpq and ntptrace

Brian Utterback brian.utterback at sun.removeme.com
Mon Apr 3 14:47:21 UTC 2006


Tim wrote:
> 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
> configuration:
> 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
> from 100us.

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
> few us.
> 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...
> 


-- 
blu

Quidquid latine dictum sit, altum sonatur.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom




More information about the questions mailing list