Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  02 Mar 2021, Konstantin Olchanski, Info, shortest possible sleep 
    Reply  02 Mar 2021, Stefan Ritt, Info, shortest possible sleep 
       Reply  03 Mar 2021, Konstantin Olchanski, Info, shortest possible sleep 
Message ID: 2116     Entry time: 02 Mar 2021     In reply to: 2115     Reply to this: 2117
Author: Stefan Ritt 
Topic: Info 
Subject: shortest possible sleep 
Why do you need that? Periodic equipment typically runs ever ten seconds or so, meaning one can do this easily in a scheduler.

For polled equipment, you don't want to sleep at all. Because if you sleep, you might miss an event. That's why I put my poll in mfe.c into a for() loop. No 
sleep, maximum polling rate. I just double checked on my macbook air. 

- If poll is always false (no event available), the loop executes 50M times in 100ms (calibrated during startup of the frontend). That means one iteration 
takes 2ns (!). So if an event occurs, the readout is started with a 2ns overhead. No sleep can beat that. In a real world application, one has to add of course 
the VME access or so to poll for the event.

- If poll is always true, the framework generates about 700k events each second (returning jus a few bytes of event data).

So if one adds any sleep here, things can get only worse, so I don't see the point for that. Of course polling eats one kernel at 100%, but these days every 
CPU has more than one, even my 800 MHz Xilinx embedded ARM CPU (Zynq).

ELOG V3.1.4-2e1708b5