From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 22:00:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7129E16A4CF for ; Sat, 25 Sep 2004 22:00:07 +0000 (GMT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1964843D54 for ; Sat, 25 Sep 2004 22:00:07 +0000 (GMT) (envelope-from guy@alum.mit.edu) Received: from [192.168.0.5] (adsl-209-204-185-249.sonic.net [209.204.185.249]) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8PM06mP020409 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 25 Sep 2004 15:00:06 -0700 Message-ID: <4155EA65.50606@alum.mit.edu> Date: Sat, 25 Sep 2004 15:00:05 -0700 From: Guy Harris User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpdump-workers@lists.tcpdump.org References: <200409250714.RAA28547@avalon.reed.wattle.id.au> <41554E71.3020708@luckie.org.nz> In-Reply-To: <41554E71.3020708@luckie.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2004 22:00:07 -0000 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.