Getting rid of the delays, moving some parameters back to StdDataLoop
I removed the delay m_readDelay
, it is not needed. But left the g_rx->getWaitTime()
as is -- we need to figure out whether we want to encapsulate it inside g_rx->readData()
or we just have to keep it in StdDataLoop.
And I moved the other parameters back to StdDataLoop, because they are not delays:
-
averageDataProcessingTime
is not a delay, it is a timeout, it does not delay anything. In principle, by its logic, it could be encapsulated somehow in the reading of the feedback from DataProcessors. But that's a pain. As it is now, the easiest is just to leave it as aStdDataLoop
parameter. -
maxIterationTime
is also a timeout, the maximum duration of theStdDataLoop::exec2
. When some triggers are lost, StdDataLoop ends the iteration after this timeout passes. (Strips occasionally lose some triggers due to data corruption, most likely it is something that happens on the stave.) -
maxConsecutiveReads
is a parameter ofStdDataLoop
algorithm, the same as inStdDataGatherer
. Also, I changed it inStdDataGatherer
, from the hardcoded4096
to a json-config parameter with 4096 as the default value. -
triggersLostTolerance
is also just a parameter of the StdDataLoop. From time to time, strips lose 1-2 triggers out of 500-1000 in the calibration runs, but in some situations we want the calibration proceed quickly, ignoring these lost triggers.
The only remaining delay is g_rx->getWaitTime()
. In principle, it corresponds to the latency of the HwController. So, it could be encapsulated in HwControllers' RxCore::readData()
. My idea was that HwControllers use Clipboards internally for the RX data, and this delay can be moved into the timeout in the Clipboard read. (So, the delay would be converted into a timeout.) But it is not true for all HwControllers.
- It is true for
NetioHW
,FelixClient
, andItsdaqFW
HwControllers (and forStarEmu
'sEmuRxCore<StarChips>::readData(uint32_t)
). - But some others do not use a Clipboard for RX data, like
SpecRxCore::readData
,rd53bRegSEETest
,PeripheralI2C
,BdaqSiTcpFifo
,EmuRxCore
(andRogueRxCore
,BdaqRxCore::readData
,EmptyHw
). So, we need to check, maybe those controllers can just live without a delay at all. Then we can removeg_rx->getWaitTime()
from StdDataLoop. Until then let's leave it there.
So, we need to figure out if we can encapsulate getWaitTime()
inside the HwControllers' readData()
or just leave it in StdDataLoop. Maybe, the controllers that do not use Clipboards, could implement the timeouting behavior in readData()
somehow differently.