(Stefan Ballmer - not Jeff)

I set up a test for diagnosing front end to front end communications via 4 separate routes:
1) IPC
2) EPICS read (pull data)
3) EPICS write (push data)
4) EPICS write and read, via a third epics server (push to 3rd server, pull from 3rd server)

The setup has a counter on H1odcmaster, this is sent via temporary IPC to h1ascimc, and then returned back to h1odcmaster via the 4 routes described above. For IPC and epics read operations I get an error flag, which I am reporting. No such thing is available for an epics write operation.

h1odcmaster is currently running at 32k, h1ascimc is running at 2k.

I calculated the following quantities
- DELAY          : round trip delay in sec
- DELAY mean     : averaged DELAY
- DELAY max:     : largest DELAY observed
- JITTER MAX     : largest time interval between updates
- JITTER MIN     : shortest time interval between updates
- JITTER MAX-MIN : = JITTER MAX - JITTER MIN, the peak-to-peak jitter
- JITTER RMS     : root-mean-square of the time interval between updates

Conclusion for now:
- No errors observed in the ~1h this was running
- No jitter on IPCs
- epics read has a faster update rate (~8Hz) than epics write (~2Hz)
- as a result the delay is shorter for epics read
- the jitter MAX-MIN is about 40msec for EPICS access - the RMS jitter is about 4msec

I turned on recording for all the fast return channels over the weekend.

The modifications to h1ascimc and h1odcmaster will be backed out on Monday.