I recently read an interesting post by B. Grey entitled “Can GigE be trusted?”. The central theme of the discussion is around the reliability of GigE in the transfer of images. I thought I’d add my 2 cents here.
First, why can’t we find any information about GigE cameras dropping frames? I see two possibilities: Either MV companies want to hide what must be a devastating problem, or more simply because it’s not an issue. Since I don’t subscribe to conspiracy theories, let’s walk through some catastrophic scenarios where a GigE Vision camera might lose a frame.
It all starts with image acquisition. An easy way to lose a frame of course, is not to capture one in the first place. Steve Maves correctly points to where this in fact happens: over-triggering the camera. The way to deal with too many triggers is manufacturer-specific: it can simply be ignored (with or without an error message) or it can be buffered to be executed as soon as possible after the current frame. Unfortunately, you need to read the fine print in the camera user manual to learn how it is implemented since this is not part of the standard.
So let’s assume the image was captured by the camera: what else can go wrong? There are a few situations where a camera might be forced to drop a frame before transmission on the gigabit link.
- First, if a link is too slow to support the acquisition bandwidth (let’s say you connected your GigE camera on a 100 Mbps Fast Ethernet port), then the camera will likely need to drop a few frames to throttle acquisition bandwidth to match the transmission bandwidth. A similar situation can happen if too many cameras are connected, through Ethernet switch, to a single Ethernet port of the NIC. These are system design issues.
- There is one more situation where a GigE camera might not send all the captured images to the PC. This has to do with a race condition between the trigger and the stop of an acquisition. Let’s assume that the camera has some on-board buffers (most GigE cameras do). The system starts a triggered acquisition and the camera starts an exposure each time it receives a trigger. But what happens if the PC sends an early StopAcquisition command after a valid trigger sequence has been initiated, but before the image was transferred? Well, once again, it depends on the camera vendor implementation. Some vendors might decide to stop any pending transfers to the PC and the image being exposed will be trashed. In this case, the number of received images at the PC will not match the number of triggers. But again, this is a special case and a well designed application would deal with such a scenario in a more elegant manner.
At this point, we can consider all captured images have been transmitted by the camera. So what can else go wrong? We all know Windows and Linux are not real-time operating systems. This is why you should not expect real-time acquisition without using GigE Vision software designed to minimize CPU usage. A good counter example is using the socket API (hence the Windows communication stack) to capture GigE images in real-time. It might work up to a point where either the transmission bandwidth will consume too much CPU or other pieces of software running on the PC will block the Windows thread responsible for image acquisition. This is why the GigE software vendors have invested in creating so called High Performance and Filter drivers. These special drivers run at the kernel level and thus have higher priority than most of the other threads scheduled by the operating system. This leaves them plenty of time to process incoming packets and copy them to the image buffers. But even such optimized drivers might be limited by other ill-behaved kernel drivers consuming CPU bandwidth for too long and preventing them to run for extended period of time (remember we’re talking about milliseconds here). In these theoretical situations, the optimized driver risks losing precious packets and might not even have the time to ask for packet resends. But I have yet to see such a situation.
Even if the GigE driver was able to receive all images and put them in the image buffers, the final part is the application software not being able to process that data fast enough. The number of host buffers is limited, and at some point there might be no more available to accommodate the next image. In that situation, the GigE driver will have to discard an image (by the way, same would be true for a frame grabber based application). Again, this should be taken care of in the system design.
I am sure there are a few other scenarios where an image could be dropped. My experience tells me there is always a way to get around the problem in a well designed MV system. This explains why you cannot find articles discussing GigE dropping frames. Well, until today that is!