On Fri, 16 Apr 1999, Dick Balaska wrote:
> It is important to find out what went wrong.
>
> Here is the zdnet response to the test:
>
>http://www.excite.com/computers_and_internet/tech_news/zdnet/?article=/news/19990415/2242246.inp
I agree (and find the ZDnet treatment fairly even-handed).
However, it isn't clear that anything "went wrong" at this time. I do
not for a minute believe that "..it's likely that a highly tuned NT, on
the Mindcraft SMP platform, would prove a bear even for a tuned Linux to
defeat". The issue could be less one of "tuning" than of simple
mind(craft)less silliness in configuration. I try to imagine just where
linux would have broken down in its scaling behavior given that 2.2.x
fine-grains kernel bound resources and that (as the ZD article clearly
states) UP Linux beats UP NT handily. There are several points covered
in the two previously posted URL/articles of which any one by itself
could be responsible for the entire deficit -- the beta RAID driver
especially, could be falling back to near UP performance levels if it
has a poor spinlock.
That's why I posted the query about running directly from U2W disk with
RAID in software -- Doug Ledford has done some benchmarks that show that
Linux can basically get hardware-limited throughput from dual U2W
controllers with dual Cheetahs on each. NT cannot do better than
hardware speed, and this configuration very nearly saturates the PCI bus
and NT cannot do better than to saturate the PCI bus. I don't think
that it is a tuning issue per se at all (MIS-tuning is more like it).
2.2.x ought to be able to operate snuggled up against hardware
boundaries in several dimensions, and I would have expected hardware to
be the rate limiting bottleneck if one merely avoided setting parameters
so that, e.g. -- the Apache server would fill all available memory and
force the system to swap. I'll wager that ten minutes watching the
system fail under load with a procmeter would indicate which resource or
resources are being stupidly configured and indicate the way to fix
things.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
