On Jan 9, 2015, at 2:09 AM, Michal Sekletar <msekl...@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. > so we don't > defeat the purpose of buffering entirely but delay is short enough that output > looks realtime-ish to human observer looking at the console. If we are dumping > to savefile we should use higher value. Yes, that's what I was suggesting - have tcpdump only use the 1-second timeout when writing to a file, and use a lower timeout, such as 1/10 second or less, when writing to a terminal, *regardless of what capture mechanism is being used*. That will remove the display delay for BPF-like capture mechanisms (BPF itself - except on AIX, where we use immediate mode due to bugs, TPACKET_V3, possibly the Tru64 UNIX mechanism) and have no effect on capture mechanisms that don't do timeout-based buffering (all other Linux mechanisms, IRIX, BPF on AIX, DLPI on HP-UX). DLPI+bufmod on Solaris, as I remember, does the timeout differently - it's an inter-packet timeout - but I think it might help there. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
