# [ntp:questions] ntp.br project - how to calculate the discrepancy?

David L. Mills mills at udel.edu
Tue Oct 9 17:56:13 UTC 2007

```Antonio,

Look carefully at your rubidium oscillator manual. A rubidium oscillator
is not a primary standard and must be adjusted with respect to a primary
standard such as a Cesium oscillator. Assuming that has been done by the
manufacturer, the limits you state are on the departure (mostly ageing)
from the nominal frequency. At an ageing rate of 5e-10, the error after
one year is about 15 ms.

Dave

Antonio M. Moreiras wrote:
> David Woolley escreveu:
>
>>> A discrepancy of 16ms in a Internet NTP primary server is acceptable?
>>
>>
>> It would exceed modern expectations, even if not necessary for most
>> applications.  People expect this sort of accuracy on end nodes.
>
>
> I have understood that 16ms is unnaceptable and I will review the project.
>
> But I need help to know, at first, if I calculated this 16ms correctly.
>
> The rubidum clock manufacturer says that:
> mensal ageing < 5e-11
> anual ageing  < 5e-10
>
> What would be the correct way to calculate the discrepancy in seconds
> after a given elapsed time?
>
> I calculated the error as 31,536,000,000 ms (1 year) * 5e-10  =
> 15.765ms, but I think this is not correct, because the 5e-10 is the
> frequency error after 1 year. This calculation would be correct if the
> 5e-10 were a constant frequency error along all the year, what is not
> the case.
>
> 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
> 5    0,00000000025    0,648    1,944
> 6    0,00000000030    0,778    2,722
> 7    0,00000000035    0,907    3,629
> 8    0,00000000040    1,037    4,666
> 9    0,00000000045    1,166    5,832
> 10    0,00000000050    1,296    7,128
> 11    0,00000000055    1,426    8,554
> 12    0,00000000060    1,555    10,109
>
> 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).
>
> 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.
>
> The studied alternatives include using cesium reference clocks, instead
> of rubidium, or calibrate the rubidium ones within shorter periods of time.
>
>>> what is the discrepancy of GPS time from UTC (without considering the
>>> leap seconds)?
>>
>>
>> 50 nano seconds at about the 50 percentile, is the official
>> specification.
>> The constellation needs to be in synch with each other to rather better
>> than this for GPS to work at all, although it is not strictly necessary
>> that they match UTC.  Even if they don't match UTC exactly, the offset
>> will be available.
>>
>> I seem to remember that typical NTP servers can lock to this to
>> microsecond accuracies, although typical network delays will degrade
>> this to around 1 ms.
>
>
> Thanks.
>
> []s
> Antonio M. Moreiras
>
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ----------------------------------------------------------
>    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
> ----------------------------------------------------------
>                http://www.usenet.com

```