Re: Usage of pcap_open_live argument to_ms

[Guy Harris <guy () alum mit edu>]

On Dec 9, 2004, at 1:09 PM, Robert Lowe wrote:

> to_ms specifies the read timeout in milliseconds. The read timeout is
> used to arrange that the read not necessarily return immediately when
> a packet is seen, but that it wait for some amount of time to allow
> more packets to arrive and to read multiple packets from the OS kernel
> in one operation. Not all platforms support a read timeout; on
> platforms that don't, the read timeout is ignored. A zero value for
> to_ms, on platforms that support a read timeout, will cause a read to
> wait forever to allow enough packets to arrive, with no timeout.
>
> --
>
> How does one "tune" this value?

It's a tradeoff between latency and packet drops.  Having a too-large 
value increases latency - if you have a timeout of, for example, 10 
seconds, then if you get one packet a second on the network, you might 
not see that packet until 10 seconds after it arrives.  Having a 
too-small value could mean that, with sufficiently heavy traffic, 
you'll be more likely to lose packets.

> Does using a zero value on platforms that support a read timeout have 
> performance implications?

Probably not much of one, but it has severe latency implications, i.e. 
the latency becomes, at worst, infinite, i.e. if you only get one 
packet ever on a network, you'll *never* see it - you'll only see 
packets once the buffer fills up.

> What does "enough packets" mean exactly?

What it means depends on, at minimum, the OS and the size of the 
packets and the size of the buffer.  I.e., we use the vague phrase 
"enough packets" intentionally - it's not predictable.

> Are packets queued for the callback routine -- I'm using pcap_loop().

Queued where?

On all current systems with a timeout and buffering, packets are 
buffered in the OS kernel until either

        1) the buffer fills up

or

        2) the timer expires

at which point, if there's a read in progress on the device (which 
"pcap_loop()", "pcap_dispatch()", "pcap_next()", and "pcap_next_ex()" 
will do), the read will complete and return whatever packets there are 
in the buffer.  Those routines will return packets from the batch that 
were read in; until all packets in that batch are returned and the next 
packet is requested, the next read on the device won't be started.

> Also does pcap_loop() set errno if it terminates abnormally?

Possibly, possibly not.  If you want to report the error from an 
abnormal termination of "pcap_loop()", use "pcap_perror()" or 
"pcap_geterr()".

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.