CPU overload with gige basler cameras

[da.martinez]

Hi guys,   I have 20 cameras Basler model N° scA640-70gc setup at 30fps for an exact process of patron identification and I use a server HP ProLiant ML350p Gen8, windows server 2012, 2 Processers Intel® Xeon®  Six-Core E5-2620v2 of  2.1 GHz, configured with 6 networks interface cards as a team giving 6 Gb of banwidth enough to support all of this data.

The problem is that I did a vi to grab simultaneously the 20 cameras and to process te patron identification, I used timed loop structure to give two cameras per core, setting the period on 30ms for the 30fps and reducing the priority to avoid to overload the CPU ussage.

But despite the cameras are using each precesser selected, ever the CPU 0 is overloading and I don't understand why does it happen??

I did other vi to only do grab with vission adquisition assitant in 4 cameras and I try to put all the cameras in the same processer different obviously to CPU 0 and with different processer too but I ever have the same result.

Windows performance monitors show that CPU usage is less than 6%, and network usage is less than 5%

Help please!!

[MoviJOHN]

Don't use the timed loops.

If you have teamed up the NICs (binding is the term I'm familiar with), it is very likely that you are not going to benefit fully from having the NICs in there, since GigE Vision on such a configuration is probably too exotic to be supported.

Try instead to alocate four cameras to each NIC, and configure the Jumbo packet size limit for each camera to be 2000, or less.  Put each camera in its own while loop.  Better yet, create a sub vi that is capable of operating a single camera standalone, but that can take in its configuration parameters at runtime, or via messaging (named queues).  Then you can drop multiple instance of the vi into your main block diagram, and establish just how each new instance impacts performance.

A 640 x 480 camera should not have much trouble with a reduced jumbo packet size, but you might be limited by the PCI/PCIe bus bandwidth, with that many cameras.

[MoviJOHN]

...Also, don't use the Express VI capture.  There is no need to have all of the overhead of the functions there (show front panel, to look inside).  Just put the grab in the loop.

[da.martinez]

Dear Jhon.

Thank you very much for your assistance, but I can get a better performance with your recommendations.

I follow all your steps, firstly I set up a one NIC with gige vision driver directly connected to one cam as you see in the picture below (this NIC is not part of the team), the packet size in jumbo frames is 1500 and the cam have status ok en IP configuration of pylon software from Basler cameras.

After that, I looked the usage of CPU using pylon software and it uses CPU 0 but it is not a critical use with one cam... but I did the same probe with MAX and it almost double the use of CPU 0 with the same configuration as pylon viewer.

Then, I did your software recommendation on the software comparing the timed loop with while loop but it is not much different.

Obviously all of the work is with one camera but I am sure that if I put all cameras I would reach the limit and overload the CPU 0.

Also, I looked the affinity of processor with labview and it is OK.

Really I do not what more to do, I am concerning about that.

I hope you have oter solution man.

Thank you very much.

[da.martinez]

These are the other pictures...

[MoviJOHN]

You misunderstood.  The NIC Jumbo packet size should be set to the highest possible value, since you are bringing in multiple cameras on it.  The cameras Jumbo packet size is what needs to be adjusted down.  This can be done in measurement automation explorer.

Also, acquiring in MAX is not the same as Acquiring in LV, so I would not read too much into that.