Re: UltraSPARC versus AMD - Mailing list pgsql-general

From Richard_D_Levine@raytheon.com
Subject Re: UltraSPARC versus AMD
Date
Msg-id OF773F47F7.3A13AB4C-ON05256FEE.00521463-05256FEE.0053F6F9@ftw.us.ray.com
Whole thread Raw
In response to Re: UltraSPARC versus AMD  (Ben <bench@silentmedia.com>)
Responses Re: UltraSPARC versus AMD  (Mike Mascari <mascarm@mascari.com>)
List pgsql-general
I am looking at options for a customer with an installed base of ~5000 Sun
workstations running 400-500MHz UltraSPARCs.  They're not getting the
performance they need.  They shipped me two Tadpole Bullfrog machines, a
Bullfrog I and a Bullfrog II for evaluation.

http://www.tadpole.com

1.28GHz single or dual CPU UltraSPARCs.  On board SCSI, but they installed
IDE drives instead.

In my *utter* lack of enthusiasm over this option, I was gathering
ammunition for better hardware.  I went to spec.org for speed comparisons,
and sun.com for price comparisons.  Sun's *entry* level servers are more
powerful when running AMD CPUs.

I note with interest and appreciation comments about the bigger iron from
Sun and IBM.  That's not what I'm in the market for, but good info as
always.

My evaluation is that a single or dual core AMD 64 Athlon in a rugged
laptop is going to give a performance enhancement (SPECMark wise) of about
an order of magnitude over their current hardware base.  And it's cheaper.

The current hardware base contains a 10k SCSI Fast Wide Ultra single disk
on a 440MHz CPU as well as a 7200 IDE on a 500MHz CPU.  The SCSI with the
slower CPU runs the application 8% faster.  Obviously I'll need to work on
the proper I/O subsystem because that's apparently more of a limiter than
the CPU speed.

Cheers,

Rick

pgsql-general-owner@postgresql.org wrote on 04/23/2005 11:02:17 AM:

> As someone who works in a nationwide bank, let me tell you why we
> choose IBM and Sun hardware: support. If we want to get a server for a
> project, we can't just go get the most cost-efficient thing out there
> for the job. We have a short list of servers that can be picked from,
> and that's it. A given server makes it onto that list if and only if it
> can be supported by a vendor in a matter of hours for at least 3 years.
> We don't always purchase that support, but bank policy says it has to
> be an option.
>
> We don't generally purchase monster machines. Sure, there are some
> mainframes, but they are few and far between. Everything else doesn't
> really have anything more than 32 procs.
>
> On Apr 23, 2005, at 2:58 AM, William Yu wrote:
>
> > As for why financial/insurance institutions use IBMs or Suns -- I
> > would suggest limited choice is a bigger issue than any specific
> > sub-system performance factor. A nationwide bank doesn't have any
> > choice except to pick a monster 100+ processor machine because
> > anything slower couldn't handle their 20,000 employees. Not many
> > options really. Plus, people in big companies tend to make safe
> > decisions -- get the company with the most name value so you don't get
> > fired if the machine turns out to be a lemon.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster


pgsql-general by date:

Previous
From: Alex Turner
Date:
Subject: Re: Hosting Service Recommendations
Next
From: Tom Lane
Date:
Subject: Re: What does "tuple concurrently updated" mean?