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?