Antonio M. Moreiras wrote: > 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 > > 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).
This is an easy problem to solve: You engineer the system to use a SW clock, saving the offset between UTC(GPS) and UTC(BR) on each calibration, then in the 1-12 months between those calibrations you use the GPS PPS signal to frequency-lock your Rb-supplied time. > 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. If you make sure that the maximum slew rate of your Rb oscillator, when steered by GPS PPS signals, is something like 2e-10 (twice the specified aging rate) or less, then you can "legally" guarantee that you pass out time with a maximum error of 64 ms after a year without any calibration directly from UTC(BR). > > The studied alternatives include using cesium reference clocks, instead > of rubidium, or calibrate the rubidium ones within shorter periods of time. I have another suggestion: Instead of calibrating every N months, why not use the same approach as is currently used to generate UTC in the first place, and to calibrate UTC(BR) vs UTC itself: Use common-view observation of the same GPS sats as UTC(BR), this would allow you to stay within a small number of ns of your legal reference, at all times. For a much cheaper/easier alternative: Run your clock with direct GPS PPS steering. UTC(BR), which is probably using common-view GPS for time transfer anyway, can tell you weekly what the current offset is between UTC(USNO) (i.e. GPS time) and UTC(BR). I.e. the only thing you require is a way to sound the alarm in your national laboratory if UTC(GPS) should ever start to drift, in which case you can simply disconnect the GPS PPS signal and allow your NTP server to coast along on the internal Rb clock. Please notice that even if GPS should ever start drifting, as long as the slew rate is less than the free-running slew rate of your Rb clock, you are still better off trusting GPS between the visits from your UTC(BR) representative! Terje -- - <[EMAIL PROTECTED]> "almost all programming can be viewed as an exercise in caching" _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
