EM64T and linux

[Christopher Browne]

On 4/28/06, Vince Hillier <vince-WxfNDWQh5LNIo2TaICnI/Q at public.gmane.org> wrote:
> Dave Cramer wrote:
>
> >
> > On 28-Apr-06, at 7:33 PM, Vince Hillier wrote:
> >
> >> Christopher Browne wrote:
> >>
> >>> On 4/28/06, Phillip Qin <Phillip.Qin-szgMhqSEIEG+XT7JhA+gdA at public.gmane.org> wrote:
> >>>
> >>>> But all the servers Dell offers use the EM64T. I have no choice.
> >>>> The port
> >>>> does say "The port consists of kernels for all AMD 64bit CPUs  with
> >>>> AMD64
> >>>> extension and all Intel CPUs with EM64T extension, and a common  64bit
> >>>> userspace.".
> >>>
> >>>
> >>> Well, then, that strikes me as an excellent reason to NOT buy
> >>> servers from Dell.
> >>
> >>
> >>
> >> That's pretty black and white no?  The 64 bit processors run 32 bit
> >> code fine.
> >>
> >>>
> >>> We stopped doing it a while back because they were severely
> >>> underperforming.
> >>
> >>
> >> I'd like to see "serverly" defined, as they're not that bad.
> >
> > Dell servers are what they are, they don't perform well for
> > postgresql. This is a well known fact. The reason is because their
> > disk I/O is very poor. Disk I/O affects all applications.
> >
> > For the same money you can get much better hardware. But it's your
> > money Chris is giving you the benefit of the experience of a company
> > that uses a lot of servers. You can choose to accept this charity or
> > not...
>
>
> Phillip is looking for a web server, not a postgres server.  I've yet to
> see a site that would degrade a dell due to I/O issues. Your frontends
> should be doing minimal seeking, if they aren't, you need a new system
> architect.

Well, the Dell servers I have had the misfortune of using have
suffered pretty badly in multiple ways:

a) I/O bandwidth seems poorer than the hardware ought to be able to support.

It looks as though the Dell thing of "buying what's cheapest this
week" has some negative effects.

That's something to worry about for any application that could be
bottlenecked by I/O.

b) Intel memory bandwidth seems to have headed back to "sucking
incredibly" over the last couple of years.

The thing I observed was that large chunks of memory accessed via PAE
essentially meant that the most memory you could *effectively* put on
a box was about 2GB, even if you had 8GB of chips there.

PAE is effectively a leap back to the days of bank switching, which
was how I used to connect 256K of memory to a 6502 that only really
supported 64K.

Unfortunately, performance suffers multiply.

Firstly, you were limited to 2GB process memory, so you had to find
multiple processes using Lotso Memory to get any use of 8GB of memory.

Secondly, DMA doesn't wind up working properly in contexts where
you're bank switching.  I/O winds up stuck in the lowest 2GB of the
machine's memory...  This has *hideous* effects on performance which
winds up affecting both I/O and memory usage.

c) The Intel EM64T looks to be a PAE-ish bag on the side of a Xeon.

No option of 64 bit device access; it's all just a mapping onto 32 bit
stuff.  I haven't had any EM64T boxes inflicted on me; all I know
there is hearsay.

In any case, all of this sucks, really quite badly.

If you DON'T CARE about system performance, and are prepared to pay
pretty big money for hardware that *won't* bear up if it sees load,
then, while there's no accounting for taste, feel free to do so.

Feel free to run Windows 2003 and IIS if you like, as well.

> Backends are a whole different discussion.

A web server is indeed the back end for web activities.

> Advice much appreciated... Charity?  Move along... move along.
--
http://www3.sympatico.ca/cbbrowne/linux.html
Oddly enough, this is completely standard behaviour for shells. This
is a roundabout way of saying `don't use combined chains of `&&'s and
`||'s unless you think Gödel's theorem is for sissies'.
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml