Setting up Link Aggregation for NI-IMAQdx

[pfigliozzi]

I have a GigE camera that has two ethernet inputs and I would like to use both of them to send image data to my computer. I wish to aggregate (or team) two of the ethernet ports on my computer so that I can get twice the bandwidth between my camera and my computer. I have an Intel PRO /1000 PT Dual Port Server Adapter installed in the PCI slot of my computer. With the Intel drivers that came with the card, I am able to combine the two ports on ethernet controller but this makes it so the camera doesn't work in MAX. If I install the NI GigE Vision Drivers for my ethernet controller I can get it to work in MAX but I cannot get the maximum performance from it because I cannot aggregate the two ports. Does anyone know how to do port aggregation using the NI GigE Vision Network Drivers?

[toto26]

Maybe you can try to follow the procedure descibed in the manual from SVS Vistek HR cameras wich are dual port.

You will find it on their website: http://www.svs-vistek.com/_products/cameras/svcam/hr/hr.php. Then donwload the pdf Manual_SVCam_HR_GE.pdf and go to page 86.

Hope this helps

Regards

[BlueCheese]

Currently the High Performance GigE Vision drivers do not have the internal ability to support link aggregation. This is something that may come in a future version. However, because link aggregation is basicially transparent to the network stack, IMAQdx natively does support link aggregation if you use Intel's drivers instead. You should be able to diagnose why your cameras weren't working with Intel's drivers. Generally it is due to using jumbo frames when they are not enabled (>1500 byte packets) or having the Windows firewall enabled. Both of these issues are transparently handled automatically if you are using the NI drivers, but must be manually configured when using another vendor's drivers.

Eric

[pfigliozzi]

So it turns out Windows Firewall was the issue. The camera now shows video in MAX at the camera's maximum framerate (63fps) but there are horizontal black lines appearing across the image. Under Ethernet Attributes it is dropping packets. The camera is an AVT Prosilica GX1910 and it is strange because it works fine with the GigE Sample Viewer provided by AVT but it has this packet loss issue in MAX. I have read elsewhere that not having Jumbo Frames enabled could affect this but each of my teamed network ports are set to 9014 bytes for Jumbo Frames. Any other suggestions to fix this problem? Thanks for the help.

[Chartreuse]

Hi,

I am having exactly the same problem with my AVT camera : I am using the Intel PRO/1000 PT Dual Port card with aggregate ports, and there are lots of missing packets with MAX and LabView. Everything works fine with the AVT software and jumbo frame is also set to 9kB. Has anybody managed to get LabView to work properly with the Intel driver?

Thanks for your help!

[toto26]

Hello,

I would say, check your cables, because it's often a cause of bad transmission. Be sure to use Cat5E cables at least.

Try to see the inter packet delay also.

Regards

[Chartreuse]

Hi,

thanks for your reply. I'm pretty sure it's not the cables since I don't have any packets missing when using the AVT software, without any hardware/driver modification. Also, when I switch to the NI driver, the images with labview are ok - the only issue is that I can't aggregate the ports with the NI driver, so I am stuck to 1Gb/s transmission rate.

It really looks like there is a compatibility issue between the Intel driver and MAX/LabView. Any hints on how to solve this?

Thanks!

[BlueCheese]

Hi,

One difference is that I believe AVT's software uses a filter driver for reading the packets. IMAQdx uses either the high-performance driver or goes through the network stack. When not using the high-performance driver it is hard for the OS to deliver all the packets through the stack without dropping any. We are continuing to look at future options to better support link-aggregation within IMAQdx for the few cameras on the market that support it, but it is a known issue that performance is not spectacular when using link-aggregation today with IMAQdx.

For workarounds, one think you might be able to do is switch the camera to an 8-bit rather than 12-bit mode (assuming you don't need the bit depth). This can cut the data rate in half. Another option is you could adjust the bandwidth controls on the camera to throttle the peak data rate a little. In general, GigE cameras "burst" their data after every frame to minimize latency. You can often cut the rate of this burst without affecting the overall framerate at all, it just means the latency for each image is a little higher. This reduction in peak data rate can help quite a bit on packet loss. AVT has several bandwidth control mechanisms in place that should be well documented.

Eric

[Chartreuse]

Hi,

thanks for your reply, it totally explains the problems I've been having. It's a shame I can't use port aggregation with IMAQdx, but it's great at least that I don't have to spend more time trying to fix this missing packets problem. I hope there will soon be a IMAQdx driver that can handle the port aggregation, that would be really useful!

Thanks again for your help

[pfigliozzi]

For the record, I have gotten link aggregation for my GigE camera to work. Here's what I did:

1. Followed the instructions from my camera manufacturer (AVT) for setting up link aggregation (Intel calls it Teaming) and setting up jumbo frames. The instructions that I used can be found here. Also, make sure you have the latest drivers for your ethernet card (mine is a Intel Pro 1000/ PT Dual Port Server Adapter)

2. Went to Measurement and Automation Explorer and changed a few settings under Camera Attributes. First, the camera did not work for me until I turned on Acquisition Attributes->Advanced Ethernet->Firewall Traversal->Enabled. This allows the camera to bypass Windows Firewall. Second, I set Camera Attributes->GigE->StreamBytesPerSecond to 248000000.

After this I was able to get framerates not possible with just one ethernet cable connected. It has been years since I have tried working on this issue so I don't know what has changed so that did not run into the same problems I had the first time I posted. One big difference is I am using the latest Intel drivers from March 2013, perhaps this was the original issue all along?