[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