[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
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.
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
>> 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.
> Antonio M. Moreiras
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
More information about the questions