We are troubleshooting some problems using Etherpeek to examine packets that have been captured on a switch and we are seeing several F flags which we have not seen before. If we knew how the software knows that packets have been dropped, it might give us clues about the problem we are trying to troubleshoot.

I know that Etherpeek has been discontinued, but we suspect that Omnipeek uses the same basic approach. How does the software determine that previous packets have been dropped?

Obviously, a simple gap in packet IDs cannot be an indicator of dropped packets -- that's a common occurrance. So, what can happen to cause the software to know that packets have been dropped? Is this a case that a packet was so corrupted that it could not be decoded? Does it mean that input was so heavy that the input queue overflowed causing packets to be lost before they could be processed? Or what?

By driver, I assume that you mean the driver for the interface on the capture machine? If so, then I assume that this means that there was more data arriving at the interface than the driver was able to hand over to the applications software -- in other words, it's basically an indication of an input buffer overflow at the interface. Have I got that basically right?

Sorry for the series of dumb questions -- I'm just trying to understand the significance of what we are seeing. It's important to me to diferentiate between a simple overload of the capture machine and indications of packet corruption.

Thanks.

Larry

[quote="Spacepacket"]OmniPeek periodically asks the driver how many packets have been dropped.

You are right on Larry. If capture performance is the highest priority, start turning off analysis options during capture, capture the packets, and do the actual analysis post capture. The Expert in particular is a major consumer of CPU cycles, resulting in dropped packets.

Thanks. We have the analysis stuff turned off, but we are using rather old processors that don't have a lot of memory, so I think they are just not keeping up.

Thanks.

Larry

[quote="Spacepacket"]You are right on Larry. If capture performance is the highest priority, start turning off analysis options during capture, capture the packets, and do the actual analysis post capture. The Expert in particular is a major consumer of CPU cycles, resulting in dropped packets.