[Winpcap-users] Packet timestamp strangeness
ipopescu at dataq.com
Wed Jul 5 12:47:25 GMT 2006
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.
More information about the Winpcap-users