From owner-freebsd-questions@FreeBSD.ORG Wed Mar 23 23:06:40 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 6C1E916A4CE for ; Wed, 23 Mar 2005 23:06:40 +0000 (GMT) Received: from imo-m17.mx.aol.com (imo-m17.mx.aol.com [64.12.138.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C76443D58 for ; Wed, 23 Mar 2005 23:06:39 +0000 (GMT) (envelope-from EM1897@aol.com) Received: from EM1897@aol.com by imo-m17.mx.aol.com (mail_out_v37_r5.33.) id e.ba.6e4e43bf (15863); Wed, 23 Mar 2005 18:06:33 -0500 (EST) Received: from mblk-r10 (mblk-r10.mblk.aol.com [152.163.179.34]) by air-id06.mx.aol.com (v104.18) with ESMTP id MAILINID62-3df74241f679181; Wed, 23 Mar 2005 18:06:33 -0500 Content-Transfer-Encoding: 8bit Date: Wed, 23 Mar 2005 18:06:32 -0500 Message-Id: <8C6FE1416E7B78A-B30-25840@mblk-r10.sysops.aol.com> From: em1897@aol.com References: <20050323225053.7793.qmail@web90210.mail.scd.yahoo.com> Received: from 24.47.89.83 by mblk-r10.sysops.aol.com (152.163.179.34) with HTTP (WebMailUI); Wed, 23 Mar 2005 18:06:32 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <20050323225053.7793.qmail@web90210.mail.scd.yahoo.com> X-Mailer: AOL WebMail 1.0.0.11984 Content-Type: text/plain; charset="iso-8859-1"; format=flowed MIME-Version: 1.0 To: jason@ec.rr.com, freebsd-questions@freebsd.org X-AOL-IP: 152.163.179.34 Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre 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: Wed, 23 Mar 2005 23:06:40 -0000   > The answer, Boris, is that the "team" has no idea what  > they're doing. Check out some of the threads on  > performance testing. They tune little pieces here  > and there, and break 10 other things in the process.  > Matt Dillon "determined" that 10,000 ints/second  > was "optimal". Of course if you're passing 10Kpps  > that means you get an interrupt for every  > packet.  >  > They're playing pin the tail on the donkey.  >  You could understand what he was saying? I wanted to help but was unsure of what he was asking. I also seem to remember that discussion you are referring too. IIRC, 10,000hz for pooling was the setting they ere talking about. But on it would very a little, and with the fxp based card polling hurt a little because the card was already ding its own thing in hardware. So that setting was redundant, it was best to leave it alone.   He also seemed to say the network bandwidth was constant, and system load rose with an 64bit system. This right? If he was using GENERIC on a smp system he was only using 1 cpu with out a recompile. There is just so much that could be wrong and he gives no information on his system or settings.   Doess he have 2 amd64 pcs with 2 different installs of 5.3, or a single machine that he ran both versions on? The router, is that a third machine that was an amd64 system, or something else? He says i386, but an up to date 5.3 world doesn't support 386 with out a work around. The least commom setting is now 486, but a build for 686 would be better. Did he tell you if he had polling on?    So I guess it is a good thing you were able to help him, because I couldn't. Not to mention the flame bait you through out, well, that would be wrong. _______________________________________________  --------- Previous Message No, thats not what I was talking about. They were tuning the MAX_INTS parameter for the em driver, which can hold off interrupts to reduce system overhead. Instead of minimizing the load, they were focused on squeezing a few extra bits out of iperf, which is not how you tune performance. If you get 700Kb/s and have a 95% load and can get 695Kb/s with 60% load, which is better? Plus they were testing with a regular PCI bus, so they were hitting the wall on the bus throughput, which changes all the timings, so it was just a stupid test in general. I'm not 100% sure of what he was saying, but I've seen the same thing. I take an i386 disk and pop on an amd64 disk with the same settings, except for the 3 or 4 required differences, and the i386 machine has WAY less network load. So maybe your buildworld runs faster, but the whole interrupt/process switching mechanism runs like crap, so you likely have a slower machine. I haven't seen any test that shows otherwise, just a bunch of swell guys swearing that one thing is faster than another. I understand that you don't want to hear the truth, so flame away. But its not going to make things any better.