Hmm on my boxes the combined sys and intr cpu rarely goes over 20% - most of the load is user space. I'd venture that most people running user space appllications will see similar numbers. I agree tat a box running as a router is not a good candidate for HT - that wasn't the question.
John [EMAIL PROTECTED] wrote: > When you get your machine running without a kernel > let me know. The kernel is the key to the O/S. If you > don't need networking and don't have many interrupts, > then it probably doesnt matter that much. > > > > -----Original Message----- > From: John Pettitt <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: freebsd-questions@freebsd.org > Sent: Sat, 26 Mar 2005 17:23:40 -0800 > Subject: Re: hyper threading. > > Well you've proven than if you pick your benchmark you can get the > result you want. > > So what that says it that the kernel network code doesn't get any > benefit from HT - given that HT is supposed to benefit diverse user > tasks and no multiple copies of the same code this is not big news - > since you have a HT box how about running a less system code intensive > and more diverse test? > > John > > > [EMAIL PROTECTED] wrote: > >> You can argue the technical theory all you want, but the >> measurements say otherwise. >> >> >> You guys have done it once again. Baited me into firing up a >> test that I already know the results of: >> >> Setup: Bridging em0 to em1 >> Load: 500Kpps, 60 bytes >> 3.4Ghz P4 1MB Cache >> >> FreeBSD 4.9 -> Load: 38% (I put this in for fun :-) >> >> Freebsd 5.4-Pre UP (no HT) -> Load: high 55-60% range >> >> FreeBSD 5.4-Pre SMP/HT -> Load: 70-80% (much more jumping around) >> >> The bottom line is that if you don't test things to get real >> world results, you don't know crap. >> >>> If that were true, then it would be equally true of systems with >> > actual > >>> multiple physical processors. In practice, multiple processors >> > provide > >>> an obvious performance gain, and hyperthreading does, too, although >> >> >> it's >> >>> much more modest than the gain obtained from physically independent >>> processors. >> >> >> >> this shows that you really are a bit foggy. Did you miss the part >> where with 2 processors you actually do have 2 processors? >> >> I can make an argument that networking with 1 processor on 5.4 is >> better than with 2. For example, with a test similar to the above, > > with > >> 2 phyiscal processors FreeBSD 5.4 will start dropping packets way > > before > >> it hits 500Kpps unless you increase the interrrupts/second, which of >> course increases the system load. And even with the dropped packets >> (which should reduce the load because it doesnt have to receive >> and transmit the packet), the load is still higher than for 4.x with >> a single processor. >> >> You and many others regulary say things like "SMP is obviously > > faster", > >> or "Opterons are noticably faster", but those statements are only true >> for certain applications. I've tested an Opteron 2.0Ghz against a > > 3.4Ghz > >> P4, and the results are pretty interesting. For raw performance, ie >> interrupts/second handling, the P4 wins easily. The P4 wins out of the >> cache. But once you grow out of the cache and get more memory >> intensive, the Opteron beats it handily. So which is really faster? > > You > >> could argue both depending on what benchmark you use. You >> have to test it in the environment where you plan to use it. Because >> the answer is almost never black and white. >> >> >> >> -----Original Message----- >> From: Anthony Atkielski <[EMAIL PROTECTED]> >> To: freebsd-questions@freebsd.org >> Sent: Sat, 26 Mar 2005 23:45:21 +0100 >> Subject: Re: hyper threading. >> >> [EMAIL PROTECTED] writes: >> >>> Yes, the theory is very nice; you've done a nice >>> job reading Intel's marketing garb. >> >> >> >> I haven't read their marketing materials. I'm simply going by the >> technical descriptions I've read of the architecture. >> >>> However if you don't have a specific hyperthreading-aware scheduler >>> and particularly well-written, threaded applications, you'll lose >> > more > >>> than you'll gain. >> >> >> >> If that were true, then it would be equally true of systems with > > actual > >> multiple physical processors. In practice, multiple processors > > provide > >> an obvious performance gain, and hyperthreading does, too, although > > it's > >> much more modest than the gain obtained from physically independent >> processors. >> >>> Since FreeBSDs network stack isn't particularly well threaded, nor is >>> the scheduler optimized for hyperthreading, you get a big mess at the >>> kernel level. >> >> >> >> Nothing needs to be specially optimized for hyperthreading. All you >> need is at least two threads available for dispatch, with reasonably >> heterogenous instruction mixes that can use different parts of the >> processor hardware at the same time. Real-world instruction mixes are >> often in this category in general-purpose operating systems. >> >>> So if you have a nice application that does a lot of threaded math >>> operations, you might think you've achieved something, >> >> >> >> Heavily math-oriented applications (or any group of applications that >> contains similar instruction mixes) are among the least likely to >> benefit from hyperthreading, because they will tend to use the same >> processor logic at the same time, effectively rendering hyperthreading >> moot. >> >>> But what you've missed is that the overhead to manage >>> the "better utilization" of the dual-pipelines created >>> by HT costs more than it gains. >> >> >> >> Unless FreeBSD is very poorly written indeed, the gain from >> hyperthreading should still exceed the slight increase in overhead >> incurred by multiprocessing logic. >> >>> Hence, the loss of performance. >> >> >> >> Where can I see this loss of performance documented? >> >>> The poblem is not at the application level, but at the kernel level. >>> The SMP overhead is so substantial, and the OS is working thinking it >>> has 2 processors, that process switching and interrupt handling slow >>> down considerably. >> >> >> >> How much is "so substantial"? Where can I see this documented? >> >>> A machine with a 50% load UP will run 65-70% load with >>> HT/SMP running. Like I said, its easily measurable. >> >> >> >> Then you can show me the measurements. Where are they? >> >> A 40% increase in system load just because of multiprocessing is >> enormous. Where did you get this figure? >> >>> Thats at the kernel level (say routing or bridging performance). >> >> >> >> But the kernel is only a small fraction of overall processor >> utilization. >> >>> Now if the machine isn't a server, it may be just fine. >>> Thats why I suggested testing. But for a network server >>> HT is bad. Very Bad. >> >> >> >> It doesn't matter whether the machine is a server or a desktop. What >> matters is the specific mix and nature of applications. >> >>> Not only that, but FreeBSD 5.x actually has a higher >>> capacity network-wise with 1 processor than 2 ... >> >> >> >> Here again, I need to see this documented. >> >>> ... and I'm sure you can theorize why 2 processors should be >>> faster than one. The theory only matters if you have >>> well written code to handle it properly. FreeBSD is >>> a long way off from that. >> >> >> >> Where can I see the measurements? >> >> -- >> Anthony >> >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" >> > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
