Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping
Matthew Luckie wrote: The motivation for this patch was to obtain something resembling the timestamp closest to when a packet I generated and transmitted hit the wire, to infer a more accurate RTT with an associated response packet. That's certainly a worthy goal, but the patch might not help much there - if you're getting time stamps for packets being transmitted by the machine running the BPF-based application, the time stamps you'll get are the time when the packet gets wrapped around by BPF in the driver, but there's more time spent in the CPU handing the packet to the network adapter and possibly time spent in the network adapter, especially if it has to wait for others to finish transmitting, or deal with collisions, on Ethernet, wait to get the token on a token-based network, etc.. It also wouldn't help get time stamps closer to the *received* time stamp, as it'd include time between the time when the last octet of the packet was received and when the driver handed it to BPF. On the other hand, one could perhaps argue that those times *should* be counted in RTT, if you're trying to measure application RTT rather than low-level link-layer RTT There is an argument to be made for generating the timestamp just the once after it actually passes a filter, I.e., so you don't spend CPU time generating the time stamp for packets that'll be discarded? That might be worthwhile, given that I think people have found that getting time stamps *can* be a bottleneck when capturing lots of traffic, so it might be a bottleneck if you're receiving a lot of traffic and discarding most of that traffic. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping
This is probably a pointless optimization, as you probably relatively rarely have multiple BPF devices bound to the same interface receiving the bulk of the packets (as opposed to some daemon with a filter that passes only the packets it's interested in), but would there be any advantage to having "bpf_tap()" and "bpf_mtap()" fetch the time stamp and pass that to "catchpacket()", so that in the case where there *is* more than one tap, the time stamp is only fetched once? That makes sense and allows you to correllate packet time stamps from a daemon collecting packets with those you see in tcpdump output when you run that in parallel to make sure things are moving. i've generated a patch to accomplish this on FreeBSD 4.10 and submitted a PR for it just a couple of weeks ago, when i noticed a small difference between the timestamp I captured in an application compared to what i saw with tcpdump. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71711 The motivation for this patch was to obtain something resembling the timestamp closest to when a packet I generated and transmitted hit the wire, to infer a more accurate RTT with an associated response packet. I'm not sure if what I've used BPF for in this case is 'correct' in that I've not done any real study to see how the timestamp compares to what a DAG would report. There is an argument to be made for generating the timestamp just the once after it actually passes a filter, but I've not done that in my patch. Feedback appreciated. Matthew - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 24.09.2004 - 25.09.2004 GMT
CVS log entries from 24.09.2004 (Fri) 09:06:39 - 25.09.2004 (Sat) 09:06:54 GMT = Summary by authors = Author: guy File: tcpdump/print-nfs.c; Revisions: 1.103 File: tcpdump/extract.h; Revisions: 1.23, 1.22, 1.21 File: tcpdump/cpack.c; Revisions: 1.2 Author: hannes File: tcpdump/CREDITS; Revisions: 1.100 = Combined list of identical log entries = Description: Add an "EXTRACT_64BITS()" macro - using the "EXTRACT_32BITS()" macro, so we get the fast implementations if we are on a processor that doesn't require alignment. Modified files: File: tcpdump/extract.h; Revision: 1.21; Date: 2004/09/24 18:21:25; Author: guy; Lines: (+5 -1) File: tcpdump/print-nfs.c; Revision: 1.103; Date: 2004/09/24 18:21:25; Author: guy; Lines: (+2 -2) = Log entries = Description: add David Young to the maintainers list Modified files: File: tcpdump/CREDITS; Revision: 1.100; Date: 2004/09/24 22:42:42; Author: hannes; Lines: (+1 -0) --- Description: Include to declare "memset()". Add a cast to squelch a compiler complaint. Modified files: File: tcpdump/cpack.c; Revision: 1.2; Date: 2004/09/24 18:18:00; Author: guy; Lines: (+2 -1) --- Description: Fix the parenthesization in the "alignment required but you can convince GCC to generate alignment-safe loads by using __attribute((packed))" version of EXTRACT_64BITS(). Fix one of the byte offsets in the "alignment required and we don't know how to trick the compiler into generating alignment-safe loads" version of EXTRACT_64BITS(). Modified files: File: tcpdump/extract.h; Revision: 1.23; Date: 2004/09/25 07:41:44; Author: guy; Lines: (+3 -3) --- Description: Don't do the "OR together the result of two "ntohl()"s stuff on platforms that don't support unaligned fetches - just assemble the 64-bit big-endian integer from its constituent bytes. Improve some comments. Modified files: File: tcpdump/extract.h; Revision: 1.22; Date: 2004/09/25 06:48:14; Author: guy; Lines: (+24 -9) = Summary of modified files = File: tcpdump/CREDITS Revisions: 1.100 Authors: hannes (+1 -0) --- File: tcpdump/cpack.c Revisions: 1.2 Authors: guy (+2 -1) --- File: tcpdump/extract.h Revisions: 1.23, 1.22, 1.21 Authors: guy (+3 -3), guy (+24 -9), guy (+5 -1) --- File: tcpdump/print-nfs.c Revisions: 1.103 Authors: guy (+2 -2) -- Automatic cron job from /tcpdump/bin/makelog - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping
In some email I received from Guy Harris, sie wrote: > On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote: > > > Here's a patch against 5.3 to add a per-instance switch which allows > > the user to specify if captured packets should be timestamped (and, > > if so, whether microtime() or the faster but less accurate > > getmicrotime() call should be used). > > This is probably a pointless optimization, as you probably relatively > rarely have multiple BPF devices bound to the same interface receiving > the bulk of the packets (as opposed to some daemon with a filter that > passes only the packets it's interested in), but would there be any > advantage to having "bpf_tap()" and "bpf_mtap()" fetch the time stamp > and pass that to "catchpacket()", so that in the case where there *is* > more than one tap, the time stamp is only fetched once? That makes sense and allows you to correllate packet time stamps from a daemon collecting packets with those you see in tcpdump output when you run that in parallel to make sure things are moving. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
