Choosing the best GigE Vision-based camera requires analyzing a number of different driver options
Since the GigE Vision standard was ratified by the Automated Imaging Association (AIA) in May 2006, a number of camera vendors have taken advantage of the camera interface. These companies now offer a plethora of products ranging from linescan and area-array to TDI-based cameras that use the standard to allow 1000-Mbit/s image transfer with low-cost cables over lengths up to 100 m (see “2007 Worldwide Industrial Camera Directory,” Vision Systems Design, November 2007, p. D21–D67).
Despite these benefits, choosing a GigE Vision-based camera requires more than analyzing the technical specifications of each camera. While the type of imager used, data-capture rate, triggering capability, and software support are important factors in choosing any type of camera, the implementation of the GigE Vision standard requires system developers and end users alike to properly evaluate the types of drivers offered by each camera vendor.
Different drivers
“GigE Vision cameras require efficient GigE drivers to transport the gigabit data and receive it reliably,” says Matthew Hori, director of marketing at GEViCAM. “To do so, each camera vendor provides its own drivers besides the Windows stack drivers. While Windows stack drivers work for the majority of applications, their performance and CPU load requirements are not particularly suited to demanding applications, and dedicated drivers must be installed under the original Windows stack drivers.”
“GigE Vision software-development kits (SDKs) offer three options for accessing a Gigabit network interface card (NIC): using the native Windows stack, using a GigE Vision Stream Protocol (GVSP) filter driver installed on top of the regular NIC driver, and using a specialized driver for Intel PRO/1000 cards,” says Boris Nalibotski, president of A&B Software. “And different companies use different terminologies for these options,” he adds. Only Pleora Technologies supports all three options, which is one of the reasons why many camera vendors, such as DALSA, GEViCAM, Imperx, JAI, and Toshiba Teli, have used the company’s hardware and software products in their range of GigE Vision cameras (see Vision Systems Design, April 2006, p. 65).
“Since GEViCAM GigE cameras use the Pleora GigE core,” says Hori, “we use the drivers supplied by Pleora.” Pleora’s SDK contains drivers that include the Windows stack driver, eBus universal driver, eBus optimal driver that uses the Intel chipset, and the company’s iPort high-performance driver that also uses the Intel chipset. While the universal driver runs on almost any vendor’s NIC and handles all IP transport protocols including network traffic, as well as GigE Vision and iPORT transport protocols, the eBUS optimal driver runs on Intel’s PRO/1000 family of NICs and 825xx ICs and handles all IP transport protocols including network traffic, GigE Vision, and iPORT transport protocols.
In operation, the eBUS core instantly identifies the high-level transport protocol in the packet header of incoming data. If data are headed by a lower-performance protocol, such as Transmission Control Protocol (TCP), eBUS sends it to the Windows IP stack for processing. If the data are headed by a performance-oriented protocol, such as GVSP, eBUS switches to the associated functional device objects (FDOs)—software modules of the eBus core—that process the packets for a specific IP transport protocol. “While the eBus optimal driver and high-performance drivers offer the best performance,” says Hori, “they must be installed with Intel’s GigE PHY chipset. However, the universal driver and Windows stack work with any GigE adapter cards.”
While Pleora offers drivers that support all three options, other companies have taken a more conservative approach in their development of device drivers. For example, although it doesn’t currently offer a GigE Vision-based camera, National Instruments (NI) offers two versions of GigE Vision drivers for its NI-IMAQdx driver included with its Vision Acquisition Software. “These include a universal driver that supports the native Windows stack and a high-performance hardware-specific driver that was developed to circumvent the overhead within the Windows Network Driver Stack,” says Johann Scholtz, senior software engineer with NI.
Since the universal driver must use the intermediate driver and the protocol driver to communicate with the hardware-specific miniport driver, it requires greater CPU processing overhead (see Fig. 1). To overcome this limitation, the high-performance driver bypasses the TCP/IP driver and optional intermediate driver communicating directly with NI’s miniport driver that replaces the Intel miniport driver. “Since the intermediate driver is an optional part of Microsoft’s Network Device Interface Specification that is designed to monitor and perhaps filter data from the miniport driver, it can be effectively bypassed for GVSP traffic,” says Scholtz. “And by parsing the GVSP packets in the NI miniport driver, the TCP/IP protocol can be bypassed.”
Especially developed to support Intel’s PRO/1000 chipset, NI’s driver offers better performance than the universal driver and monitors both TCP and UPD packets, both traditional network and GVSP packets. “Should the driver detect a GVSP packet,” says Scholtz, “then image data can bypass the Windows stack, resulting in a higher throughput. Should non-GVSP network data be detected, then the traditional Windows stack can be used to process the data.”
More performance
Basler Vision Technologies finds no reason to support the native Windows stack. The company’s “pylon” driver package contains two drivers. But Basler has taken a different approach, choosing to avoid native Windows stack support and offering two different GigE Vision drivers—a GigE Vision filter driver and a GigE Vision performance driver.
“While the filter driver is located below the Windows IP stack and can be used with all NICs, the CPU load associated with this driver is generally attributable to the fact that packets must normally be copied at least twice,” explains Werner Bochert, Basler product manager. The advantage of the performance driver is a significantly lower CPU load. This performance driver is a hardware-specific GigE Vision network driver compatible with NICs that use specific Intel chipsets. Using the C++ API of Basler’s driver package, system developers can select a driver that best fits their application requirements.
Due to the different architectures of the drivers and to different hardware platforms, the CPU load of the filter and performance driver that runs on Intel’s PRO/1000 family of NICs varies. Other parameters that contribute to performance include the network topology, packet size of the data transfer stream, and the system bandwidth. Both the filter driver and performance driver affect the CPU differently (see Fig. 2). In tests performed on a dual-core Pentium running at 2.8 GHz and an Intel PRO/1000GT network card with the pylon SDK installed, the effects of using the performance driver and filter driver with different packet sizes can be clearly seen. Tests were performed using a Basler piA640-210gm camera.
Prosilica also offers two types of GigE driver for its range of cameras. But the company has chosen to support the native Windows stack with its GigE Vision driver and to offer an optional GigE filter driver to reduce the CPU load on the host.
A&B Software has decided not to develop a specialized driver for the Intel card in the initial release of its Active GigE SDK. “We performed tests with third-party SDKs and found that the real jump in performance (CPU load) happens when a filter driver is installed over the native NIC driver,” says Nalibotski. “This cuts the CPU load in half compared with the native Windows stack driver.
“However, when you compare the difference between using a filter driver and a specialized hardware-specific driver, the specialized hardware driver only reduces the CPU load by roughly between 10% and 15%. This does not appear to be a significant gain as it ties you to Intel PRO/1000 adapters,” he says. A&B has performed comparisons using a 640 × 480 × 100-frame/s camera that uses packet sizes of 8000 bytes (see table).
Eric Carey, manager of the smart-camera product line at DALSA and acting chairman of the AIA’s GigE Vision Committee, agrees. For this reason, DALSA’s Genie camera Framework offers a GigE Vision driver suitable to any standard NIC card. “With the power of hyperthreading and multicore processors, the slight improvement in CPU usage is rarely a factor. It is also difficult to compare CPU load from Windows Task Manager. A more suitable test is to benchmark some image-processing function without image acquisition and compare that with the same function performed during acquisition. Such tests highlight the additional burden put on memory. This more accurately depicts a real word machine-vision system,” he says.
null
