From: William Yu <wyu@talisys.com>
To: Greg Stark <gsstark@mit.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: ok you all win what is best opteron (I dont want a
Date: Sun, 15 May 2005 13:39:39 -0700
Message-ID: <4287B38B.506@talisys.com> (raw)
In-Reply-To: <871x8846z9.fsf@stark.xeocode.com>
References: <4285403A.50206@bigpond.net.au>
<00e201c558b1$730ffb10$797ba8c0@jfradkin>
<d66601$30l6$1@news.hub.org>
<871x8846z9.fsf@stark.xeocode.com>
I say most apps because it's true. :) I would suggest that pretty much
every app (other than video/audio streaming) people think are
bandwidth-limited are actually latency-limited. Take the SpecFoo tests.
Sure I would have rather seen SAP/TPC/etc that would be more relevant to
Postgres but there aren't any apples-to-apples comparisons available
yet. But there's something to consider here. What people in the past
have believed is that memory bandwidth is the key to Spec numbers --
SpecFP isn't a test of floating point performance, it's a test of memory
bandwidth. Or is it? Numbers for DC Opterons show lower latency/lower
bandwith beating higher latency/higher bandwidth in what was supposedly
bandwidth limited. What may actually be happening is extra bandwidth
isn't actually used directly by the app itself -- instead the CPU uses
it for prefetching to hide latency.
Scrounging around for more numbers, I've found benchmarks at Anandtech
that relate better to Postgres. He has a "Order Entry" OLTP app running
on MS-SQL. 1xDC beats 2x1 -- 2xDC beats 4x1.
order entry reads
2x248 - 235113
1x175 - 257192
4x848 - 360014
2x275 - 392643
order entry writes
2x248 - 235107
1x175 - 257184
4x848 - 360008
2x275 - 392634
order entry stored procedures
2x248 - 2939
1x175 - 3215
4x848 - 4500
2x275 - 4908
Greg Stark wrote:
>William Yu <wyu@talisys.com> writes:
>
>
>
>>It turns out the latency in a 2xDC setup is just so much lower and most apps
>>like lower latency than higher bandwidth.
>>
>>
>
>You haven't tested anything about "most apps". You tested what the SpecFoo
>apps prefer. If you're curious about which Postgres prefers you'll have to
>test with Postgres.
>
>I'm not sure whether it will change the conclusion but I expect Postgres will
>like bandwidth better than random benchmarks do.
>
>
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: wyu@talisys.com, gsstark@mit.edu
Subject: Re: ok you all win what is best opteron (I dont want a
In-Reply-To: <4287B38B.506@talisys.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox