[convFixb]

Doubtful of the last paragraph: What kind of clock oscillator 'learns' to keep better time by being adjusted from a better source? A normal crystal doesn't have any memory effect AFAIK.

In a typical real life scenario where the GPS / antenna malfunctions, your server clock will just slowly.. drift.. I.e. the crystal runs a bit too fast or a bit too slow.

[dfox]

The last paragraph is what the FB's timecard (and essentially any other rubidium based frequency normal) does. You use the GNSS frequency output as a reference for PLL that does fine tuning (on the order of tens of ppm) of the rubidium oscilator (or even normal crystal oscilator). The reference oscilator modules usually have some kond of input for this kind of fine tuning (in xtal case this analog input typically controls biasing of varactor that introduces parasitic capacitance to the crystal, in rubidium case it is usually done digitally and it changes the division factor in the feedback path of internal PLL).

Edit: and for that matter even ntpd/chrony does this tuning in software and can compensate for imprecise and/or slowly wandering host clock generator (obviously it cannot compensate for abrubt changes and intentionally does not even try to).

[myself248]

That's literally the definition of disciplining an oscillator:

https://csrc.nist.gov/glossary/term/disciplined_oscillator_d...

For a quartz oscillator, it's typically done by holding the crystal at a constant temperature ("ovenized", "oven controlled"), and then varying its loading capacitance by manipulating the reverse bias voltage of a varactor (a diode whose junction capacitance varies in a well-defined way according to applied voltage). You connect a lots-of-bits DAC and a very stable amplifier to the varactor, and keep all those pieces inside the same oven so they're all isothermal.

Apply a very long time constant (typically on the order of 11h58m out to maybe 2 weeks) to the control loop that drives the DAC, and after a few loop-times you've got a quartz crystal whose period is precisely tuned and whose behavior will remain incredibly stable when the disciplining reference goes away. (As long as you're smart enough to notice the loss of reference and freeze the DAC value, rather than naively assuming there's an enormous difference and slamming the control loop against a limit and destroying your carefully-honed performance. Which is what pretty much everyone implementing this from scratch does at least once.)

For rubidium atomic clocks, the disciplining process is usually done by varying the magnetic field applied to the vapor cell. Since these work by measuring the energy absorbed by a specific hyperfine transition, but that energy is only well-defined at zero static magnetic field, it's necessary for the physics package to cancel out the Earth's magnetic field. This is done with a set of Helmholtz coils, but how do you know how much current to put through them? By comparing the measured frequency with an external reference of higher quality. Since Rubidium oscillators are inherently several orders of magnitude more stable than quartz, this is done with very long time-constants (since any apparent error is probably jitter on the GPS receiver's part).

Ovenized quartz GPSDOs are common at cellular tower sites, whereas rubidium finds more application at central offices. I own clocks that exploit both of these mechanisms. (The rubidium is down right now while I build a new DAC for the tuning voltage that drives the coil current amplifier.)