Re: Libpcap timeout settings in tcpdump - too long when printing to a terminal?

[David Laight <David.Laight () ACULAB COM>]

From: Guy Harris
> On Jan 9, 2015, at 2:09 AM, Michal Sekletar <msekleta () redhat com> wrote:
>
> > Can't we use new default timeout value (lower) if we detect TPACKET_V3,
>
> The first sentence of my original mail was "With TPACKET_V3 support, Linux users are discovering what
> those of us using BSD-flavored OSes have known for quite a while:"
>
> This is not a TPACKET_V3 issue, it's a buffering issue.  I notice it when testing tcpdump on Macs,
> which don't have PF_PACKET sockets of any sort, they have BPF; if, for example, I test on the
> generally-low-traffic loopback interface by pinging 127.0.0.1, the packets don't show up continuously,
> they show up in batches, with a 1-second delay.

Is there any real reason for a delay as long as 1 second?
If the traffic is light (which might mean 100/sec) then processing
every packet separately isn't going to be a problem.
Cleary at very high rates you do want to defer the wakuep.

So reducing the delay from 1 sec to 100ms (or even 50ms) will have
little effect on the ability to process the received data.

        David

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers