You're not making sense wrt AMD memory arrangements - capacity is only an
issue in that it loads up the channel with mutiple ranks. Where did you
get this stuff? Why did you bring up an extreme case with 128GB of memory?
Is that the basis of support for your contentions?
I specifically demonstrated that several memory capacities require the
user to lower the speed. 48GB+ for HP boxes, and I don't think many
other folks have K8 boxes that go more than 32GB.
I think not. If TPC benefited greatly from cache then I don't see its
applicability to the target market... which would be err, futile.
TPC-C definitely benefits from bandwidth, although not linearly since
cache helps provide effective bandwidth. Your second sentence is
entirely incomprehensible...
Huh? You really think price is related to cost?
Well, actually it is, just weakly. My point was that if it was a
quality of DRAM/DIMM issue, HP would be able to simply use higher
cost/quality memory. However, they don't...which seems to imply it's
not a quality issue and has more to do with the rank limitations and
the design of the memory controller and DDR bus.
[snip]
Can you cite examples in the 2P & 4P realm of Intel based systems
running the memory slower to achieve high capacity? I cannot, but I
may very well be overlooking stuff.
Unless you have a very recent DIB system, the Intel Xeon multi-drop FSB is
derated (vs. an equivalent P4 system) anyway.
As it so happens I do have such a box : ) The dual busses are useful
for keeping pace with initial multicore designs. Once Intel does
shared caches, they won't have as many problems with FSB speeds.
Ah, so what is this here "box"? I wasn't aware that there were any DIB
systems in the err, wild... apart from IBM Hurricane based?... or are you
saying you have access to Intel prototype systems?
Yes, I have a Bensley system sitting next to my desk. I wrote an
article about it, using at least one or two relevant benchmarks:
http://www.realworldtech.com/page.cfm?ArticleID=RWT112905011743
You can find SPECjbb2005 results in there for a very modestly
configured box, that is one benchmark that I can use. Also, I believe
Intel's reference Xeon MP platform uses two busses. However, the
independence of the busses in blackford is....minimal. The two busses
are independent when using a snoop filter (i.e. a partial directory).
Blackford does not use a snoop filter, Green Creek (the work station
version) does.
Feel free to suggest other benchmarks for future inclusion...
Yeah please do check it... and the effective bandwidth. From what I see
Xeons just don't do very well in bandwidth tests compared with equivalent
speed P4s. In fact AMD can well afford to drop a speed grade, if
necessary, and still be well ahead.
I suspect that the timing for the bus may be slightly different, but
they are the same MT/s for 1-2P systems. Also, most P4 systems don't
use registered, ECC DIMMs, while most Xeon systems do.
Generally, Intel's bus works for 3 drops (i.e. MCH, and 2 processors),
it starts to drop off in speed at more drops. The problem with their
systems right now is that the Paxville MPUs have 2 bus interfaces, so a
2 socket system can have as many as 5 controllers trying to talk.
Can do?... or will do? I'm interested in what can be done practically and
not some projected vapor using a memory channel technology which is looking
less and less practical, the more we see of it. As for the current
chipsets, the results I've seen do not reflect the supposed theoretical
MT/s.
Can do. It can also do 1333MT/s, but Dempsey does not do 1333, while
Woodcrest does. The system I have uses two 1066MT/s busses.
[snip]
It's a while since I looked and I don't have time right now, but this issue
has been discussed here before wrt tpc benchmarks - it's more than
"usually"... it's quite consistent.
I agree that every sign I've seen points to the fact that for TPC-C,
DB2 is better than MSSQL. However, there are 2-3 comparable systems
tested with both. Also, most of the DB2 submissions are for AIX
systems, which for now, tend to perform better than others. Again, you
can see trends, but there are so many other variables contributing to
them; the only way to control for OS, memory, storage, etc. is to get
identical or near identical systems for comparison. Unfortunately,
there are only 2-3 of those at best.
The *point* is that the differences between DB2 and SQL Server systems are
massive compared with any hardware differences - a few MHz here or there is
not going to come close to those kinds of gaps. Insisting on "identical"
is unnecessary... and piddling.
I guess it depends on how much you are willing to assume or know about
DBMS. I honestly don't consider myself an expert, so I tend to place
more faith in statistics than other sources. If Jim Gray came along
and said that DB2 performs better than MSSQL, I'd probably believe him,
but it's hard to ascertain someone's level of experience over the
internet.
Bandwidth boosts just do *not* result in huge differences in effective
performance... as reflected in the HP score as is.
It all depends on the system...if you look at queuing theory models
(which apply to TPC-C, since the benchmark has to be in equilibrium),
increasing bandwidth can be very helpful. Obviously,
d(tmpc)/d(bandwidth) < 1 usually, but it would be a really interesting
experiment to take a K8 and P4 based system and then underclock the
memory and see how benchmark scores vary. I just don't use or know
TPC-C...nor do I have a license, nor do I have clients, nor do I have
the requisite number of disks.
David
