Date: Sun, 16 Jan 2000 15:25:15 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: ap@bnc.net (Achim Patzner) Cc: current@freebsd.org Subject: Re: Current, XEON and MP performance Message-ID: <200001162025.PAA03056@skynet.ctr.columbia.edu> In-Reply-To: <20000116103935.A9402@bnc.net> from "Achim Patzner" at Jan 16, 2000 10:39:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Achim Patzner had to walk into mine and say: > I don't know where to ask first (or what to look at) so I'd like some > creative guessing by some people closer to the sources... > > Running the same programs on nearly identically configured -CURRENT kernels > on a > HP NetServer LH4 > (four 550 MHz PIII Xeon with 512MB Cache, 512MB cache? I think you mean KB. > supposed to be an INTEL 450NX-based chipset) > with one GB RAM > and a home-grown ASUS P2-BDS based system > (two 450 MHz PIII) > with 512 MB RAM > I find that the > programs (running on the same input data) on the "smaller" machine tend to > take only a third of the CPU time they need on the LH4. Can you show us the actual results from your testing (an hopefully your testing methods as well) that led you to this conclusion? Details matter. Are these programs I/O bound, CPU bound, or a little of both? FreeBSD's SMP support still depends largely on the big giant lock approach which means that while you can indeed get processes running on multiple CPUs at the same time, you end up using only one CPU once you enter the kernel. And you have to enter the kernel in order to perform any disk, network or even console I/O. If your programs suck large datasets into memory, do lots of number crunching on them, then spit the results back out to a disk file, then they should benefit from more CPUs. However if they read and write data a lot while running, you're going to be limited by the big giant lock. There may also be scalability issues (i.e. does FreeBSD perform better as you add more CPUs or does it spend so much time trying to stay out of its own way that it actually performs worse) however I don't know enough to say if you could be running into such problems as the only SMP machines I have access to have only 2 CPUs. > [Worse: The LH4 > behaves like a spoilt brat when it comes to hardware, disliking the Intel > EtherExpress that came with it (generating bus mastering problems after > bringing it up), Which model Intel EtherExpress? What chipset? What bus mastering problems exactly? > having interrupt routing problems with two DEC TULIP based > ethernet cards sharing the same IRQ Which tulip cards? What driver? What kind of problems? I find it unusual that two PCI devices would wind up with the same IRQ with the APIC enabled since it's supposed to give you a lot more IRQs than in UP mode. > and being picky just which 3C906B-TX it > gets plugged in. There is no such card as a 3c906B. There's a 3c905B, and there's a 3c905C. Unfortunately, 3Com did go through several different ASIC revisions with the 3c905B series, some of which work better than others, but again, I see no details here. > It's a bitch and I'd like shooting it. Oh yes - HP has been > very helpful, telling me that I was at least 10 years behind wanting to run > a BSD and that only WinNT, HP-Sux and Linux were supported on this hardware.] If somebody at HP actually told you that HP-UX runs on anything besides the PA-RISC architecture (and, in the distant past, the m68k architecture), they were either a) jerking your chain, b) working at HP in an parallel dimension, c) misinformed, or d) not terribly bright. (I'm sure HP wouldn't mind having HP-UX/x86, but they certainly don't offer it as a product now.) > Back to the topic: Are there any reasons for these observations? If someone > liked taking a closer look at it I could provide them with access to the > machine (and its console). I ran out of clues... Hard to tell really without more info. We don't know what your test programs do, so it's impossible to predict what their behavior should or shouldn't be. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001162025.PAA03056>