Date: Wed, 23 Mar 2005 18:06:32 -0500 From: em1897@aol.com To: jason@ec.rr.com, freebsd-questions@freebsd.org Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre Message-ID: <8C6FE1416E7B78A-B30-25840@mblk-r10.sysops.aol.com> In-Reply-To: <20050323225053.7793.qmail@web90210.mail.scd.yahoo.com> References: <20050323225053.7793.qmail@web90210.mail.scd.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C6FE1416E7B78A-B30-25840>