[patch] allow zero period for periodic equipment frontends

[Former user]

Sometimes 1000 events/second is not enough

diff --git a/src/mfe.cxx b/src/mfe.cxx
index 9042e01..5302f90 100644
--- a/src/mfe.cxx
+++ b/src/mfe.cxx
@@ -1929,7 +1929,7 @@ static INT scheduler()

          /*---- check periodic events ----*/
          if ((eq_info->eq_type & EQ_PERIODIC) || (eq_info->eq_type & EQ_SLOW))
-            if (eq_info->period == 0)
+            if (eq_info->period == -1)
                continue;

             /* check if period over */

[Stefan Ritt]

If you need more than 1000 events per second, don't define this as slow control events, but as trigger events. MIDAS is optimized to read trigger events much faster than slow control events.

[dd1]

At very high data rates, the mfe scheduler becomes unreliable because it does many background activities (updates watchdog timestamps, updates equipment statisitics, checks for alarms, etc).

I would say at above 100/sec you should use the multithreaded equipment type with an event fifo between your readout thread and mfe. (see mfe multithreaded examples)

The new tmfe c++ frontend has an improved scheduler for periodic events, but it inherited the 1 ms/1 kHz limit from mfe.c via the “int period” odb setting. I should look into removing this limitation and permitting at least 1 us/1 MHz periodic handler. The current Linux kernel does provide time functions with such high resolution.

K.O.

‌