Are we in the ballpark?

We're building a new database box. With the help of Gregory Smith's
book, we're benchmarking the box: We want to know that we've set it up
right, we want numbers to go back to if we have trouble later, and we
want something to compare our _next_ box against. What I'd like to know
is, are the performance numbers we're getting in the ballpark for the
class of hardware we've picked?

First, the setup:

CPU: Two AMD Opteron 6128 (Magny-Cours) 2000 mHz, eight cores each
RAM: DDR3-1333 64 GB (ECC)
RAID: 3Ware 9750 SAS2/SATA-II PCIe, 512 MB battery backed cache,
write-back caching enabled.
Drives: 16 Seagate ST3500414SS 500GB 7200RPM SAS, 16 MB cache:
2 RAID1 ($PG_DATA/xlog)
12 RAID10 ($PG_DATA)
2 hot spare
PostgreSQL 8.4.1 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.3.real
(Debian 4.3.4-2) 4.3.4, 64-bit
File system: XFS (nobarrier, noatime)
i/o scheduler: noop

Database config (differences from stock that might affect performance):
shared_buffers = 8192MB
temp_buffers = 16MB
work_mem = 192MB
maintenance_work_mem = 5GB
wal_buffers = 8MB
checkpoint_segments = 64
checkpoint_completion_target = 0.9
random_page_cost = 1.0
constraint_exclusion = on

Now, the test results:

Memtest86+ says our memory bandwidth is:
L1 32,788 MB/S
L2 is 10,050 MB/S
L3 is 6,826 MB/S

Stream v5.9 says:
1 core: 4,320
2 cores: 8,387
4 cores: 15,840
8 cores: 23,088
16 cores: 24,286

Bonnie++ (-f -n 0 -c 4)
$PGDATA/xlog (RAID1)
random seek: 369/sec
block out: 87 MB/sec
block in: 180 MB/sec
$PGDATA (RAID10, 12 drives)
random seek: 452
block out: 439 MB/sec
block in: 881 MB/sec

sysbench test of fsync (commit) rate:

$PGDATA/xlog (RAID1)
cache off: 29 req/sec
cache on: 9,342 req/sec
$PGDATA (RAID10, 12 drives)
cache off: 61 req/sec
cache on: 8,191 req/sec

pgbench-tools:

Averages for test set 1 by scale:
avg_
set clients tps latency 90%< max_latency
1 1 29141 0.248 0.342 5.453
1 10 31467 0.263 0.361 7.148
1 100 31081 0.265 0.363 7.843
1 1000 29499 0.278 0.365 11.264

Averages for test set 1 by clients:
avg_
set clients tps latency 90%< max_latency
1 1 9527 0.102 0.105 1.5
1 2 13850 0.14 0.195 5.316
1 4 19148 0.19 0.251 2.228
1 8 44101 0.179 0.248 2.557
1 16 50311 0.315 0.381 11.057
1 32 47765 0.666 0.989 24.076

We've used Brad Fitzpatrick's diskchecker script to show that the i/o
stack is telling the truth when it comes to fsync.

Are there any nails sticking up that we need to pound on before we start
more extensive (real-world-ish) testing with this box?