Re: Fwd: AMD x2 chips

Bill Broadley <[email protected]> wrote:
> Not sure what the definition of physical is here.  It's different
> than say a dual opteron single socket system.  There is no
> hypertransport between the two cores.

There is no Socket and HyperTransport trace on a mainboard, no.

Since the A64 x2 or Opteron xx5 model uses a single socket, you only
get 384 traces (128-bit memory) whereas two, physical Socket-940
sockets will give you two sets of 384 traces.  In fact, some "cheap"
Opteron 2xx mainboards have DDR memory channels connected to only *1*
Opteron 2xx.  A system diagram such as follows:  


But inside the A64 x2 or Opteron xx5, you have several ICs.  It
various on implementation, but the commonality is that not much is
changed from external as glueless HyperTransport interfaces are used.
 That really makes life easier for AMD.

I haven't researched if 1) each core gets a single DDR channel, 2)
one core is wired with both DDR channels and the other core accesses
it over HyperTransport or 3) neither core has memory directly
attached, and accessed over HyperTransport where the actual DDR
controller is at.  A few enthusiast sites report #3, but I've found
many enthusiast sites to be incorrect.

> Nor "_two_different" or "_physical", although I suspect it's just a
> terminology difference.  Both cores share the same die.

Same die != same IC.  But yeah, it's easy to use terminology that
isn't consistent or is confusing.  My apologies.

> AMD dual cores processors are on a single die, with a single
> connection to memory, and a single connection to hypertransport.

External memory and external HyperTransport, yes.
But how they are connected internally, it's _not_ bridging.

> So the motherboard sees no difference between a single core
> and a dual core.

Actually, that's how the processor makes itself appear to the APIC. 
That really opens up a can-o-worms in general when we start looking
at how the mainboard POST sees X, how the system OS seems Y, etc...

> There is a small difference in the CPU initialization, so make
> sure your motherboard/BIOS mentions support for dual core AMD
> chips.

Yes, because the APIC needs to be setup correctly.

> Both cores are behind a system request interface (SRI), and a
> crossbar.

But what is that crossbar using?  Is it HyperTransport?  From my
understanding, it is -- all glueless.  Or is it a localized EV6
crossbar (which can be up to 16 nodes)?  I assume not, because that
would add more complexity.

My further question is how is the memory connected.  One DDR channel
to each IC/core?  Both DDR channels to one IC/core?  Or the memory
into that crossbar and _not_ directly connected to either core?
 
> I wouldn't expect any problems from the newer RHEL or Fedora
> distributions.

The APIC handles pretty much all that.  The only consideration is
more performance -- like processor affinity for programs and I/O.

> Of course this only doubles performance (at the same clock speed)
> if your code is relatively cache friendly, since your sharing a
> single memory bus between 2 cores.

The L1 cache is localized to each IC/core.

The L2 cache seems to also be localized to each IC/core, although I
haven't verified this.

Again, how the memory is physically connected to each IC/core inside
the package, I don't know.  There's a lot of conflicting info out
there.  I guess it's time I just read the AMD spec sheets.

> From my experience even memory intensive codes often scale in the
> 1.5-1.8 times faster range.  Worst case, of course, is 0% faster.
> Actually the worst I've seen is around 5-10%, even on completely
> memory bound code a dual core seems to manage to keep the memory
> bus slightly busier.

Which _would_ suggest that HyperTransport extends internally.  One of
the downsides of HyperTransport is that it is a broadcast approach.


-- 
Bryan J. Smith     Professional, Technical Annoyance
[email protected]      http://thebs413.blogspot.com
----------------------------------------------------
*** Speed doesn't kill, difference in speed does ***

-- 
amd64-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/amd64-list