Re: 4-way Opteron vs. Xeon-IBM X3 architecture



George Macdonald <fammacd=!SPAM^nothanks@xxxxxxxxxxxxx> wrote:
> On Fri, 30 Dec 2005 20:51:42 +0000 (UTC), David Wang <foo@xxxxxxxxxxx>
> wrote:

> >The point here is that the issue concerns both speed AND capacity.
> >The references given suggest that higher speeds are possible, but
> >none shows that higher speeds are possible with full capacity.

> Depends what you mean by "full capacity" - if you mean eight quad-rank
> DIMMs then the memory mfrs don't even make PC3200 in that form factor; if
> you look at the mbrds available to us, eight slots per CPU is not something
> I've seen. OTOH right in this thread is a "reference"
> 11r8donj9u00g9d@xxxxxxxxxxxxxxxxxx apparently demonstrating PC3200
> operation with 72 devices per channel.

I've already defined what I meant by "full capacity". 4 ranks of
DRAM devices, 18 devices per rank, 72 devices per channel running
at 400 Mb/s.

As to the reference, the message header points right back in this thread,
and there's nothing in that post that shows 72 devices per channel @
400 Mb/s.



> >As you may suspect, I read plenty about memory systems, and I would
> >vigorously challenge your memory in regards to the "common knowledge"
> >here. I do not believe it's common knowledge for anyone to have
> >demonstrated running 64 DDR(1) SDRAM devices reliabliably @ 400 Mb/s.
> >If you can, please do cite a concrete reference URL. What you remember
> >to have seen may not actually be what it is.

> See above.

There's nothing in the referenced post.



> >The issue that prohibits making the higher speed version with x4 devices
> >is that you have to hang 16 of them (18 with ECC) on the same address
> >and command busses per rank. That's a rather heavy electrical load to
> >run @ 200 MHz. So, no, you can't just look at "enthusiast memory" built
> >with x8 parts and automatically assume that x4 parts will work just the
> >same at the same data rate, because you're going to need even faster
> >parts to meet the same timing.

> The memory mfrs are producing PC3200 2GB RDIMMs with 36 devices.<shrug>

You need them to make PC3200 4 GB RDIMMs with 36 devices and work in the
2 slot boards to get to 8 GB per channel and 16 GB per CPU. Once you have
that, then you can raise the memory capacity of the 4P Opteron box to
64 GB. Until then, the limit for the 4P Opteron box remains as 32 GB of
DDR(1) @ 400 Mb/s.



> >Because you cited some rather nebulous references in regards to memory
> >from the enthusiast market and assumed that it would work in the server
> >world. I was simply pointing out that's not going to work here because
> >of configuration differences and electrical loading considerations.

> AMD has specs. They can be exceeded and have been regularly for Athlon64
> unbuffered operation; it does seem that the specs for Opteron registered
> could be and in fact are easily exceeded.

No one running a 4P server and using it commercially will run the box with
memory system configuration that exceeds spec.



> >Which is what is shipping in HP's Opteron server, and guarenteed to
> >work by HP. That guarentee provides the effective upper limit to
> >the maximum memory capacity of an Opteron server as of today. That
> >limit cannot be exceeded or changed arbitrarily. This, I believe was
> >the crux of the contentious point. . .

> The original claim was that anything "> half-loaded" required a decrease in
> clock speed; even AMD specs go above half-loaded.

That claim is supported by the specification of a validated, shipping
system. Your argument that the server folks can run with more memory
in the memory system by pushing the configuration beyond the validated
spec - does not hold water.


> >The difference is that CPU's and GPU's are single vendor to single customer
> >parts. That is, Intel can change the specs of these devices to whatever
> >it wants, whenever it wants, as long as its customers doesn't mind
> >following the new spec. Same with AMD, NVIDIA, ATI, etc. DRAM doesn't
> >work that way. The dynamics of the commodity market means that the parts
> >are supposed to be completely interchangeable. So the "interchangeable"
> >aspect of things greatly limits the standards definition process.

> Times have changed - we can now tweak the voltages of about every part of
> the system from software. We now have gone as far as CPUs with variable
> voltage specs. For memory there's up to .5V boost for some mbrds in .05V
> increments; saying you shouldn't do that because it violates some old spec
> is nuts. Would I personally run server memory at 3V - no! Would I go up
> to 2.75V?... if it gave me a worthwhile performance advantage, probably.

I have never heard of any IT manager sitting around tuning the voltage on
the CPU or memory of his/her latest 4P Opteron/Xeon box. This scenario
sounds rather far fetched.


> >For example, Samung can probably crank out much faster DDR parts because
> >it has excellent process tech, but some of the less-well funded fabs
> >can barely meet the spec, and they would be hard pressed to meet these
> >push spec parts, so they would be resistant to changes in the JEDEC
> >standards definition.
> >
> >The limitation of the JEDEC standard means that the faster guys can't
> >really run ahead of the slow guys, although they're finding some ways
> >around that with the push spec parts designed for the "enthusiast
> >market". So, no, you can't just take advantage of opportunities
> >made available with faster process technology to make your own faster
> >DRAM parts. You have to wait until sufficient number of DRAM manufacturers
> >can agree with you on the new addendum to the spec, and a suffient
> >number of design houses (Intel, IBM, Sun, AMD, etc etc) agree to the
> >same set of proposed addendum to the spec, before the standard can be
> >created, and you can sell you part as (JEDEC) DDRx xyz MHz, and customers
> >can be reasonably certain that your DDRx xyz MHz parts can operate
> >interchangeably with parts from Infineon, Samsung, Micron, Elpida,
> >etc.

> Every DIMM mfr is selling unbuffered boutique parts rated at PC4000/DDR500
> (2.8V seems the norm) - where they get the chips from matters not...
> whether it violates some enshrined, 3-year-old JEDEC document is of no
> importance to the people selling or buying.

No one buys these parts to put in a 4P Opteron/Xeon server, and the
sentiment does not apply.


> >They'll enable servers with incredible amount of memory, and the power
> >headache that comes with it. The AMB is just part of the problem. With
> >16 device per FBD, you can get the ratio of AMB device power to DRAM
> >device power down to 15~20%.

> But the AMB power usage must depend on its position in the channel... so
> are they going to be able to be able to lose the heatpipes on them?:-)
> Surely the Primary is always going to get hammered.

Heatpipes? From what I've seen, it's just a small heatsink. I think
it's about ~4W per fully-on AMB, and you can selectively turn off
parts of it to save power.























--
davewang202(at)yahoo(dot)com
.



Relevant Pages

  • Re: 4-way Opteron vs. Xeon-IBM X3 architecture
    ... >>>The point here is that the issue concerns both speed AND capacity. ... >As to the reference, the message header points right back in this thread, ... >>>As you may suspect, I read plenty about memory systems, and I would ... >>>from the enthusiast market and assumed that it would work in the server ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: 4-way Opteron vs. Xeon-IBM X3 architecture
    ... I did not see any concrete reference other than to THG. ... >reliably add more memory to the Opteron system @ 400 Mb/s. ... >> With the right devices and with registering the server market should be ... >following the new spec. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: question--function returns class object(comparing C++ & JAVA)
    ... that the reference IS exactly the memory address. ... So depending on whether you're talking within or outside the language ... guaranteed as such by any spec) to say that a reference is a memory ...
    (comp.lang.java.programmer)
  • Re: question--function returns class object(comparing C++ & JAVA)
    ... > good that the reference IS exactly the memory address. ... > (though not guaranteed as such by any spec) to say that a reference is ... Java, like you said, a reference is not defined as being a memory address, ...
    (comp.lang.java.programmer)
  • Re: 4-way Opteron vs. Xeon-IBM X3 architecture
    ... > seen such discussion of memory configs in almost all. ... > With the right devices and with registering the server market should be ... Which is what is shipping in HP's Opteron server, ... following the new spec. ...
    (comp.sys.ibm.pc.hardware.chips)