From owner-freebsd-net Sat May 20 4:52:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A8CAF37B589; Sat, 20 May 2000 04:52:45 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id HAA00591; Sat, 20 May 2000 07:52:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 20 May 2000 07:52:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dmitry Samersoff Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: bpf question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 May 2000, Dmitry Samersoff wrote: > I have traffic metering program using bpf, > it works fine on relatevly free net but looses about 30% > of packets on havy loaded one. Two possibilities come to mind: 1) You machine is too slow (pretty slow), your bus is too slow (ISA), or your cards are too slow (maybe if_ed). 2) You're using multiple processes/rforks to support the application, which results in a full context switch during BPF reads. Instead, use our userland pthreads library. Only you can tell us about (1) -- I can tell you I have successfully snarfed 60+mbps (probably more like 70) off of two 100mbps interfaces simultaneously with the CPU still quite low on FreeBSD 4.0, with a moderately decent machine (400mhzish box). There was no packet loss at all, and I was pulling the whole packet off the wire, not just the header. In this experiment, the limiting factors were the data-pumping machines, not the sniffing machine. Number (2) is interesting -- if I run two tcpdumps at the same time, I see a huge loss of performance, as all copies from kernel to userland happen twice, and many packet deliveries cause both processes to wake up and be scheduled. For high speed sniffing, using only a single process (i.e., just a relatively fast kernel->user1->kernel switch). Preventing a full userland context switch and making sure all BPF data goes through a single process makes a big difference (measurements on a p166). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message