[ntp:questions] project ntp.br - discrepancy from UTC

Unruh unruh-spam at physics.ubc.ca
Tue Jan 1 00:40:02 UTC 2008


"Antonio M. Moreiras" <antonio at moreiras.eng.br> writes:

>The Cesium clock at observatorio nacional (ON) is UTC. In fact, the ON
>is one of the metrology laboratories that colaborates with the Bureau
>International des Poids et Measures (BIPM) in generating the UTC (as
>NIST does in USA, for example).

>The Rubidium clocks are synchronized with the UTC at least one time per
>year and the manufacturer says that the Rubidum reference has a monthly 
>aging less than 5e-11 and a yearly aging less than 5e-10.

>It gives us a 16ms maximum discrepancy from UTC (31,536,000,000 ms/year 
>* 5e-10 * 1 year = 15.765ms - is this correct?)

I would say that that is too large. 

>After one year, with the discrepancy at 16ms it will be probabily of the 
>same order than the half round trip time for the majority of the clients.

That does not matter. If the two one way trips are consistant, then the
trip time is cancelled out by ntp. ntp can do much better than 16ms. I have
a GPS clock and also connect to tick.usask.ca  for which the travel time is
44 ms, but the typical difference between my local GPS time and the ntp
time obtained from them is less than one ms. 
EG
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
+tick.usask.ca   .GPS.            1 u  797 1024  377   44.364    0.147 0.104

That is .15ms off GPS time ( it is also a GPS receiver).




>Given this, do you you think it will be necessary any modification?

>If so, what would be the maximum discrepancy allowed to not need any 
>modifications? As the primary servers are appliances from Symmetrycom or 
>Spectracom probabily it will be very difficult to get customized 
>firmware versions... Maybe we should study the possibility of 
>synchronize the Rubidium reference clocks more frequently with UTC.

I would think so. On a one month basis your clocks seem to be about .2ms,
which would be more reasonable.



>I don´t know if I correctly understood what this discrepancy can cause. 
>If a client is using other sources attached directly to GPSs, for 
>example, there is a risk that our servers being considered falsetickers. 
>Is it? Or is there other problems?

With a 16ms error it should probably be considered one. 


>A discrepancy of 16ms in a Internet NTP primary server is acceptable?

I would say it is pretty far out. 


>In Brazil time stamps should be less than 100ms accurate to be legaly 
>valid (for financial or government institutions, for example). I think 
>it is the same in other parts of the world. Then, 16ms appears to 
>reasonable for an Internet service.

>The majority of the Internet NTP primary servers are GPS based. For 
>curiosity: what is the discrepancy of GPS time from UTC (without 
>considering the leap seconds)?




More information about the questions mailing list