Hi all,

many experiments separate the initialization of devices, e.g., init, from the "actual" experimental sequence, e.g., exec:

class Example(EnvExperiment):
    def build(self):
        self.setattr_device("core")
        self.urukul_cplds = [self.get_device(f"urukul{i}_cpld") for i in range(4)]
        self.urukul_channels = [
            self.get_device(f"urukul{i}_ch{j}") for i in range(4) for j in range(4)
        ]

    def run(self):
        self.init()
        self.exec()

    def init(self):
        for cpld in self.urukul_cplds:
            self.init_urukul_cpld(cpld)
        for channel in self.urukul_channels:
            self.init_urukul_channel(channel)

    @kernel
    def exec(self):
        self.core.reset()

        self.urukul_channels[0].sw.on()
        self.urukul_channels[0].set_att(10)
        self.urukul_channels[0].set_frequency(1e6)
        # ...

    @kernel
    def init_urukul_cpld(self, cpld):
        self.core.break_realtime()
        cpld.init()

    @kernel
    def init_urukul_channel(self, channel):
        self.core.break_realtime()
        channel.init()
        channel.cpld.init()

Running init takes quite some time, especially in the present case, where we "dynamically" initialize the devices.

What are some strategies you can think of to minimize this initialization time?

Some ideas, I have - but not sure if they would actually work:

  1. Let python template an init function which can be completely run on the kernel without host interaction (in the present example the host has perform many calls to init_urukul_cpld and init_urukul_channel).
  2. Move the initialization to an idle kernel and ensure that the idle kernel runs at least once in-between the scheduled experiments.

Kind wishes,
Bodo

We now use self.setattr_argument('initialize_devices', BoolValue(True)) to decide if we initialize the devices or not. When we submit a series of experiments to the scheduler, we have the first run initialize the device and the subsequent ones skipping the initialization by overwriting the arguments when submitting the experiment to the scheduler.

We now are down to about 2 s between the experimental runs where the actual sequence is below a few hundred ms.

With artiq_coremgt log, we observe that the master Kasli's runtime often fallsback into the idle kernel and then a new connection with incrementing port numbers (> 40000) is shown.

Any suggestions, how we could reduce the time between the experimental runs further?

    bodokaiser Any suggestions, how we could reduce the time between the experimental runs further?

    Try NAC3.