From: | William Yu <wyu(at)talisys(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: UltraSPARC versus AMD |
Date: | 2005-04-23 09:58:14 |
Message-ID: | d4d67o$2kfb$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)postgresql(dot)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(at)postgresql(dot)org)
>
From | Date | Subject | |
---|---|---|---|
Next Message | Typing80wpm | 2005-04-23 11:45:58 | Intuitive Software and Mario Brothers |
Previous Message | Craig Bryden | 2005-04-23 09:45:43 | PRIMARY KEY and indexes |