s-fifteen-instruments / fpfind Goto Github PK
View Code? Open in Web Editor NEWAdd-on implementation of frequency compensation for qcrypto.
Add-on implementation of frequency compensation for qcrypto.
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
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: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:
-r
, -d
) from stdinUsage of argparse for command line argument parsing and logging Python libraries may be helpful.
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:
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.
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.
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
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:
Line 362 in 857dbc9
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:
Lines 176 to 178 in 857dbc9
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: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
.
Generally just avoiding shooting oneself in the foot when supplying the same filename, which causes the file to be erased.
Issue by franciumxzf
Friday Feb 17, 2023 at 03:40 GMT
Originally opened as franciumxzf/fpfind#10
None
Issue by franciumxzf
Monday Jan 30, 2023 at 09:26 GMT
Originally opened as franciumxzf/fpfind#5
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
Issue by franciumxzf
Monday Jan 30, 2023 at 09:58 GMT
Originally opened as franciumxzf/fpfind#7
None
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 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:
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 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.
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.
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 -n
: number of epochs (corresponding to the acquisition time -V
: verbosity (for debugging messages)-q
: FFT buffer order (corresponding to FFT array size N
)-R
or -r
: desired timing resolution (corresponding to Yet to define how the separation time between acquisitions pfind
functionality.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.