Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Wed, 1 Sep 2010 10:51:58 -0500

areaDetector plugins run in their own thread if the BlockingCallbacks PV
is set to "No".  Thus, they should run in their own core on a multi-core
system.

However, there is something that the plugin author needs to be aware of.
The processCallbacks() function in the callback code is called with the
asynPortDriver mutex locked.  The processCallbacks() function must call
this->unlock() before it begins computationally intensive code, during
which time it should not access any class variables or call any class
methods except this->lock().  If the plugin does not call this->unlock()
then drivers will not be able to place any additional arrays on the
plugin queue, and the system will be essentially single-threaded,
because the driver will block waiting for the plugin to execute.  

I wonder if the mjpeg plugin has this problem?

Mark

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, September 01, 2010 10:38 AM
To: [email protected]; [email protected]
Subject: RE: areaDetector video (Was: network video)

Lewis,

No, the software is multithreaded. The images I mentioned were black and
white and if you switch to colour compression (which is more expensive)
the CPU load goes up to around 220% at times.

This is all implemented as an areaDetector plugin in a single IOC. I
don't know what would happen if you tried to use two IOC's on one host,
but I suspect the gains would be minimal. Clearly, if you used a second
host system you would get a doubling of everything.

As I understand it the frames are lost before they leave the Prosilica
driver. The GigE standard is real-time UDP and since we have multiple
independent data sources with no bandwidth allocation I think if you
looked carefully you would see data bits all over the floor. I feel
having the system die reasonably gracefully when the incoming Ethernet
pipe chokes is the best we can do - even if the choke point is
significantly less than the full theoretical bandwidth.

Cheers,

Nick

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of J. Lewis Muir
Sent: 01 September 2010 15:33
To: EPICS Tech-Talk
Subject: Re: areaDetector video (Was: network video)

On 9/1/10 7:14 AM, [email protected] wrote:
> As a guide, on an Intel X5260 processor (Dell 2950) with 3 1024x768
Mono
> cameras @ 30fps uses 30% of 1 core for acquisition and another 35-40%
> for compression. The compressed stream is about 10% of the
uncompressed
> stream. However, despite the data from the three cameras only being
> 70Mbytes/sec, only one core being utilised so another core is idle,
and
> it being a fully switched network, if you add another camera then
frames
> start being dropped. So, as they say, your mileage may vary.

Hi, Nick.

If only one core is being utilized, perhaps the software isn't written
to take advantage of the other core.  In this case, the behavior you
observed doesn't seem so surprising: 30% + 40% = 70%. 70% / 3 = 23% per
camera.  One might then anticipate that adding another camera would run
the CPU usage up to 70% + 23% = 93% which might be high enough to cause
frames to get dropped.

Is there a way to run more than one instance of your software?  When
software isn't written to take advantage of more than one core, you can
sometimes overcome this if you can run more than one instance of the
software; the operating system will take care of scheduling the second,
third, etc. software process on other cores.

Lewis

-- 
This e-mail and any attachments may contain confidential, copyright and
or privileged material, and are for the use of the intended addressee
only. If you are not the intended addressee or an authorised recipient
of the addressee please notify us of receipt by returning the e-mail and
do not use, copy, retain, distribute or disclose the information in or
attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual
and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any
attachments are free from viruses and we cannot accept liability for any
damage which you may sustain as a result of software viruses which may
be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in
England and Wales with its registered office at Diamond House, Harwell
Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System