Page History

...

•  I think this is done with the "inprocSend" ZMQ context in DrpBase.cc.
• The phase1 response to the control level from the drp nodes is in PGPDetectorApp.cc:handlePhase1()

MEB Discussion

April 15, 2022: claus, caf, cpo

Ric found that in UED the disable transitions were being delayed by several seconds, queueing up a few of them and creating buffering problems for the meb and difficult-to-understand crashes (perhaps because we only have 1 buffer for the disable transition?).  We discussed two options to address this, allowing the meb to participate in the control.py decision about when to execute the next transition:

option (1) is having the meb participate in the phase2 sweep (like teb)
  - more work for ric
  - have to generate the "inproc" (complete) message
  - complication: has to handle slowupdate in a special way
  - more self-contained
  - ric worries that meb buffers may not be promptly returned to the drp: maybe wouldn't work?

option (2) is meb becomes like a drp: generate it's on phase2 complete and send to control.py via ZMQ "inproc" message
  - more work for caf
  - could more precisely identify the meb as being a problem if meb crashed
  - touches both drp and control.py code

does the above decision affect speed of phase2?
- i think the answer is no: meb doesn't do anything in phase2

tentative decision is to try option (2)