Would the current state of athlon support be considered stable?
I've got a colleague interested in getting a dual athlon box, and
I'll be making the decision as to what hardware to purchase. I'm
wondering is dual Athlon viable for a business solution right
now, or is it considered "experimental"?
What hardware would be recommended for a dual CPU system that
needs to be fairly rock solid? Should I recommend to stay with
the P-III Xeon? Or something else? What issues would I expect
to have to deal with if going with a dual Athlon?
Also, what is a good rock solid SCSI RAID controller? Money is
no object. Reliability, performance and Linux compatibility are
though.
Chipsets to avoid?
Any experiences/info good/bad would be greatly appreciated.
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> Would the current state of athlon support be considered stable?
yes.
Andrea
Moin Mike,
> From: Mike A. Harris [mailto:[email protected]]
>
> Would the current state of athlon support be considered stable?
> I've got a colleague interested in getting a dual athlon box, and
> I'll be making the decision as to what hardware to purchase. I'm
> wondering is dual Athlon viable for a business solution right
> now, or is it considered "experimental"?
I don't know if anyone can say if it's stable, as there are no dual Athlon
boxes out there yet.
> What hardware would be recommended for a dual CPU system that
> needs to be fairly rock solid? Should I recommend to stay with
> the P-III Xeon? Or something else? What issues would I expect
> to have to deal with if going with a dual Athlon?
AFAIK Tyan is the only manufacturer building such a board (Thunder K7 /
S2562) right now. This will use AMD's 760MP Chipset with DDR memory support
up to 4GB, 5 64bit PCI slots, AGP pro, dual NIC (3c920), U160SCSI (aic7899).
The launch for dual Athlon is planned for June 4th.
If this will be rock-solid will be shown in the first weeks of Q3.
I am also highly interested in information about dual Athlon (which
kernel/compiler/tools to use?), as we will get a dual Athlon sample before
the launch.
Olli
--
Die Wahrheit liegt irgendwo da drau?en...
Moin Andrea,
> From: Andrea Arcangeli [mailto:[email protected]]
>
> On Tue, Apr 24, 2001 at 08:03:18AM +0200, Antwerpen, Oliver wrote:
> > I am also highly interested in information about dual Athlon (which
> > kernel/compiler/tools to use?), as we will get a dual
> Athlon sample before
>
> kernel >= 2.4.3 (better >= 2.4.4pre2 for other rasons)
> compiled for K7 and
> CONFIG_SMP=y, compiler as usual for the kernel gcc 2.95.[43]
> or egcs 1.1.2.
So there is nothing special about that? Have you already had the chance to
test this? What can you say about it?
Olli
--
Die Wahrheit liegt irgendwo da drau?en...
On Tue, Apr 24, 2001 at 08:03:18AM +0200, Antwerpen, Oliver wrote:
> I am also highly interested in information about dual Athlon (which
> kernel/compiler/tools to use?), as we will get a dual Athlon sample before
kernel >= 2.4.3 (better >= 2.4.4pre2 for other rasons) compiled for K7 and
CONFIG_SMP=y, compiler as usual for the kernel gcc 2.95.[43] or egcs 1.1.2.
Andrea
Andrea Arcangeli wrote:
>
> On Tue, Apr 24, 2001 at 08:03:18AM +0200, Antwerpen, Oliver wrote:
> > I am also highly interested in information about dual Athlon (which
> > kernel/compiler/tools to use?), as we will get a dual Athlon sample before
>
> kernel >= 2.4.3 (better >= 2.4.4pre2 for other rasons) compiled for K7 and
> CONFIG_SMP=y, compiler as usual for the kernel gcc 2.95.[43] or egcs 1.1.2.
With the recent development kernels, an Athlon SMP kernel boots and runs
fine
on a uniprocessor Athlon machine. This was busted until a few weeks
ago.
I don't have a SMP Athlon box to test with, so I can't help you there.
Miles
"Mike A. Harris" wrote:
>
> Would the current state of athlon support be considered stable?
> I've got a colleague interested in getting a dual athlon box, and
> I'll be making the decision as to what hardware to purchase. I'm
> wondering is dual Athlon viable for a business solution right
> now, or is it considered "experimental"?
>
> What hardware would be recommended for a dual CPU system that
> needs to be fairly rock solid? Should I recommend to stay with
> the P-III Xeon? Or something else? What issues would I expect
> to have to deal with if going with a dual Athlon?
>
> Also, what is a good rock solid SCSI RAID controller? Money is
> no object. Reliability, performance and Linux compatibility are
> though.
>
> Chipsets to avoid?
>
> Any experiences/info good/bad would be greatly appreciated.
The build problen with Athlon+SMP was solved by AA's patch. I had tested a
similar patch on UP over 2.4.0-test and previous 2.4 releases with nary a
problem.
This may be too experimental for your purposes, but FWIW I'm writing from a
2.4.4-pre3 built with gcc-2.97-20010205 using -march=athlon set by the k7
config. I've been building kernels with that snapshot since the middle of
Feb. With the current image, the box has locked up once in continuous use. I
can't say what caused that one, no log survived.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
On Tue, Apr 24, 2001 at 01:18:57PM +0300, Ville Herva wrote:
> There's also AthlonLinux http://athlonlinux.org/ and AthlonGCC
> http://athlonlinux.org/agcc/about.shtml, but I have no experience with those
> (I have no Athlon ;( ).
A warning about agcc, I've discovered that it does not always compile code
quite the way you expect it. This is unsurprising given it's based on
pgcc which is known to change alignments on you in ways that sometimes
break things subtly.
I do not know if agcc actually can produce code which simply does not work
as is reported with pgcc (I suspect the alignment differences account for
many of those cases), but I recall reading in the past few days that agcc
is not supported for compiling the kernel.
It also fails to properly compile certain other programs, notably anything
that includes asm functions. As a result, my own experience suggests you
consider agcc in the same class as gcc 3.0 at the moment - experimental.
Hopefully the k7 optimizations that work well will find their way into a
nice athlon subarch options in standard gcc and agcc won't be necessary.
--
Joseph Carter <[email protected]> Free software developer
Guns don't kill people. It's those damn bullets. Guns just make them go
really really fast.
-- Jake Johanson
On Tue, Apr 24, 2001 at 03:39:22AM -0700, you [Joseph Carter] claimed:
>
> A warning about agcc, I've discovered that it does not always compile code
> quite the way you expect it. This is unsurprising given it's based on
> pgcc which is known to change alignments on you in ways that sometimes
> break things subtly.
While people always bash pgcc, I've had pretty good experiences with it.
Mostly everything I've compiled with it has worked quite well - even a
2.0.34 kernel (which I compiled accidentally with pgcc) ran with no problems
for long times. Sometimes pgcc does give internal errors with highest
optimizations, though.
Don't take me wrong: I'm not advocating using pgcc for any serious
production systems (nevermind any kernel stuff), but perhaps it shouldn't be
completely discarded for perfomance hungry stuff (where a miscompile won't
cause third World War). It does gain as much as 30% in some cases over older
gcc - I'm not sure how good the newest gcc's are, but oldish pgcc does beat
gcc-2.96 on stuff I tried. (Didn't gcc get a new IA32 backend some time ago?
How good is that?)
> I do not know if agcc actually can produce code which simply does not work
> as is reported with pgcc (I suspect the alignment differences account for
> many of those cases), but I recall reading in the past few days that agcc
> is not supported for compiling the kernel.
Any pgcc variant is quite bad idea for kernel stuff. There are known
problems (I think), and it doesn't even gain that much since kernel is
pretty much hand optimized anyway.
But if the instruction scheduler in the compiler knows about K7, I imagine
that could gain something. Perhaps it could use the preload instructions etc
as well? The again, I'm no kernel NOR compiler guru.
> It also fails to properly compile certain other programs, notably anything
> that includes asm functions. As a result, my own experience suggests you
> consider agcc in the same class as gcc 3.0 at the moment - experimental.
> Hopefully the k7 optimizations that work well will find their way into a
> nice athlon subarch options in standard gcc and agcc won't be necessary.
Hope so. Unfortunately AMD doesn't seem to be doing all that much compiler
work (Intel has a whole compiler suite for Win, and did the beginnings of
pgcc, if I've not mistaken.)
-- v --
[email protected]
Joseph Carter <[email protected]> writes:
> On Tue, Apr 24, 2001 at 01:18:57PM +0300, Ville Herva wrote:
> > There's also AthlonLinux http://athlonlinux.org/ and AthlonGCC
> > http://athlonlinux.org/agcc/about.shtml, but I have no experience with those
> > (I have no Athlon ;( ).
>
> A warning about agcc, I've discovered that it does not always compile code
> quite the way you expect it. This is unsurprising given it's based on
> pgcc which is known to change alignments on you in ways that sometimes
> break things subtly.
>
>
> I do not know if agcc actually can produce code which simply does not work
> as is reported with pgcc (I suspect the alignment differences account for
> many of those cases), but I recall reading in the past few days that agcc
> is not supported for compiling the kernel.
>
> It also fails to properly compile certain other programs, notably anything
> that includes asm functions. As a result, my own experience suggests you
> consider agcc in the same class as gcc 3.0 at the moment - experimental.
> Hopefully the k7 optimizations that work well will find their way into a
> nice athlon subarch options in standard gcc and agcc won't be necessary.
Note that gcc 3.0 will have support for Athlons, -mcpu=athlon and
-march=athlon are both supported and will do the right thing. For
details you should ask Jan Hubicka who implemented this some time ago,
Andreas
--
Andreas Jaeger
SuSE Labs [email protected]
private [email protected]
http://www.suse.de/~aj
On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> Also, what is a good rock solid SCSI RAID controller? Money is
> no object. Reliability, performance and Linux compatibility are
> though.
I have very good experiences with the Mylex controllers/drivers!
But then again I also have good experiences with the new-style SW-RAID;
it performs very well indead and it is quite cheap :)
Regards,
Martin
--
There's no place like ~
On Wed, Apr 25, 2001 at 01:18:42AM +0200, Martin Clausen wrote:
> On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> > Also, what is a good rock solid SCSI RAID controller? Money is
> > no object. Reliability, performance and Linux compatibility are
> > though.
>
> I have very good experiences with the Mylex controllers/drivers!
>
> But then again I also have good experiences with the new-style SW-RAID;
> it performs very well indead and it is quite cheap :)
Remember, any RAID solution is based on software. The difference is, whether
the software is closed-source and hiding on a slow processor, or free software
running on a much more powerful processor (which on the other hand also needs
to run other parts of the system, as this is the main CPU).
The main selling-points of software RAID except for stability and usually much
higher performance than "hardware" RAID is, that the interaction between the
userland tools and the RAID code is "open". People who use RAID, be it one
kind or the other, occationally meet some problem where the RAID seems to be
having a will of it's own. With the "open" solution, you as an administrator
actually have a chance of figuring out what happens.
I know the usual trouble-shooting on proprietary RAID seems to be "uh, it
doesn't work ? well, try the newer drivers and firmware. Oh, you did that,
well, then try the older versions then". If people are comfortable with that
kind of systems, well, fine as long as it's not my data. I want to know the
code I trust my data with. From an theoretical point of view, it is stupid to
trust proprietary code - however, in the case of RAID I believe (at least some
of) the manufacturers has managed to prove that even from a purely pragmatic
point of view it is stupid to trust their code.
Yet, an awful lot of people seem to prefer the so-called "hardware" RAID :)
--
................................................................
: [email protected] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob ?stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
On Tue, Apr 24, 2001 at 03:33:00AM -0400, you [Tom Leete] claimed:
>
> The build problen with Athlon+SMP was solved by AA's patch. I had tested a
> similar patch on UP over 2.4.0-test and previous 2.4 releases with nary a
> problem.
>
> This may be too experimental for your purposes, but FWIW I'm writing from a
> 2.4.4-pre3 built with gcc-2.97-20010205 using -march=athlon set by the k7
> config. I've been building kernels with that snapshot since the middle of
> Feb. With the current image, the box has locked up once in continuous use. I
> can't say what caused that one, no log survived.
There's also AthlonLinux http://athlonlinux.org/ and AthlonGCC
http://athlonlinux.org/agcc/about.shtml, but I have no experience with those
(I have no Athlon ;( ).
-- v --
[email protected]