Experimental Physics and
Industrial Control System

"Pearson, MR \(Matthew\)" <[email protected]> · Fri, 12 Oct 2007 11:08:39 +0100

Hi,

I had some similar results with a Pulnix TMC-1405GE camera (colour,
1392*1040, Gigabit ethernet connector). That also comes with a custom
windows network stack, which dramatically improves performance.

The Pulnix sends packets over UDP to the client (which is a windows
application from Pulnix). UDP is ideal for video network transmission,
since normally it doesn't matter if the occasional packet is lost. Using
UDP instead of TCP increases frame rates by about 50%, since there is no
TCP protocol overhead.

This is with no compression in use (since we are talking diagnostic
cameras). 

The ideal situation would be to do any video processing on the server
side (either the camera itself, or a server gateway which the camera is
connected to). Then do compression before sending data over the network
for visualisation purposes. Any real-time code would be run on the
server side.

Also, note that 1394b also supports fiber optic links. There are now
cameras and PCI cards on the market for this (like the AVT Pike camera,
which has both copper and optical connector). Then optical cables
lengths for 1394b cameras can be up to several hundred meters.

Cheers,
Matthew 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Mark Rivers
Sent: 11 October 2007 22:35
To: Kate Feng
Cc: [email protected]; Daron Chabot; [email protected]
Subject: RE: firewire video on RTEMS-4.6.x-MVME5500

I just did a quantitative data throughput measurement.

The time to capture 368 frames at 1360x1024 resolution was 12.216
seconds.  This is 33.2 msec /frame.

The total amount of data is thus 512 MB, for a data rate of 42MB/second.

The data have a time stamp with each frame with msec precision, and the
mean time between frames was 33msec seconds, with a maximum of 34 msec
and minimum of 32 msec.  So it truly is 30 frames/second at this
resolution.

At 680x512 resolution the measured throughput was 52 frames/second.

This was done with a dedicated Ethernet connection to the camera.

Mark

________________________________

From: Mark Rivers
Sent: Thu 10/11/2007 2:15 PM
To: 'Kate Feng'
Cc: 'Daron Chabot'; '[email protected]'; '[email protected]'
Subject: RE: firewire video on RTEMS-4.6.x-MVME5500

> Thus, the display rate you see is not necessary 334 Mbits/sec.  The 
> eyes can not tell.  No one knows exactly how fast the display rate is 
> if there is  no 3rd party monitor software to verify.

The application DOES give the actual frame update rate, and it is 30Hz
+- 1Hz, so I do know the actual value.  You had previously asked if I
had a reading of the network bandwidth, which I do not have.

Mark

________________________________

	From: Kate Feng [mailto:[email protected]] 
	Sent: Thursday, October 11, 2007 12:58 PM
	To: Mark Rivers
	Cc: Daron Chabot; [email protected]; [email protected]
	Subject: Re: firewire video on RTEMS-4.6.x-MVME5500

	Mark Rivers wrote:

			Does the camera come with it's own display ?  Or
do you use EPICS CA for
			display ?  If the real data throughput to the
EPICS display is 334 Mbits/sec,
			you should see 42 Mega Bytes/sec of high traffic
using the Window network
			perfromace monitor.  

		There is no EPICS involved with this.  It is using the
manufacturers display program.

			What's the protocol the camera use for
tranferring the data to the host PC ?
			I thought it's the GigE network.  

		It is TCP/IP over Ethernet.

			If so, you should see at least 334 Mbits/sec
			data throughput on the window network
performance monitor.  Something
			does not make sense to me.

		The reason that the Windows network performance monitor
does not see this traffic is that the camera manufacturer provide their
own Ethernet driver for Windows.  This driver grabs all camera packets
before Windows sees them, and sends them straight to the camera
application.  This is a technique used by most GigE cameras, it greatly
reduces the CPU load.  It is restricted to a subset of available GigE
Ethernet chip sets, but seems to support all of the ones (Intel, etc.)
that I have run into.

	Thus, the display rate you see is not necessary 334 Mbits/sec.
The eyes
	can not tell.  No one knows exactly how fast the display rate is
if
	there is  no 3rd party monitor software to verify.

	Kate

		Mark

		________________________________

		From: Kate Feng [mailto:[email protected]]
		Sent: Thu 10/11/2007 8:26 AM
		To: Mark Rivers
		Cc: Daron Chabot; [email protected];
[email protected]
		Subject: Re: firewire video on RTEMS-4.6.x-MVME5500

		Mark Rivers wrote:

			> Does the window has any tool to measure the
actual
			> network throughput of the  1GHz ?  Or do you
have any
			> H/W tool to measure it ?  If so, how many Mega
bytes/sec
			> of throughput ?

			I don't see a tool in their software to measure
the network throughput.  I can do a simple calculation for the full
frame size at 30 FPS 8-bit mode:

			 1360.*1024.*30.*8 = 334 Mbits/second.

			This is the real data throughput to the display,
and does not include any protocol overhead.

			The Norpix software includes a replacement
Ethernet driver on Windows which looks at all frames before the Windows
network stack gets them.  The camera frames go directly to the camera
application, and only other frames are passed to the Windows network
stack.  So using the Window network perfomance monitor shows virtually
no traffic at all.

		Does the camera come with it's own display ?  Or do you
use EPICS CA for
		display ?  If the real data throughput to the EPICS
display is 334 Mbits/sec,
		you should see 42 Mega Bytes/sec of high traffic using
the Window network
		perfromace monitor.  If it shows no traffic at all, then
the display could be
		only 1 frame/second (e.g. 11 Mbits/sec) while the data
transfer is 334 Mbits/sec.

		What's the protocol the camera use for tranferring the
data to the host PC ?
		I thought it's the GigE network.  If so, you should see
at least 334 Mbits/sec
		data throughput on the window network performance
monitor.  Something
		does not make sense to me.

		Kate

			> Can the window run remote client ?

			I don't think so.  But there is a development
library to write your own client.

			Mark

		________________________________

				From: Kate Feng [mailto:[email protected]] 
				Sent: Wednesday, October 10, 2007 12:43
PM
				To: Mark Rivers
				Cc: Daron Chabot; [email protected];
[email protected]
				Subject: Re: firewire video on
RTEMS-4.6.x-MVME5500

				Mark Rivers wrote:

					I recently got a GigE camera
from Prosilica.  It is 1360x1024 resolution.  At 8-bits the StreamPix
software from Norpix is able to acheive frame rates of 30Hz at full
resolution, and 52 Hz when it is 2x2 binned to 680x512.  This is under
Windows, using the single GigE port on the PC, with the camera and PC
connected directly to a GigE switch (which also is connected to the rest
of the LAN).

				Does the window has any tool to measure
the actual
				network throughput of the  1GHz ?  Or do
you have any
				H/W tool to measure it ?  If so, how
many Mega bytes/sec
				of throughput ?

				Can the window run remote client ?

				Regards,
				Kate

					Mark

		________________________________

						From:
[email protected] [mailto:[email protected]] On
Behalf Of Kate Feng
						Sent: Wednesday, October
10, 2007 10:17 AM
						To: Daron Chabot;
[email protected]; [email protected]
						Subject: Re: firewire
video on RTEMS-4.6.x-MVME5500

						Daron Chabot wrote:

							Sorry for not
being more clear: I am only interested in the EPICS and EDM applications
you've created for displaying the video, not in any of the RTEMS-related
code.

						I did not change any EDM
applications or EPICS base.  The protocol
						is CA.   The
optimization is implemented at RTEMS device driver
						and IIDC1394 library
layers. The BSP is RTEMS-MVME5500.
						The driver does not have
to be linked to EPICS.
						It is just another
real-time application with the RTEMS-MVME5500
						BSP.  It triggers the
camera at 30 fps and  display at 30Hz
						simultaneously for the
1024x768x8bit mode (video mode) even under the
						limited 100MHz network
bandwidth and indeterministic network environment. 
						Yes,  in the 100MHz NIC,
the actual network throughput is not 
						30Hzx1024x768x8 bits.
But it is greater than 10Hz.  Thus, the system does
						not have to run in a
private network. I do not believe it
						will  be slower with a
non-EPICS application.  

							Here at the CLS
we're using linux-based soft IOCs to communicate with Flea and Flea2
cameras.

							We're having
difficulty in achieving video frame rates greater than about 10 Hz at
640x480 resolution. I'm interested to know how you are getting such fine
performance (aside from using RTEMS :-) ).

						Perhaps I will have the
optimization written in a publication, so that
						hopefully it can help
the Linux or vxWorks users.  If so,  will you
						feedback to this list
regarding how much improvement you achieved
						in the Linux driver ?

						Regards,
						Kate

<DIV><FONT size="1" color="gray">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
</FONT></DIV> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System