Page History

...

Ideally, replace Worker threads with Worker processes
BUT, RIC's (complicated) infiniband stuff is all multithreaded

Option 1: (the original idea discussed above)

...

Advantage:
- only 1 process
- no new DRP

Disadvantage:
- weird

Option 2:

Python is low performance.  Maybe replace all of it with multiprocess zmq?

...

Advantage:
- looks more like shmem
- standard multiprocess python

Option 3:

kcu1500 -> PGPReader -> N*Worker -> Ric's TEB -> Collector
                                    ^^^^^^^^^-- on another node

...

Disadvantage:
- 2 processes with communication (also have that in option 2)

work to be done:

- valerio: drp communicate with multiple python processes
- mona:
  o routines to modify dgrams from python
    - look at dgramCreate.pyx
      https://github.com/slac-lcls/lcls2/blob/master/psana/psana/peakFinder/dgramCreate.pyx
      also the test test_py2xtc.py
      goal: receive the raw-dgram, and return a fex-dgram with the raw
      data removed (almost always) and put in fex data.
  o think about calib-fetch scaling (lower-priority)
    - ideally independent of mpi. zmq approach? how do we
      determine "supervisor"?