[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




More information about the questions mailing list