[CentOS] maximum cpus/cores in CentOS 4.1

[Bryan J. Smith]

Joshua Baker-LePain <jlb17 at duke.edu> wrote:
> One has to be even more careful with terminology these
> days.  You can see less memory bandwidth per *core* with
> dual core Opterons. 

Correct.

> But, as you point out, each CPU (socket -- what should we
> call it?)

Yes, that's what I try to do.  S[ocket]940.

> has, essentially, its own bank** of memory.

S754 has one (1), glueless, 184-trace 64-bit DDR channel**.
S939/940 has two (2), glueless, 184-trace 64-bit DDR
channels.**

_All_ other PC sockets do not have memory channels.  They
have a "front side bus" (FSB) to a bridge.  Many of these
lines are multiplexed with others.

All Intel GTL platforms bridge into a "hub" all components
share -- hence Memory Controller Hub (MCH).  Intel S370 and
478 (not to be confused with S423, which uses Rambus, long
story) and others have logically (data-wise, which may be
muxed with address, control, etc...) _only_ one (1) 64-bit
memory channel.  Any "dual channel" marketing is an
interleaving hack done at the MCH.  Intel S603, 604 and 775
logically have two (2) 64-bit memory channels.  Intel
sometimes "widens" the GTL logic at the MCH for 4-way
servers, although that requires additional support.

Digital EV6 platforms have ports (up to 16) into a "crossbar
switch."  The logical front-side bus is also 64-bit,
including S462.  Again, any claims of "dual DDR" is actually
an interleaving hack, done in an attempt to reduce latency
and increase overall throughput.  But it is not the same as
S939/940's _true_ 368 traces for a _true_ 128-bit DDR.

[ **ANAL NOTE:  The term "bank" in traditional PC/RISC
architecture actually 32-bit.  So a 64-bit DIMM is 2 banks. ]

BTW, AMD multi-cores simply use an internal HyperTransport. 
They are ultra-simple to design.

Intel, on the other hand, uses a bridge for dual-core, which
has massive limitations.  This is why Intel is moving towards
dual-ported FSBs, because it's just an evolution of what
they've done with dual-core internally to the IC package.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)