Potential desynchronization of epochs with large frequency detuning

[pyuxiang]

For a frequency detuning of 100pm (for simple crystal oscillators) at reference frequency 10 MHz, this corresponds to a timing drift of 1ms/s. The epoch size is roughly 500ms, so epochs initially synchronized via NTP (roughly a small 1ms to 20ms offset) will no longer overlap after 500s.

Note that this is normally not an issue when the two remote clocks are disciplined by rubidium clocks of at most 10 ppb.

If this is a potential issue, perhaps some epoch resynchronization scheme is required downstream, e.g. use of two epochs for peak tracking instead of only one epoch in costream.

[pyuxiang]

The relative frequency offset itself can also drift over time, will pose an issue as well?

[pyuxiang]

Using freqcd approach to bake in the frequency difference directly into the raw timestamps before packing into epochs mitigates this problem. An associated issue is related to the 20 hour 54-bit timestamp overflow, which needs fixing, see below:

https://github.com/franciumxzf/pfind/blob/cddfeafd7cd9f15d5015e430e0783e9939dccca0/src/pfind/freqcd.c#L275-L283