Date: Thu, 24 Mar 2005 10:23:26 -0500 From: em1897@aol.com To: freebsd-questions@freebsd.org Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre Message-ID: <8C6FE9C8F1C50E9-B50-2E021@mblk-d19.sysops.aol.com> In-Reply-To: <424256E6.5030301@ec.rr.com> References: <20050323225053.7793.qmail@web90210.mail.scd.yahoo.com> <8C6FE1416E7B78A-B30-25840@mblk-r10.sysops.aol.com> <424256E6.5030301@ec.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think that warning people that the good name of "FreeBSD" is being tainted by the current band of clowns is very productive. Its more like a religion now; I've never seen so many people in total denial that their beliefs are completely wrong. A lot of people are wasting a lot of time because of this propaganda. The cluelessness in the performance list is a good indication. -----Original Message----- From: jason henson <jason@ec.rr.com> To: em1897@aol.com Cc: freebsd-questions@freebsd.org; hardcodeharry@yahoo.com Sent: Thu, 24 Mar 2005 00:57:58 -0500 Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre em1897@aol.com wrote: > > >> 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 would say 60% load. Now I completely understand what you were saying. > > 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. Ahh! More flame bait! I just didn't like you platitudinal and unproductive message that I believe would just drive Boris onto linux and leave a possible open problem on FreeBSD for some one else to discover latter. It's not that I don't want to hear the truth, you were just not saying anything worth his time. But atleast now we can get some where to help him and the amd64 port. I also had the idea that Boris was just trolling because he has not responded, just said FreeBSD was bad and left us to duke it out. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > So the whole interrupt/process switching mechanism runs like crap with the amd64 build? Since I don't have a amd64 system, and you might hav access to atleast 1, how about getting a little info on the irqs? Look at systat -vmstat or vmstat -i under load? aybe report it back? I wonder if the irq rates are changing, or irqs are taking longer to service. Either there is a problem. Ofcourse some hardware info would be nice, chipset and cpu? Maybe you script vmstat -i for a log, and use netperf too? I like Nick's followup. I would guese Boris may have a problem with proper hardware support. I can't really said it is bad hardware if speeds are the same, just high load(right?). Maybe the driver he is using is not good for 64bit as it is for 32bit? I think if Boris studies the thread I like to below he will be alright. Check this out: http://www.atm.tut.fi/list-archive/freebsd-stable/thrd66.html http://docs.freebsd.org/cgi/mid.cgi?200502171636.10361.drice Inparticular: http://www.atm.tut.fi/list-archive/freebsd-stable/msg19651.html http://www.atm.tut.fi/list-archive/freebsd-stable/msg19679.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C6FE9C8F1C50E9-B50-2E021>