29 January 2019
Design notes for ipctogt

GRETINA routines exist that setup and take down clients.  The Gretina Event
Builder is a SERVER in the IP sense.  Clients "connect", using send and recv
to exchange information.  Some of that is hidden by the GRETINA routines.

The tricky parts are around the routines:

1) the GEB host and port can change.  They must be discovered using channel
   access:  caget GEB_CV_Addr and GEB_CV_Port, before starting setup.
   Ron apparently gets these on the command line?

2) Each send to the GEB gets an acknowledge.  If not equal to 0, the send has
   been rejected.  The GEB wants one event at a time.
3) The GRETINA code uses epics mutexes to control?
4) The end of a run causes the SERVER to exit, killing all connections....
   So we have to check the state of a CV, Cluster_CV_State, to be sure we 
   are ready? Ron kills the task and restarts it.  I just have to start again
   with setGEBClient. Wait, there is a routine checkGEBClient that gets the
   state.

5) Use Ron's gretinaControl.c to control the run state.  It has all the proper 
   callbacks and timers for an asynchronous system like EPICS.

 
Sketch of program flow
   **Basic rule is that this program runs forever until stopped by PACMAN**
   While running, Communications with GRETINA is by EPICS Channel Access or by 
   client connection to the Global Event Builder.  During transitions of the 
   GEB, as happens when runs stop, ipctogt should stay up and running.


   Initialize ORPAS
      Allocate buffer memory
      Open connection to IPC ring buffer in shared memory
   Initialize GEB Client

   loop1 forever
      End of run branch point?
      Check Cluster_CV_State - if Cluster_CV_State is Run, continue, else wait
      //volatiles
      Get GEB_CV_Addr - GEB server name
      Get GEB_CV_Port - GEB port number
      //
      setupGEBClient - make connections to GEB
      //
      loop2 forever
         Get an IPC buffer
         Find the end of real data
         Find the end of the next event
         loop3 over buffer
            extract next event
            build GEB event data buffer
            loop4
               send buffer
               check pacman interrupt - cleanup and return
               check status - if not accepted, continue to try
               check status - if disconnected - set disconnected flag, break
            end loop4
            check for disconnect - if true, break
          end loop3
          check for disconnect - if true, break
       end loop2
   end loop1


28 Jan 2019

Success yesterday in getting the code to work, talking to GEB.  
VMETEST is running 29K evt/sec and transferring events that look
correct at GEB.  The event rate into the GEB is 7900 evt/sec, and Chris
Campbell thinks that the GEB is fully busy.
We have options:
1) impose the GEB deadtime on ORPAS, by making ipctogt a required client.
We may never have tested that in MCSQ's version of the ipc.
2) try to send more events per transmission?
3) Keep the event rate below 7K. How far below 7k is an interesting question.

