From owner-freebsd-questions@FreeBSD.ORG Thu Jan 6 16:10:53 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAB7D16A4CE for ; Thu, 6 Jan 2005 16:10:53 +0000 (GMT) Received: from imo-m22.mx.aol.com (imo-m22.mx.aol.com [64.12.137.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5018843D46 for ; Thu, 6 Jan 2005 16:10:53 +0000 (GMT) (envelope-from Tm4528@aol.com) Received: from Tm4528@aol.com by imo-m22.mx.aol.com (mail_out_v37_r3.8.) id f.13c.a0c43e8 (14374); Thu, 6 Jan 2005 11:10:23 -0500 (EST) From: Tm4528@aol.com Message-ID: <13c.a0c43e8.2f0ebcef@aol.com> Date: Thu, 6 Jan 2005 11:10:23 EST To: dave@horsfall.org MIME-Version: 1.0 X-Mailer: 9.0 for Windows sub 5116 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: questions@freebsd.org cc: tedm@toybox.placo.com cc: kris@obsecurity.org Subject: Freebsd 5.3 Performance X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 16:10:53 -0000 In a message dated 1/6/05 4:51:10 AM Eastern Standard Time, dave@horsfall.org writes: > 4.10 *is* supported, and 5.3 works "as advertised" - what the hell is your > *problem* exactly??? Its been well documented that 5.3 does NOT work as advertised, and the newest intel chipsets (not that new) don't work in 4.10, redering is useless with the newer intel processors. To quote Robert watson of the Freebsd core team who posted to this list on Nov 11, 2004: " FreeBSD 5.3 sees an observably higher per-packet processing costs than the 4.x branch due to in-progress changes to the synchronization and queueing models. Specifically, the SMPng work has changed the interrupt and synchronization models throughout the kernel in order to increase concurrency and preemptibility (i.e., lower latency in interrupt-based processing). However, this has increaseed the overall overhead of synchronization on the stack. The network stack forwarding path is particularly sensitive to this, so while other parts of the system see immediate concurrency benefits (i.e., socket-centric web servers that now see less contention on SMP, and more preemption on UP), this path still runs slower for many workloads. We're actively working to remedy this, and you will see changes merged to the 6.x and 5.x branches over the next couple of months that will cut into the numbers you see above by quite a bit. Off the top of my head, I would have expected to see more around a 15% overhead on UP for the workload you're seeing, but as you point out, results can and do vary." 5.3 is not ready for production. 4.10 should be fully supported until it is. TM