From owner-freebsd-current@FreeBSD.ORG Tue May 25 06:12:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C29016A4CE for ; Tue, 25 May 2004 06:12:23 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9ACA43D46 for ; Tue, 25 May 2004 06:12:22 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 May 2004 09:12:05 -0400 Message-ID: From: Don Bowman To: 'Sergey Lyubka' , freebsd-current@freebsd.org Date: Tue, 25 May 2004 09:12:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 5.2.1 + snort, dropping packets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2004 13:12:23 -0000 From: Sergey Lyubka [mailto:devnull@uptsoft.com] > hackers, > I am running snort on 5.2.1-RELEASE, and I am getting high > dropped packets rate. traffic is quiet, about 1kpps, the box > runs on xeon > processor, intel gigabit NICs (em driver), system load is low: > > CPU states: 1.9% user, 5.1% nice, 1.6% system, 4.7% > interrupt, 86.8% idle > Mem: 121M Active, 97M Inact, 75M Wired, 736K Cache, 60M Buf, 201M Free > Swap: 512M Total, 512M Free > > > I have tried: > o both SMP and UP kernels > o both SCHED_ULE and SCHED_4BSD options > o libpcap libs versions 0.7 and 0.8.3 > o 5.2.1-RELEASE and -current kernels > o DEVICE_POLLING option > o sysctl debug.bpf_bufsize set to maximum of 524288 > > and still having dropped packets. > I am having a much lower spec box, running obsd 3.2, same > snort configuration, > capturing the same traffic. obsd shows constant 0 dropped packets. > > How would I fix that problem? This might be old information, but on stable branch, libpcap overrode the 'debug.bpf_bufsize' and always made it 4K. I made a local change and it fixed it for me. Not sure if that is corrected on current. On the system you indicate you should be able to get ~300Kpps into user space via bpf, or at least, you can with stable.