NI VBAI GigE Camera Lost Packets

Question

We are running VBAI on a fast PC through an Intel Pro/1000 card and a jumbo-frame GigE switch to a large number of Basler Ace GigE cameras.
It is understandable that multiple cameras can not simultaneously transfer complete images to the PC at the full 1000 MHz data rate due to the limited bandwith between the PC and switch.
One way around this is to throttle the max data rate for each camera down so that the sum is not greater than 1000 MHz.
However, this means that image transfers always take longer, even if only one camera happens to be in operation much of the time.
Is this a fundamental limitation of GigE Vision, or are GigE Vision cameras clever enough to operate as fast as possible...via resends of the occasional lost packet??? 
     Nelson

Answer 1

We have come up with a solution.
The issue is that the cameras, switch, network card, and VisionBuiilder cannot handle any instance where more than one camera is sending images to VisionBuilder where the total of the data rates for those cameras is ever in excess of the 1GB network card bandwidth.
(It would be nice if someone made a network switch that has slightly more packet buffer memeory...100MB?...so that the occasional collision does not result in garbage images while allowing most captures to operate at maximum speed.)
Solution:
(1) We added 3 additional 1Gb network ports to our vison pc.
(2) In order to redistribute camera traffic to more than one network port, we assigned each network card, and the corresponding cameras, to a different subnet.
(3) We lowered the data rate for the less time-critical cameras.
Even after lowering the data rates for several cameras in NI-MAX down to 200 Mb/s such that lost packets should no longer be possible, we stil saw them.
After a detailed examination we found that the VisionBuilder image acquisition steps do not pay attention the the data rates that you assign in NI-MAX, and alwasy default to the maximum 1000 Mb/s rate, hence the saturated data rates and lost packets.
The solution to this problem turns out to be to explicity set the desired data rate in each VisionBuilder Image Acquistion step, using the attributes tab.  While you are at it, you should also check that other critical parameters, such as the packet size, are also correct, and update them if not.
After explicitly correcting the data rates in all image acquisition steps, we ran an image capture stress test that ran all the vision processes (several programs running simultaneously) about 10x faster than required, and observed no lost packets at all.
Problem solved.