From owner-freebsd-questions@FreeBSD.ORG Sun Dec 11 16:55:12 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org 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 B644316A41F for ; Sun, 11 Dec 2005 16:55:12 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: from web33307.mail.mud.yahoo.com (web33307.mail.mud.yahoo.com [68.142.206.122]) by mx1.FreeBSD.org (Postfix) with SMTP id 9238243D5A for ; Sun, 11 Dec 2005 16:55:09 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: (qmail 17677 invoked by uid 60001); 11 Dec 2005 16:55:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XgJI0lCleF/Q500loRxGb+Y+dApcaPIlRlP73Vg+McWyOZNvcZh5BmAaO+27F1sCVCOvpzFhPJGMiUyHcMSd5KM8vNx50AMzoL62LhvSzMV+HVc8NvORrVPN/FgvvyLq4WAcuicyFv0Z+BRJhhGKuaM6fYMDD0y/dYiGNjAonlA= ; Message-ID: <20051211165509.17675.qmail@web33307.mail.mud.yahoo.com> Received: from [24.46.186.215] by web33307.mail.mud.yahoo.com via HTTP; Sun, 11 Dec 2005 08:55:08 PST Date: Sun, 11 Dec 2005 08:55:08 -0800 (PST) From: Danial Thom To: RacerX@makeworld.com, freebsd-questions@freebsd.org In-Reply-To: <439C4A08.7040809@makeworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: 5.4 vs. 6.0 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: danial_thom@yahoo.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 16:55:12 -0000 --- Chris wrote: > Danial Thom wrote: > >>>Kris is just a PR front man for a "team" of > >>>developers that is lost. Their "theory" on > >> > >>how to > >> > >>>build a better mousetrap for MP is > completely > >>>wrong, and now they're going to try > something > >>>else, using the entire FreeBSD community as > >>>guinea pigs. First 5.4 was the answer. Then > >> > >>6.0. > >> > >>>Now it looks like 6.0 sucks too. Its a damn > >>>shame. > >>> > >>>DT > >> > >>IF you are such a man that can actually call > >>himself an engineer - why > >>hide behind Yahoo mail? My company requires it > >> > >>Next, IF you are as you claim to be - WHY are > >>you not on the "team" or > >>at least contributing code? I think your premise that all of the great engineers contribute to open source projects is broken. Perhaps Kris' participation makes him a better chum than me, and it surely says that he has a lot more time. As someone who doesn't contribute significant code (although I have contributed fixes and ideas over the years under various aliases), perhaps you might say that I have no right to criticize. I'll give you that to some extent. But, as somone who built a product on FreeBSD and has a significant financial stake in its existence, I'm mad as heck that this current "team" has taken a perfectly good O/S, arguably the best networking OS around in 4.x, and made it a lot worse. Considering that they continually bamboozle us by saying how great the next version is going to be (when they really just want to have a few 100 people test it for them), should give us a charter to be pissed off. At least if they admitted things it would help. Do some reading in lucky.freebsd.performance. They are in total denial. Every time someone complains about network performance they blame TCP settings or some other ridiculous thing. They continue to rely on netperf for their measurements, and its just not the correct way to test. The problem with netperf is that is loads a machine to capacity and measures the capacity of the system. The problem is that no-one runs their machine at 90%+ cpu. Things change when you approach "the wall" and when you load the bus, so you're not really measuring the machine under normal conditions. What you want to do is measure the CPU load under high-normal working conditions, which is more like 50-70% range. As bus bandwidth diminishes and queues fill, timings change, because non-normal conditions exist. So the measurements they use are just wrong. Or at least they are wrong in measuring the real performance of a production system. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com