s-fifteen-instruments / fpfind Goto Github PK

Issue by pyuxiang
Thursday Jan 26, 2023 at 08:56 GMT
Originally opened as franciumxzf/fpfind#4

The arguments defined by the original pfind in the qcrypto stack is listed here, while those used by the QKDServer controller is listed here.

https://github.com/s-fifteen-instruments/QKDServer/blob/79ff894a1dbc449b5ca2326c31e4a99faa4400a0/S15qkd/pfind.py#L11-L21

The relevant options to use should be:

• -d and -D: path to directory storing input epochs (instead of timestamps)
• -e: first overlapping epoch between the two remotes (corresponding to $T_{start}$)
• -n: number of epochs (corresponding to the acquisition time $T_a$)
• -V: verbosity (for debugging messages)
• -q: FFT buffer order (corresponding to FFT array size N)
• -R or -r: desired timing resolution (corresponding to $\sigma_t$)

Yet to define how the separation time between acquisitions $T_s$ should be defined in this interface, as well as other new parameters required for this new pfind functionality.

Issue by franciumxzf
Friday Feb 17, 2023 at 04:02 GMT
Originally opened as franciumxzf/fpfind#12

Issue by pyuxiang
Wednesday Feb 01, 2023 at 15:04 GMT
Originally opened as franciumxzf/fpfind#9

Relevant equation found in #6.

Perhaps we can name it freqcd for the frequency correction daemon, styled after the error correction package named thusly errcd.

Relevant parameters are:

• Pipe for (64-bit) timestamp events
• Frequency correction offset (either in floating point, or integer with specified units)
• Output pipe for corrected events (to chopper)

Might need to manually track overflow in timestamp events, as well as truncate back to 64-bit. Reference start time will correspond to the first timestamp event entering the pipe.

Issue by franciumxzf
Friday Feb 17, 2023 at 03:54 GMT
Originally opened as franciumxzf/fpfind#11

Method 1: calculate directly from original frequency offset by running pfind(alice, bob) and perform the calculation $\frac{1}{1 + \Delta f'} - 1$ or $-\frac{\Delta f'}{1 + \Delta f'}$
Method 2: obtain the result from pfind(bob, alice) and convert the time offset result accordingly
We need to quantify which method has less error.

Issue by pyuxiang
Thursday Jan 26, 2023 at 08:36 GMT
Originally opened as franciumxzf/fpfind#2

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.

Issue by franciumxzf
Monday Jan 30, 2023 at 09:58 GMT
Originally opened as franciumxzf/fpfind#7

None

Issue by franciumxzf
Monday Jan 30, 2023 at 09:26 GMT
Originally opened as franciumxzf/fpfind#5

None

Issue by franciumxzf
Friday Feb 17, 2023 at 03:40 GMT
Originally opened as franciumxzf/fpfind#10

None

Given a string of timestamps as follows:

-10_000_002  -2  -1  0  1  2 

The timestamps before and after the overflow should still be contiguous, but the observed output is instead:

> generate_freqcd_testcase -t 18014398499481982 18014398509481982 18014398509481983 0 1 2 \
     | freqcd -df 20000 -v | generate_freqcd_testcase -
18014398499481982
17
18
1672295219219
1672295219220
1672295219221

Under poorer NTP sync conditions, the timing difference between two sites can be >10ms. This is not ideal when dt < 0, because there will be missing timestamps in the target set of timestamps (i.e. bob) as they are shifted forward in time, due to the following timing compensation line:

If the buffer order is too low, this ~10ms timing shift becomes significant as the timing resolution reduces, potentially resulting in an empty timestamp array passed to the FFT generation step below:

The fix for this is relatively simple, simply shift the reference point for the reference timestamps (i.e. alice) forward as well. Note to check the performance impact, as well as the potential need to read in more timestamps from the timestamp/epoch files. As a workaround, the reference and target timestamps can be swapped to minimize this problem.

Debug log:

20240517_132847 INFO    main:665        | Namespace(help=0, verbosity=2, logging=None, config='fpfind.dataset019a7.conf', save=None, experiment=False, reference='data/20240515_dataset019a7_2Mcps+99,1split_initialloss_left_noclock.dat', target='data/20240515_dataset019a8_2Mcps+99,1split_initialloss_right_noclock.dat', legacy=True, skip_duration=0, sendfiles=None, t1files=None, first_epoch=None, skip_epochs=0, num_wraps=1, num_wraps_limit=4, buffer_order=21, initial_res=16, final_res=1, separation=6, peak_threshold=6, freq_threshold=0.1, convergence_rate=1.4142135623730951, quick=False, output=0, dt=0, dt_use_bins=False, precomp_enable=False, df=0.0, precomp_step=1e-07, precomp_stop=2e-05, precomp_ordered=False, precomp_fullscan=False)
20240517_132847 DEBUG   main:688        | Reading timestamps...
                                        |   Required duration: 0.3s (cross-corr 0.0s)
20240517_132847 INFO    main:727        |   Reading from timestamp files...
20240517_132847 DEBUG   main:749        |   Read 754195 and 656378 events from reference and compensating side.
                                        |     Reference timing range: [0.00, 0.30]s
                                        |     Compensating timing range: [0.00, 0.30]s
                                        |     (skipped 0.00s)
20240517_132847 DEBUG   main:782        | Running fpfind...
20240517_132847 DEBUG   [fpfind]:783    | START PROFILING
20240517_132847 DEBUG   fpfind:412      |   Applied initial 0.0000 ppm precompensation.
20240517_132847 DEBUG   [time_freq]:418 |   START PROFILING
20240517_132847 DEBUG   time_freq:137   |   Performing peak searching...
20240517_132847 DEBUG   time_freq:138   |     Parameters:
                                        |       Bins: 2^21
                                        |       Bin width: 16ns
                                        |       Number of wraps: 1
                                        |       Target resolution: 1ns
20240517_132847 DEBUG   time_freq:165   |     Iteration 1 (r=16.0ns, k=1)
20240517_132847 DEBUG   time_freq:171   |       Performing earlier xcorr (range: [0.00, 0.03]s)
20240517_132847 DEBUG   time_freq:198   |         Peak: S = 9.876, dt = -15831856ns (resolution = 16ns)
20240517_132847 DEBUG   time_freq:214   |           Accepted
20240517_132847 DEBUG   time_freq:269   |       Performing later xcorr (range: [0.20, 0.23]s)
20240517_132847 DEBUG   time_freq:332   |       Calculated timing delays:
                                        |         early dt       =  -15831856 ns
                                        |         late dt        =  -15832160 ns
                                        |         accumulated dt =  -15831856 ns
                                        |         current df     =    -1.5100 ppm
                                        |         accumulated df =    -1.5100 ppm
20240517_132847 DEBUG   time_freq:165   |     Iteration 2 (r=3.8ns, k=1)
20240517_132847 DEBUG   time_freq:171   |       Performing earlier xcorr (range: [0.00, 0.01]s)
20240517_132847 DEBUG   [time_freq]:418 |   END PROFILING: 1 s
20240517_132847 INFO    fpfind:425      | Peak finding failed,   0.000 ppm: Array is empty!

Issue by pyuxiang
Thursday Jan 26, 2023 at 08:18 GMT
Originally opened as franciumxzf/fpfind#1

To allow external code to invoke the pfind function, the inputs and outputs of pfind should be defined.

The most straightforward implementation is to have the code read/write to standard file descriptors (stdin, stdout, stderr) for interoperability with other programs - in particular:

• reading standard command line syntax (e.g. -r, -d) from stdin
• writing output as a space-delimited string to stdout
• writing debugging and error messages to stderr

Usage of argparse for command line argument parsing and logging Python libraries may be helpful.

Issue by pyuxiang
Thursday Jan 26, 2023 at 08:46 GMT
Originally opened as franciumxzf/fpfind#3

This will simplify testing for upcoming changes to the pfind function.

Issue by pyuxiang
Wednesday Feb 01, 2023 at 11:28 GMT
Originally opened as franciumxzf/fpfind#8

Once the final time and frequency offset is calculated, we should do one more cross correlation with the modified timestamps and output the significance of the peak (sigma), in line with the output of pfind.c.

This is distinct from the double pfind run on (alice, bob) and (bob, alice) - this belongs to the tests to check for algorithm correctness.

Given a coincidence window of 0.8ns, the maximum tolerable clock skew in an epoch duration (i.e. ~0.536ns) is 1.49ppb. Because the current modality is to do only initial correction before passing to chopper, this means the frequency itself can drift beyond 1.49ppb. When this occurs, the peak will be severely suppressed.

Tiered solutions to this problem:

1. Feed the currently measured frequency drift back into freqcd for subsequent correction. This is simple enough: Read output from costream and compute the frequency drift from the tracking value. This will allow for 0.5ppb resolution corrections. Only downside is the frequency compensation will lag a little.

2. Do fine correction of coincidence timing within each epoch, so that costream will read a stronger peak. This is important for getting better QBER values out of the measurements. Potential problems being costream may end up reading discontinuities in timestamps between epochs and/or timestamps will be cut off from the epoch. Given that the per-epoch correction is small, i.e. < 1ppb, or ns adjustments, this is not too big an issue.

3. Do frequency compensation within each epoch. Preliminary tests suggest that basic peak tracking + floating point correction is still much faster than the event throughput (of ~1Mevent/s). This is optional since most of the mitigation is done by solution (1), unless the rate of clock skew drift itself is >2.8ppb/s (i.e. 1.49ppb/0.536s).

See plots for frequency drift measurements.

Issue by franciumxzf
Monday Jan 30, 2023 at 09:29 GMT
Originally opened as franciumxzf/fpfind#6

1. frequency correction done on rawevents instead of epochs
2. pfind will find the frequency differency: if it is large, will perform the frequency correction on rawevents before chopper
3. store the frequency difference in the units of 1e-12
4. how to apply the frequency correction in integer multiplication