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.
Larry
Laurence Lurio
Associate Professor
Department of Physics
Northern Illinois University
Phone: 815 753-6492
Cell: 815 260-4900
Email: [email protected]
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Kate
Feng
Sent: Tuesday, March 11, 2008 1:56 PM
To: tieman
Cc: [email protected]; [email protected]
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: [email protected]
request: [email protected]
http://www.aps.anl.gov/mailman/listinfo/beamline_controls
- Replies:
- Re: [APS Beamline_controls] EPICS support for 2-D detectors/cameras Kate Feng
- RE: [APS Beamline_controls] EPICS support for 2-D detectors/cameras Mark Rivers
- References:
- EPICS support for 2-D detectors/cameras Mark Rivers
- Re: EPICS support for 2-D detectors/cameras tieman
- Re: EPICS support for 2-D detectors/cameras Kate Feng
- Navigate by Date:
- Prev:
Re: Problem with gateway Dehong Zhang
- Next:
Re: [APS Beamline_controls] EPICS support for 2-D detectors/cameras Kate Feng
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS support for 2-D detectors/cameras Kate Feng
- Next:
Re: [APS Beamline_controls] EPICS support for 2-D detectors/cameras Kate Feng
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|