semcomedi.find_best_oversampling_rate() sometimes return wrong period

[pieleric]

In semcomedi, find_best_oversampling_rate() sometimes return a wrong period.
That's not directly obvious, but eventually that causes such error to be reported:
Failed to create the precise command period = 2300300 ns (should be 2300321 ns)

Here are two logs causing the same issue, but potentially caused by different cases:

(semcomedi) DEBUG: Found duplication & over-sampling rates: 2.30032e+06 ns x 1 x 1 = 2.30032e+06 ns
(semcomedi) DEBUG: read took 0.00142694 s
(semcomedi) DEBUG: Waited for the read thread for actually 0.00340796 s
(semcomedi) DEBUG: Write finished after 0.00349689 s, while expected  0.00137471 s
(semcomedi) DEBUG: Counter sync read after 0.00354695 s
(semcomedi) WARNING: Simultaneous acquisition from analog and counting detector not supported. Only going to acquire from counting detector!
(semcomedi) DEBUG: Reading 1 lines at a time: 1 samples/counter every 2300.32 µs
(semcomedi) DEBUG: Going to read 1 lines
(semcomedi) DEBUG: Generating new write and count commands for 2 scans on [1, 0]/8
(semcomedi) ERROR: Failed to create the precise command period = 2300300 ns (should be 2300321 ns)

=> This is with a long dwell time, and with the counting detector. It seems to have returned period not even multiple of 50 ns (which is a hardware limitation).

(semcomedi) DEBUG: Found duplication & over-sampling rates: 1650 ns x 1 x 17 = 28050 ns
(semcomedi) DEBUG: ranges X = (-2.7486572265625, 2.7486572265625)V, Y = (-2.7486572265625, 2.7486572265625)V
(semcomedi) DEBUG: Reading 240 lines at a time: 16719840 samples/read every 28.05 µs
(semcomedi) DEBUG: Going to read 240 lines
(semcomedi) DEBUG: Generating new write and read commands for 491760 scans on channels [1, 0]/(0, 1)
(semcomedi) ERROR: Failed to create the precise command period = 1700 ns (should be 1650 ns)

=> Dwell time was set at 28.05µs, and two analog detectors are running simultaneously. The result of the method seems coherent, but likely for 2 read channels, the hardware limitation is a period multiple of 100 ns (ie, 2x50ns).

[pieleric]

Should now be fixed both in v2.4.3, and coming release v2.5.