| Author |
Message |
Rob Stow
Guest
|
 Posted:
Tue Nov 01, 2005 5:15 pm Post subject:
Re: AMD to leave x86 behind? |
|
|
Del Cecchi wrote:
| Quote: | "Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:dtJ9f.4402$LF3.395983@news20.bellglobal.com...
Terje Mathisen wrote:
I don't get it, your diagram seems to be only a different permutation
of
Rob's diagram. The only difference, in yours is that you got CPU5
connecting to CPU6 and CPU4 to CPU7, whereas in Rob's it was CPU4 to
CPU6 & CPU5 to CPU7. That little "x" you put in between doesn't
represent a shortcut, it represents one line going over the other but
not touching.
Listing all of the 3 hop combinations in yours and Rob's, this is what
I
get.
Rob:
1: CPU0-CPU1: 0-2-3-1
2: CPU0-CPU5: 0-2-3-5 or 0-2-4-5
3: CPU1-CPU4: 1-3-2-4 or 1-3-5-4
4: CPU2-CPU7: 2-4-5-7 or 2-3-5-7
5: CPU3-CPU6: 3-2-4-6 or 3-5-4-6
David:
1: CPU0-CPU1: 0-2-3-1
2: CPU0-CPU5: 0-2-3-5 or 0-2-4-5
3: CPU1-CPU4: 1-3-2-4 or 1-3-5-4
4: CPU2-CPU6: 2-4-5-6 or 2-3-5-6
5: CPU3-CPU7: 3-2-4-7 or 3-5-4-7
Only #4 & #5 are different between your two respective diagrams.
I think you've missed a key feature of that cross:
2: CPU0-CPU5: 0-6-5
3: CPU1-CPU4: 1-7-4
4: CPU2-CPU6: 2-0-6
5: CPU3-CPU7: 3-1-7
I.e. only the CPU0-CPU1 link has to pass over three hops.
Okay, I stand corrected. Now one question arises from this. How do the
Opterons themselves know how to handle the message passing between
themselves? Do they just broadcast out in every direction and hope it
gets there with the smallest route, and ignore any duplicates coming in
later from non-optimal routes? Or is there a lookup table that gets
programmed into each CPU telling it which direction to send each
message?
Yousuf Khan
I have never heard that the multiple HT ports include a switch or a
routing table. My guess is that a broadcast protocol is used.
|
At least for memory requests it I think it would have to be a
broadcast protocol because the caches have to be snooped on all CPUs. |
|
| Back to top |
|
 |
Patrick Schaaf
Guest
|
| Posted:
Tue Nov 01, 2005 5:15 pm Post subject:
Re: AMD to leave x86 behind? |
|
|
Yousuf Khan <bbbl67@ezrs.com> writes:
| Quote: | Okay, I stand corrected. Now one question arises from this. How do the
Opterons themselves know how to handle the message passing between
themselves? Do they just broadcast out in every direction and hope it
gets there with the smallest route, and ignore any duplicates coming in
later from non-optimal routes? Or is there a lookup table that gets
programmed into each CPU telling it which direction to send each message?
|
There is an elaborate set of special purpose registers, which is used
at system startup to configure routing tables in each processor,
for memory address ranges and I/O stuff, IIRC. This is presumably
done by the BIOS.
There's a "BIOS and kernel programmer's guide" somewhere on the AMD
site, which describes this in detail. Pub.Nr #26094 from the copy
I find lying around here.
best regards
Patrick |
|
| Back to top |
|
|
Yousuf Khan
Guest
|
| Posted:
Tue Nov 01, 2005 5:15 pm Post subject:
Re: AMD to leave x86 behind? |
|
|
Tim McCaffrey wrote:
| Quote: | Performance doesn't necessarily mean FP performance. For instance, the
x86 interrupt model really needs a re-think (especially since x86-64
doesn't really support the segmentation model). Something like
the ARM's register sets would be nice.
|
What specifically about the interrupt model is the problem?
Yousuf Khan |
|
| Back to top |
|
|
Yousuf Khan
Guest
|
| Posted:
Tue Nov 01, 2005 5:15 pm Post subject:
Re: AMD to leave x86 behind? |
|
|
Terje Mathisen wrote:
| Quote: | I don't get it, your diagram seems to be only a different permutation of
Rob's diagram. The only difference, in yours is that you got CPU5
connecting to CPU6 and CPU4 to CPU7, whereas in Rob's it was CPU4 to
CPU6 & CPU5 to CPU7. That little "x" you put in between doesn't
represent a shortcut, it represents one line going over the other but
not touching.
Listing all of the 3 hop combinations in yours and Rob's, this is what I
get.
Rob:
1: CPU0-CPU1: 0-2-3-1
2: CPU0-CPU5: 0-2-3-5 or 0-2-4-5
3: CPU1-CPU4: 1-3-2-4 or 1-3-5-4
4: CPU2-CPU7: 2-4-5-7 or 2-3-5-7
5: CPU3-CPU6: 3-2-4-6 or 3-5-4-6
David:
1: CPU0-CPU1: 0-2-3-1
2: CPU0-CPU5: 0-2-3-5 or 0-2-4-5
3: CPU1-CPU4: 1-3-2-4 or 1-3-5-4
4: CPU2-CPU6: 2-4-5-6 or 2-3-5-6
5: CPU3-CPU7: 3-2-4-7 or 3-5-4-7
Only #4 & #5 are different between your two respective diagrams.
I think you've missed a key feature of that cross:
2: CPU0-CPU5: 0-6-5
3: CPU1-CPU4: 1-7-4
4: CPU2-CPU6: 2-0-6
5: CPU3-CPU7: 3-1-7
I.e. only the CPU0-CPU1 link has to pass over three hops.
|
Okay, I stand corrected. Now one question arises from this. How do the
Opterons themselves know how to handle the message passing between
themselves? Do they just broadcast out in every direction and hope it
gets there with the smallest route, and ignore any duplicates coming in
later from non-optimal routes? Or is there a lookup table that gets
programmed into each CPU telling it which direction to send each message?
Yousuf Khan |
|
| Back to top |
|
|
David Hopwood
Guest
|
| Posted:
Tue Nov 01, 2005 11:38 pm Post subject:
Re: AMD to leave x86 behind? |
|
|
Stephen Fuld wrote:
| Quote: | "David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote:
CPU6--------------CPU7
| \_____ ____/ |
| \ / |
| X |
| / \ |
| CPU4---CPU5 |
| | | |
| | | |
| CPU2---CPU3 |
| / \ |
| / \ |
CPU0 CPU1
| |
| |
Chipset Chipset
11 one-hops, 16 two-hops, and 1 three-hop.
Is there some technical reason behind the limitation to three HT links or
was it a marketing decision?
|
Well, two HT links would constrain the CPUs to being in a linear chain,
with a maximum hop count of 7 and an average hop count (between two
different CPUs) of 4. So going from two links to three provides a very
significant benefit; going from three links to four much less so. In
fact the best four-link-per-CPU configuration I can find right now only
gets you 14 one-hops and 14 two-hops, although I'm not sure that's optimal.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> |
|
| Back to top |
|
|
David Hopwood
Guest
|
| Posted:
Tue Nov 01, 2005 11:41 pm Post subject:
Re: AMD to leave x86 behind? |
|
|
Yousuf Khan wrote:
| Quote: | David Hopwood wrote:
CPU6--------------CPU7
| \_____ ____/ |
| \ / |
| X |
| / \ |
| CPU4---CPU5 |
| | | |
| | | |
| CPU2---CPU3 |
| / \ |
| / \ |
CPU0 CPU1
| |
| |
Chipset Chipset
11 one-hops, 16 two-hops, and 1 three-hop.
I don't get it, your diagram seems to be only a different permutation of
Rob's diagram. The only difference, in yours is that you got CPU5
connecting to CPU6 and CPU4 to CPU7, whereas in Rob's it was CPU4 to
CPU6 & CPU5 to CPU7. That little "x" you put in between doesn't
represent a shortcut, it represents one line going over the other but
not touching.
Listing all of the 3 hop combinations in yours and Rob's, this is what I
get.
Rob:
1: CPU0-CPU1: 0-2-3-1
2: CPU0-CPU5: 0-2-3-5 or 0-2-4-5
3: CPU1-CPU4: 1-3-2-4 or 1-3-5-4
4: CPU2-CPU7: 2-4-5-7 or 2-3-5-7
5: CPU3-CPU6: 3-2-4-6 or 3-5-4-6
David:
1: CPU0-CPU1: 0-2-3-1
2: CPU0-CPU5: 0-2-3-5 or 0-2-4-5
|
0-6-5
| Quote: | 3: CPU1-CPU4: 1-3-2-4 or 1-3-5-4
|
0-7-4
| Quote: | 4: CPU2-CPU6: 2-4-5-6 or 2-3-5-6
|
2-0-6
| Quote: | 5: CPU3-CPU7: 3-2-4-7 or 3-5-4-7
|
3-1-7
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> |
|
| Back to top |
|
|
Bill Davidsen
Guest
|
| Posted:
Tue Nov 01, 2005 11:52 pm Post subject:
Re: AMD to leave x86 behind? |
|
|
YKhan wrote:
| Quote: | how about some form of SMT for AMD?
I don't know that might come too, but it can't be done as easily as
Hyperthreading. Hyperthreading relied on the Pentium 4's inherent
inefficiency to run a lot of threads simultaneously.
Actually not. It takes advantage of the fact that the CPU has a number |
of instruction units, adders, FPU, etc, which one thread MAY use at once
in some cases, but which are not ALWAYS all in use.
By adding another instruction decoder one or more additional threads can
run using the resources which are otherwise not needed at some clock tick.
Do you believe that AMD uses every execution unit on every cycle?
Hopefully not, which raises the possibility of SMT, at least in theory.
The question is one of benefit, typically on a task such as Linux kernel
build, or a large application build, SMT reduces the clock time by
20-30%. No matter how you spin it, it the task runs in less time I call
the CPU faster.
No, it doesn't help a single threaded task, other than moving the O/S
and display usage into the "other" thread.
--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com |
|
| Back to top |
|
|
Bill Davidsen
Guest
|
| Posted:
Wed Nov 02, 2005 12:52 am Post subject:
Re: AMD to leave x86 behind? |
|
|
Yousuf Khan wrote:
| Quote: | David Kanter wrote:
If you think that any modern MPU is efficient, you are smoking crack.
They all have plenty of unused cycles left on the table (except when
running linpack).
But the secret is to have enough idle cycles to run both threads at
close to full speed each. I'd say anything that had enough to run both
threads at 80% full speed, was a reasonably successful SMT.
|
I suspect you still don't understand SMT... if you had enough idle
cycles to run 2x80% you should either get rid of all the silicon wasted
in idle capacity or add a little more and go full dual core.
Please note: the following is simplified, if someone wants to go into
more detail feel free.
A single thread CPU has some number of execution units, which represent
how many things can be done at once. I think the goal for the original
RISC thinking was "one" at that stage, and the VLIW folk were thinking
"boatloads." Most CPUs are in the middle and the number of things they
can do at once is influenced by the number of stages of the pipeline,
OOE, and other things.
The Intel P4 design uses a long pipeline, and on code without branches
it runs quite well, and is able to do many things at once, therefore has
execution units to allow multiple simultaneous operations. However,
programmers don't write code without branches, therefore some execution
units go unused part of the time. Intel added another op decoder (and
register set) to generate instructions to use those spare units.
Sorry if this is over simplified, chip designers feel free to correct or
expand.
--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com |
|
| Back to top |
|
|
Rob Stow
Guest
|
| Posted:
Wed Nov 02, 2005 1:16 am Post subject:
Re: AMD to leave x86 behind? |
|
|
Stephen Fuld wrote:
| Quote: | "David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message
news:dKN9f.65754$iD.48396@fe2.news.blueyonder.co.uk...
Stephen Fuld wrote:
snip
Is there some technical reason behind the limitation to three HT links or
was it a marketing decision?
Well, two HT links would constrain the CPUs to being in a linear chain,
with a maximum hop count of 7 and an average hop count (between two
different CPUs) of 4. So going from two links to three provides a very
significant benefit; going from three links to four much less so. In
fact the best four-link-per-CPU configuration I can find right now only
gets you 14 one-hops and 14 two-hops, although I'm not sure that's
optimal.
That sounds reasonable but it I believe it assumes eight CPUs. If they
wanted to address the market for larger systems, what are the numbers for 16
or 32 CPUs? They could certainly charge a premium for such systems and you
might be able to have the number of links be a bond out option, thus keeping
their costs low and giving an extra market segment to compete in.
|
Sounds a lot AMD would be making the chips more complicated and
requiring more pins for the additional HT link - just to *not* do
as good a job as Horus appears to be achieving in its early
incarnations. And running all the additional traces across the
motherboards would be a real pain in the butt.
Plus you need to keep in mind that as the number of CPUs grows,
so does the amount of cache snooping that has to occur if there
is no Horus-like intermediary between CPUs or groups of CPUs. |
|
| Back to top |
|
|
Eric P.
Guest
|
| Posted:
Wed Nov 02, 2005 1:16 am Post subject:
Re: AMD to leave x86 behind? |
|
|
Jeremy Linton wrote:
| Quote: |
Eric P. wrote:
Yousuf Khan wrote:
Tim McCaffrey wrote:
Performance doesn't necessarily mean FP performance. For instance, the
x86 interrupt model really needs a re-think (especially since x86-64
doesn't really support the segmentation model). Something like
the ARM's register sets would be nice.
What specifically about the interrupt model is the problem?
The x86 takes an awful lot (thousands) of clocks to do what common
sense tells you shouldn't cost much more than a pipeline drain.
If you wrote down a description of the functionality required
for interrupt handling, then compared your design to how x86
actually works, you can see the appalling cost.
If you look at the x86 System Programmers guide you'll get some
idea why. Segmentation, RPL-DPL protection checks, call gates,
hardware tasking, all of which are not used but cost overhead.
Sadly the x64 continues to drag much of that baggage with it
because it's design must straddle both worlds. Remember that
the x64 had to boot looking like an x86 for compatibility,
so it even supports real and virtual 8086 modes (just in case).
I'm not sure how much of that is really the problem, a few years ago I
did some basic back of the envelope calculations in a similar
discussion. My calculations were based on 100% cache misses for doing
the dozen or so memory reads required to pull in the interrupt vector in
when there wasn't a TLB entry for the IDT or the destination address.
Given a few hundred cycles of latency for each read it quickly became
apparent that short of disabling paging and removing the ability to move
the IDT around in memory it wasn't going to get much faster.
|
Yeah, I agree that cache and TLB misses would greatly add to the
costs. I've been trying to find my original source for those clock
numbers to see whether they are just interrupt overhead costs
(after cache & TLB warming) or include cache and TLB miss costs, but
don't seem to be able to find the sources. I'm pretty sure they would
have warmed the caches. I'm curious so I'll keep poking about.
The current x86 appears to require:
- 5 writes to save old SS, ESP, CS, EIP, EFLAGS
- read interrupt gate from IDT to get new EIP & DPL
- 3 reads for kernel CS, SS and ESP from task TSS for that DPL
- read SS & SS descriptors from GDT/LDT (assuming it cached the
GDT&LDT bases when the TSS was set, otherwise read them too)
- Interrupt routine must immediately save old and load segment register
appropriate for kernel mode (DS, ED, FS, GS) and therefor their
appropriate descriptors.
- So I'm guessing at least 9 writes, 9 reads, and a dozen instructions
before saving any general registers.
- All of the above have a plethora of segment, validity and access
checks (the pseudo code for IRET is quite lengthy).
Now assuming one could toss the entire current design, an interrupt
should take 3 writes (old EFLAGS, EIP, ESP) to push onto the kernel
stack, and 1 read (the new EIP). The kernel stack pointer and eflags
can be stored in protected registers and don't memory access to load.
Segment registers are only used by 32 bit legacy mode apps and
so need not be touched by interrupt handlers, only by task switcher.
The kernel FS and GS, currently used to point to the thread and
processor state records, could also be in special protected registers
and therefore not need to be constantly saved and reloaded.
Another solution would be to bank switch all the segment registers
based on User/Super mode, again saving their save and load.
The absolute best case latency one might think the old state could
be written to an in-cache kernel stack before the pipeline flush was
even complete, so maybe ~40 clocks.
For worst case, assuming 100 ns memory, 2 GHz clock, with cache and
TLB misses, 4 level page table (later lookups hit cache except pte)
I get 7 main memory reads and 2 writes, or 1800 clocks.
With a redesigned MMU then even much of this could be avoided
(bottom up translate, lockable tlb entries, large variable sized
pages mapping whole kernel).
| Quote: | Compared with my ARM7TDMI, which doesn't have paging, and the ISR
vector is fixed in memory (and thereby saved a bunch of time dealing
with memory translation). The real advantage of the ARM was the separate
register space which allowed it to avoid having to setup a separate
stack space. Of course my generic operating environment basically then
has to setup the stack space manually for 99% of the interrupts so that
wasn't really an advantage in the long run. This reinforced what I
thought after working with a PPC interrupt handler, it could handle the
interrupt faster, but then you spend 10x as long manually dealing with
all the crap that the interrupt handler didn't do for you. In the end
its a wash for general purpose computing. On the other hand when your
talking about a hard real time systems with a short latency requirement
the FIQ mode on the ARM starts to look really good. In those enviroments
you don't gererally give a crap about 99% of the stuff a normal OS does
in an interrupt hander, so its not really a fair comparison.
|
It sounds like you are referring to ARMs bank switched register set.
Those are fine if you don't have many interrupt priority levels.
But for a general purpose cpu and OS I can see 8 or more levels:
- Bus error
- Clock
- Power fail
- Inter Processor Interrupt
- External device High
- External device Medium
- External device Low
- Scheduler
which would require at too many register sets. At that point saving
the prior state on a kernel stack seems the best approach.
Eric |
|
| Back to top |
|
|
Stephen Fuld
Guest
|
| Posted:
Wed Nov 02, 2005 1:16 am Post subject:
Re: AMD to leave x86 behind? |
|
|
"David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message
news:dKN9f.65754$iD.48396@fe2.news.blueyonder.co.uk...
| Quote: | Stephen Fuld wrote:
|
snip
| Quote: | Is there some technical reason behind the limitation to three HT links or
was it a marketing decision?
Well, two HT links would constrain the CPUs to being in a linear chain,
with a maximum hop count of 7 and an average hop count (between two
different CPUs) of 4. So going from two links to three provides a very
significant benefit; going from three links to four much less so. In
fact the best four-link-per-CPU configuration I can find right now only
gets you 14 one-hops and 14 two-hops, although I'm not sure that's
optimal.
|
That sounds reasonable but it I believe it assumes eight CPUs. If they
wanted to address the market for larger systems, what are the numbers for 16
or 32 CPUs? They could certainly charge a premium for such systems and you
might be able to have the number of links be a bond out option, thus keeping
their costs low and giving an extra market segment to compete in.
--
- Stephen Fuld
e-mail address disguised to prevent spam |
|
| Back to top |
|
|
Bill Todd
Guest
|
| Posted:
Wed Nov 02, 2005 1:17 am Post subject:
Re: AMD to leave x86 behind? |
|
|
Bill Davidsen wrote:
| Quote: | Yousuf Khan wrote:
David Kanter wrote:
If you think that any modern MPU is efficient, you are smoking crack.
They all have plenty of unused cycles left on the table (except when
running linpack).
But the secret is to have enough idle cycles to run both threads at
close to full speed each. I'd say anything that had enough to run both
threads at 80% full speed, was a reasonably successful SMT.
I suspect you still don't understand SMT...
|
A failing you may share yourself.
if you had enough idle
| Quote: | cycles to run 2x80% you should either get rid of all the silicon wasted
in idle capacity or add a little more and go full dual core.
|
In which case your single-thread performance would suck on applications
that stressed the core to unusual levels (lots of potential ILP, few
memory stalls).
IIRC EV6/7 Alphas still spend on average something like 50% of their
time waiting for memory, so a fine-grained SMT implementation could
potentially run two threads at close to 100% of the single-thread speed.
EV8 simulations indicated that running 4 threads could (depending upon
the characteristics of the workload) increase throughput 2x - 3x over a
non-SMT implementation. And EV8 wasn't even primarily *aimed* at SMT:
it was aimed at industry-leading single-thread performance in
highly-parallelizable code, had enough silicon devoted to the job to
ensure that, and used SMT as a way to leverage that silicon when it
wasn't being used for its primary purpose.
Core silicon is cheap, and getting cheaper still. Core power less so,
but with the developing ability to shut down unused elements at very
fine time granularity that problem is being addressed. What SMT gives a
core is the flexibility to be good at *both* single-thread and
multi-thread performance in ways that single-threaded cores cannot be,
at a relatively small cost in additional chip area (5% - 10%, depending
upon the implementation granularity - IIRC those are about the numbers
for Xeon vs. POWER5 and EV8; Montecito's
'switch-on-event-multi-threading' may be even less).
- bill |
|
| Back to top |
|
|
keith
Guest
|
| Posted:
Wed Nov 02, 2005 8:53 am Post subject:
Re: AMD to leave x86 behind? |
|
|
On Tue, 01 Nov 2005 17:52:40 +0000, Bill Davidsen wrote:
| Quote: | YKhan wrote:
how about some form of SMT for AMD?
I don't know that might come too, but it can't be done as easily as
Hyperthreading. Hyperthreading relied on the Pentium 4's inherent
inefficiency to run a lot of threads simultaneously.
Actually not. It takes advantage of the fact that the CPU has a number
of instruction units, adders, FPU, etc, which one thread MAY use at once
in some cases, but which are not ALWAYS all in use.
|
Does Intel's HT issue from different threads on the same cycle? I thought
not, which makes the number of execution units moot. Certainly there are
units idle in any given cycle, that's where dynamic power management comes
into play.
| Quote: | By adding another instruction decoder one or more additional threads can
run using the resources which are otherwise not needed at some clock
tick.
|
Not easily. It's pretty tough to be able to fetch and decode from
different threads simultaneously. Another decoder doesn't really helpmuch.
| Quote: | Do you believe that AMD uses every execution unit on every cycle?
|
I certainly don't, but I also don't believe Intel uses every execution
unit every cycle. I could be wrong, bu AIUI they cannot dispatch
instructions from two threads in the same cycle.
| Quote: | Hopefully not, which raises the possibility of SMT, at least in theory.
|
Ok, but surely you know that theory <> reality, except in theory.
| Quote: | The question is one of benefit, typically on a task such as Linux kernel
build, or a large application build, SMT reduces the clock time by
20-30%.
|
Maybe, but that has nothing to do with "idle" EUs.
| Quote: | No matter how you spin it, it the task runs in less time I call
the CPU faster.
|
If? Ok, but it's not for the reasons you presume, not is it every set of
tasks that will benefit. If your set of tasks is HT friendly, go fer it!
TO presume others are similarly enhanced, is simply nuts.
| Quote: | No, it doesn't help a single threaded task, other than moving the O/S
and display usage into the "other" thread.
|
Neither does SMP, but my position is that any application that will
benefit from SMT will benefit more from SMP. SMP is here.
--
Keith |
|
| Back to top |
|
|
YKhan
Guest
|
| Posted:
Wed Nov 02, 2005 9:00 am Post subject:
Re: AMD to leave x86 behind? |
|
|
Bill Davidsen wrote:
| Quote: | Do you believe that AMD uses every execution unit on every cycle?
Hopefully not, which raises the possibility of SMT, at least in theory.
|
No, but I don't believe AMD has nearly enough execution units to devote
to a second thread at acceptable speeds. I'd say keeping the number of
pipeline stages the same and the same number of execution units in both
a P4 and an Athlon, the P4 might be able to run both threads at 70% of
single-thread efficiency, whereas the Athlon might only be able to
execute 40% efficiency.
Yousuf Khan |
|
| Back to top |
|
|
David Schwartz
Guest
|
| Posted:
Wed Nov 02, 2005 9:15 am Post subject:
Re: AMD to leave x86 behind? |
|
|
"Stephen Fuld" <s.fuld@PleaseRemove.att.net> wrote in message
news:5NQ9f.10906$qk4.277@bgtnsc05-news.ops.worldnet.att.net...
| Quote: | That sounds reasonable but it I believe it assumes eight CPUs. If they
wanted to address the market for larger systems, what are the numbers for
16 or 32 CPUs? They could certainly charge a premium for such systems and
you might be able to have the number of links be a bond out option, thus
keeping their costs low and giving an extra market segment to compete in.
|
Once you're in the16 or 32 CPU market, you can afford a central
non-blocking switch. So three ports is plenty.
DS |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in