Re: [APS Beamline_controls] EPICS support for 2-D detectors/cameras

[Kate Feng <feng1@bnl.gov>]

l.lurio wrote:

Hi,

I think it would be nice to have the ability to transfer images through
epics, but I don't think it is a good idea to make this the sole means to
save images.  For a really fast system you probably want to write directly
to a local RAID array using a dedicated controller.  I think this could be
at least 10 x's faster than the 20 Mbytes/s you list.

Yes,  I agree with you.  We are using a dediacted FibreChannel controller
for data storage, which is mentioned in the same paper I talked about in the
previous E-mail.
http://accelconf.web.cern.ch/accelconf/ica07/PAPERS/WPPB12.PDF

Thanks,
Kate

Larry

Laurence Lurio
Associate Professor
Department of Physics
Northern Illinois University
Phone: 815 753-6492
Cell:     815 260-4900
Email: llurio@niu.edu

-----Original Message-----
From: beamline_controls-bounces@mailman.aps.anl.gov
[mailto:beamline_controls-bounces@mailman.aps.anl.gov] On Behalf Of Kate
Feng
Sent: Tuesday, March 11, 2008 1:56 PM
To: tieman
Cc: beamline_controls@aps.anl.gov; tech-talk@aps.anl.gov
Subject: Re: [APS Beamline_controls] EPICS support for 2-D detectors/cameras

tieman wrote:

  

I've thought about the standard EPICS IOC route.  The Image Server was 
always an application first and a PV server second.  I still believe 
there is value in that philosophy but can see the value in going 
standard EPICS.
I don't see a danger in sticking with the Portable Channel Access 
Server.  There's enough code reliant on it now that I don't see it 
going away.  It does not suffer from the 16K barrier if built to avoid 
it but I generally disagree with EPICS as a means to move image data.  
I've already done a small amount of preliminary work in developing a 
new code base using the PCAS but it's nothing that can't be thrown away.

    

It is always a good idea to constantly seek improvement on EPICS.
However, I am not unhappy about its CA performance so far.  Sometimes,
its perfromance is coupled with the hardware, software and PC that
is used in your system.

In Nov. 2007, I was able to "display real-time image"  at an average
of  20 Mbytes/sec (a max. of 22 Mbytes/sec) while the camera
was transferring the image data at 28 Mbytes/sec to the system
memory via the 1GHz network. The performance is up by 33 % since
the paper was published in ICALEPCS07 conference, which was held
in Oct..  See
http://accelconf.web.cern.ch/accelconf/ica07/PAPERS/WPPB12.PDF
The system configuration is mvme5500/firewire/Linux PC.
The better news is that I do not think I hit the bottleneck yet.
1) I could still improve the mvme5500 BSP that I wrote to have higher 
performance.
2)  The perfromance is estimated to be at least twice higher with the
mvme6100 support  in the "disco" BSP, which I derived
from the mvme5500 BSP that I wrote.  "disoc" BSP supports the discovery
based board such as mvme5500 and mvme6100.

However, the analysis of 1) and 2) is not a high priority task to me 
presently.
Only the sky is the limit.

Cheers,
Kate






_______________________________________________
APS Beamline_controls mailing list
post: Beamline_controls@mailman.aps.anl.gov
request: Beamline_controls-owner@mailman.aps.anl.gov
http://www.aps.anl.gov/mailman/listinfo/beamline_controls