[ntp:questions] ntp.br project - how to calculate the discrepancy?
Terje Mathisen
terje.mathisen at hda.hydro.com
Tue Oct 9 05:54:38 UTC 2007
Antonio M. Moreiras wrote:
> Calculating in a mensal basis (but considering 5e-11 as a constant freq
> error within the month, what is wrong too but with a smaller
> overestimated error):
>
> Month Accum Ageing Err(ms) Tot Error(ms)
> 1 0,00000000005 0,130 0,130
> 2 0,00000000010 0,259 0,389
> 3 0,00000000015 0,389 0,778
> 4 0,00000000020 0,518 1,296
>
> If this is correct, it means that whith 3 calibrations per year, it
> would be possible to keep the discrepancy < 1ms. And if we calibrate the
> system in a monthly basis, the discrepancy would be less than 150us.
>
> We are studying, as suggested by some people, using GPS as time
> reference, but one of primary requisites to our project is to have the
> servers in sync with the official brazilian time, that is UTC(ONRJ).
This is an easy problem to solve: You engineer the system to use a SW
clock, saving the offset between UTC(GPS) and UTC(BR) on each
calibration, then in the 1-12 months between those calibrations you use
the GPS PPS signal to frequency-lock your Rb-supplied time.
> Considering that we could completely trust the GPS system (can we? it is
> a us military system...) there would be no practical differences, but
> yet there would be some legal differences. So we are looking for
> alternatives to synchronize to UTC(ONRJ) with an acceptable accuracy.
If you make sure that the maximum slew rate of your Rb oscillator, when
steered by GPS PPS signals, is something like 2e-10 (twice the specified
aging rate) or less, then you can "legally" guarantee that you pass out
time with a maximum error of 64 ms after a year without any calibration
directly from UTC(BR).
>
> The studied alternatives include using cesium reference clocks, instead
> of rubidium, or calibrate the rubidium ones within shorter periods of time.
I have another suggestion:
Instead of calibrating every N months, why not use the same approach as
is currently used to generate UTC in the first place, and to calibrate
UTC(BR) vs UTC itself:
Use common-view observation of the same GPS sats as UTC(BR), this would
allow you to stay within a small number of ns of your legal reference,
at all times.
For a much cheaper/easier alternative: Run your clock with direct GPS
PPS steering. UTC(BR), which is probably using common-view GPS for time
transfer anyway, can tell you weekly what the current offset is between
UTC(USNO) (i.e. GPS time) and UTC(BR).
I.e. the only thing you require is a way to sound the alarm in your
national laboratory if UTC(GPS) should ever start to drift, in which
case you can simply disconnect the GPS PPS signal and allow your NTP
server to coast along on the internal Rb clock.
Please notice that even if GPS should ever start drifting, as long as
the slew rate is less than the free-running slew rate of your Rb clock,
you are still better off trusting GPS between the visits from your
UTC(BR) representative!
Terje
--
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
More information about the questions
mailing list