[Winpcap-users] Packet timestamp strangeness

[Ioan Popescu]

Richard Hansen wrote:
> Ioan Popescu <ipopescu at dataq.com> wrote:
>> Mark Buchanan wrote:
>>> Take a close look at the initial set up of the adapter (pcap_open or 
>>> pcap_open_live function) - the read timeout parameter is critical to 
>>> what you are trying to do. The lowest value of 1 ms might not be fast
>>>  enough for you. Check the documentation - if set to 0 this might
>>> return immediately on every packet.
>> Use "-1" as the timeout to return immediately.
> 
> I tried this out and it pegged my CPU even without packets arriving.  I
> took a look at the source and when to_ms = -1, it doesn't wait for data
> -- it just polls as rapidly as it can.

I use it with a loop, not the callback function. But yes, it allows you to
poll for packets.

> to_ms apparently doesn't affect delay anyway if mintocopy = 0.  Based on
> my understanding of the code, the callback function is invoked when: *
> there is data available, AND * the number of bytes available has reached
> the mintocopy value OR to_ms has been reached, whichever is sooner.
> 
> So, if mintocopy is 0 (or really low) you can safely set to_ms to a high
> value without increasing latency.

I'm not an expert on WinPcap. Although there is always "latency", doing what
you describe should lower it. Don't forget the documentation warning:
decreasing mintocopy results in more CPU usage, make sure you have it. I
believe one of the reasons is because the driver transfers the data from
kernel memory to user memory more often instead of doing larger batches.
These transfers are costly.