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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
