(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.