Re: UltraSPARC versus AMD - Mailing list pgsql-general

From William Yu
Subject Re: UltraSPARC versus AMD
Date
Msg-id d4d67o$2kfb$1@news.hub.org
Whole thread Raw
In response to Re: UltraSPARC versus AMD  ("Uwe C. Schroeder" <uwe@oss4u.com>)
Responses Re: UltraSPARC versus AMD  (Ben <bench@silentmedia.com>)
List pgsql-general
Oh I'm sure in the past, Sun had way better I/O performance. But the gap
at least for entry-level servers has closed quite a lot with HT,
Inifiband, PCI-X, PCIe and so on available on for x86. Most x86 2P/4P
server MBs I've seen seem to have 2 PCI-X bridges, 1 PCI bridge and
separate bridges for 2x Gigabit Ethernet -- easily 2+GB of I/O available.

Now the latest craze is PCIe. For example, the Tyan S2895 has 3 HT
(6.4GB/s) connections used for I/O. #1 has PCIe x16 (8GB) + GigE, #2 has
PCIe x16 + GigE + SATA + IDE, #3 has PCI-X 133 (1GB) + PCI-X 100 (.75GB)
+ PCI. If you could find the right cards to max out the system, we're
looking at 14+ GB/s of I/O. Unfortunately, the PCIe SCSI RAID controller
selection is pretty sparse right now. There's a PCIe x8 (4GB/s) card
from Intel but it's only has 2 U320 channels so it's way underutilizing
the available bandwidth.

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.


Uwe C. Schroeder wrote:
> Well, you overlook one thing there. SUN has always has a really good I/O
> performance - something far from negligible for a database application.
> A lot of the PC systems lack that kind of I/O thruput.
> Just compare a simple P4 with ATAPI drives to the same P4 with 320 SCSI drives
> - the speed difference, particularly using any *nix, is surprisingly
> significant and easily visible with the bare eye.
> There is a reason why a lot of the financial/insurance institutions (having a
> lot of transactions in their DB applications) use either IBM mainframes or
> SUN E10k's :-)
> Personally I think a weaker processor with top of the line I/O will perform
> better for DB apps than the fastest processor with crappy I/O.
>
> i guess the "my $0.02" is in order here :-)
>
> UC
>
>
> On Saturday 23 April 2005 01:06, William Yu wrote:
>
>>Looked on AMD's website. 132 for 4x875 on Windows, 126 on Linux.
>>(Probably Intel compiler on Windows, gcc on Linux.) That gets AMD into
>>the $100K 16+ processor Sun system area in terms of performance. Of
>>course, Sun still has a crapload of other uptime/reliability features
>>built-in to their systems.
>>
>>William Yu wrote:
>>
>>>The numbers don't have the latest dual core Opterons yet. (Don't see
>>>them on spec.org yet either.) My random guess right now, 4x2 system
>>>would probably be about 140 SpecINT_rate. It's looking like it's faster
>>>than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory
>>>bank because the interconnect between cores inside a DC CPU is so much
>>>faster than the HT motherboard connect.
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 2: you can get off all lists at once with the unregister command
>>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>
> --
> Open Source Solutions 4U, LLC    2570 Fleetwood Drive
> Phone:  +1 650 872 2425        San Bruno, CA 94066
> Cell:   +1 650 302 2405        United States
> Fax:    +1 650 872 2417
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

pgsql-general by date:

Previous
From: "Craig Bryden"
Date:
Subject: PRIMARY KEY and indexes
Next
From: "Sean Davis"
Date:
Subject: Re: PRIMARY KEY and indexes