Slow Deadtime

dxs114

Hi,

This is probably a bit of a stupid question but it is not entirely clear to me what the best way to get around this is.

We have written an experimental sequence that takes ₁.5 s that we run in a loop (that also collects data from NIDAQ etc.). However, we have found that the deadtime between the runs is quite long (₂ - 3 s), which appears to be due to the communication between the PC and ARTIQ (i.e. the sequence being sent to the ARTIQ seems to take up most of this time).

I was wondering whether there was any advice as to the best way to reduce this deadtime as it is currently limiting our experiments, and if so, what would be the most sensible way to do this?

Thank you for your help in advance.

sb10q

https://m-labs.hk/artiq/manual-beta/rtio.html#seamless-handover

dxs114

Thanks for the reply. What what I can understand from that link, it seems that if I have a "run" function, which a combination of other two functions "k1" and "k2", the seamless handover is done more or less by itself. Or am I misunderstanding this page?

However, what happens if I want to put the "run" function into a loop - this is where my deadtime is coming from. I have the "run" function in loop and it seems that everytime I re-submit the "run" function to ARTIQ, this takes a few seconds. Is there a way to speed this up, for example, while the current "run" is running the information for the next "run" is being sent to the ARTIQ CPU and as soon as the previous run finishes, the next one starts?

sb10q

You can try NAC3 (https://forum.m-labs.hk/d/392-nac3-new-artiq-compiler-3-prealpha-release) which compiles faster.

dxs114

Hi,

Thank you for your reply and sorry for my delayed response. Is there anything like NAC3 possible with earlier versions of ARTIQ as the one we are using is running on ARTIQ 5 at the moment? Essentially, I just want to speed up the communication between our PC and the ARTIQ so that the time between each of the runs is reduced as much as possible when running the same code hundreds of times.

sb10q

dxs114 Is there anything like NAC3 possible with earlier versions of ARTIQ as the one we are using is running on ARTIQ 5 at the moment?

No, NAC3 requires firmware version 7. It's also experimental "prealpha" software as the post mentions.

rjo

dxs114 You mention that you run your 1.5 s long sequence in a loop and between iterations there are 2-3 s for compilation and upload. The general approach is to push that loop down into the kernel. That way you save the 2-3 s per iteration.

sinaraafws

I'm experiencing the same issue on ARTIQ 7.
I load a 100k × 32-bit array using very simple kernel code (with out long array it took at all <₀.1s).
This results in a 0.9-second dead time, and the sequence is adjusted to run at 1 second. (repetition every 1.9 sec)

I added a timestamp printer inside artiq.coredevice.core._run_compiled, and here’s what I observed:

self.comm.load() takes about 0.28 seconds — which is already quite a lot. Even at 100 Mb/s, it should be significantly faster.

self.comm.run() takes ₀.0001seconds — not sure what it's doing? It looks like time for kernel FPGA code compilation and run flag. But it fine do not take time at all.
self.comm.serve() takes 1.17 seconds, which includes 0.17 seconds of unexplained idle time, which happen at the end of sequence (2 some rpc call at the end, second use this time). What’s going on here?
And some additional 0.4 s time for some thing else!! What time used before load
Thank you!
P.S. total deadtime and all times separatly is mostly linear with data size.

sb10q

Please start a new topic and provide more details, including minimal code that demonstrates the slowness issues.
Also we've made a bunch of performance improvements in a number of areas (e.g. Zynq-SoC, firmware on ARTIQ-9, NAC3), please make sure you are up to date.