SB 2000 or SB 2500: Which would you buy?
Nemo ad Nusquam
one. Specs aside, which one would gentle readers choose?
Thank you.
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
Doug McIntyre
>SB 2000 and SB 2500 are available on ebay at PC prices. I am going to buy
>one. Specs aside, which one would gentle readers choose?
The thing that would probably push it one way or the other for me is
that the SB2000 use FCAL hard drives, while the SB2500 switched back
to SCSI (other than the SB2500 generally having newer, bigger CPUs, etc).
DoN. Nichols
> SB 2000 and SB 2500 are available on ebay at PC prices. I am going to buy
> one. Specs aside, which one would gentle readers choose?
Well ... I *already* have a SB-2000, and enough FC disk drives
so I would like to keep it.
However, if I were starting from scratch, I would go for the
SB-2500, since the FC (Fibre Channel) disk drives are harder to find at
reasonable prices -- except occasionally at hamfests. And the SB-2000
uses two FC drives internally, and has external 68-pin SCSI and FC (as
well as slow USB 1.1 and a rather slow Firewire built in, while the
SB-2500 comes with a PCI card which offers several USB 2.0 and a couple
of faster Firewire ports. (I can testify that the card works in the
SB-2000 as well, as I am using one that way.
Other than that -- the SB-2500 seems to only be marginally
faster (in CPU speed) than the SB-2000.
I know that the SB-2000 is far from featherweight, and I presume
that the SB-2500 is similar in weight.
Enjoy,
DoN.
--
Email: <dnic...@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
Dave
> SB 2000 and SB 2500 are available on ebay at PC prices. I am going to buy
> one. Specs aside, which one would gentle readers choose?
>
> Thank you.
I noticed on eBay the other day someone selling a Silver Blade 2500
rather than a red one. They implied this was a newer model. I know there
are two colours, but are unsure of the difference between them.
I have a Blade 2000 which I really liked, but it was damaged recently by
lightning. I am in fact going to replace it by an x86 box.
As far as I can ascertain, there is no electrical difference between a
blade 1000 and a 2000. The motherboards are the same.
As others have said, FC-AL disks are somewhat rarer than SCA. Whilst my
machine has a pair of 147 GB disks, I can't pick them up and put them in
any other machine, or in any external enclosure I own.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
Michael Laajanen
Dave wrote:
> Nemo ad Nusquam wrote:
>> SB 2000 and SB 2500 are available on ebay at PC prices. I am going to
>> buy
>> one. Specs aside, which one would gentle readers choose?
>>
>> Thank you.
>
> I noticed on eBay the other day someone selling a Silver Blade 2500
> rather than a red one. They implied this was a newer model. I know there
> are two colours, but are unsure of the difference between them.
Red is up to 1.28Ghz and Silver is 1.6GHz which is the fastest IIIi CPU.
>
> I have a Blade 2000 which I really liked, but it was damaged recently by
> lightning. I am in fact going to replace it by an x86 box.
>
> As far as I can ascertain, there is no electrical difference between a
> blade 1000 and a 2000. The motherboards are the same.
>
SCSI(1000) FCAL(2000), but I would assume that the motherboard has been
reved since the first 650MHz 1000!
> As others have said, FC-AL disks are somewhat rarer than SCA. Whilst my
> machine has a pair of 147 GB disks, I can't pick them up and put them in
> any other machine, or in any external enclosure I own.
>
/michael
Michael Laajanen
Nemo ad Nusquam wrote:
> SB 2000 and SB 2500 are available on ebay at PC prices. I am going to buy
> one. Specs aside, which one would gentle readers choose?
>
> Thank you.
>
>
The Blade 1000/2000 uses the server CPU Ultrasparc III in various speed
and caches, the Blade 1500/2500 uses the the desktop CPU Ultrasparc IIIi .
IIIi runs cooler, but I think if loaded with a lot of processes the III
will outperform the IIIi.
IIIi can also take more RAM(8GB per CPU) and cheaper RAM.
/michael
DoN. Nichols
> Nemo ad Nusquam wrote:
>> SB 2000 and SB 2500 are available on ebay at PC prices. I am going to buy
>> one. Specs aside, which one would gentle readers choose?
>>
>> Thank you.
>
> I noticed on eBay the other day someone selling a Silver Blade 2500
> rather than a red one. They implied this was a newer model. I know there
> are two colours, but are unsure of the difference between them.
Hmm ... visit the FEH at the Australian site:
<http://www.sunshack.org/data/sh/2.1.8/infoserver.central/data/syshbk/index.html>
and navigate around until you find the man pages for the two systems.
Routing is going in a loop for me right now, so I can't post links to the
specific pages, but hopefully by the time you try this, the routing will
be fixed.
IIRC, the primary difference is that the later version comes
with faster CPUs, but I may be mis-remembering, since I don't have any
of these beyond the SB-2K.
> I have a Blade 2000 which I really liked, but it was damaged recently by
> lightning. I am in fact going to replace it by an x86 box.
>
> As far as I can ascertain, there is no electrical difference between a
> blade 1000 and a 2000. The motherboards are the same.
There are several system boards some of which overlap between
the two systems, and the primary difference in these is the version of
the SCHIZO modules -- and I don't really know what difference these make
anyway. :-)
> As others have said, FC-AL disks are somewhat rarer than SCA. Whilst my
> machine has a pair of 147 GB disks, I can't pick them up and put them in
> any other machine, or in any external enclosure I own.
There are various external boxes for multiple FC-AL drives. EMC
makes them, I'm using a set of Eurologic ones which I particularly like
Sun makes some -- and I *think* that there is even a FC-AL version of the
Multipack.
Or -- you could get a spare drive cage for a SB-[12]000, dig
though the foam rubber on the back of the backplane, and jumper one of
the ID wires high which is currently low to make the drive addresses no
longer conflict with the ones which are internal (1&2 for the SB-[12]Km
0&1 for the Sun Fire 280R. Also -- the Sun Fire 280R cage only will
accept 1" high drives, not 1.6" ones. You can get 146 GB 1" FC-AL
drives, and I have two in one of my SF-280R machines.
I'm not sure how many traces you'll need to cut to make this
jumpering possible.
Good Luck,
Benjamin Gawert
> SB 2000 and SB 2500 are available on ebay at PC prices. I am going to buy
> one. Specs aside, which one would gentle readers choose?
Well, the SB2000 has a hampered memory interface (only the primary CPU
has directly connected main memory, the second processor has to go over
the first one to access RAM which in memory-intensive applications
affects performance), not sure if this got better with the SB2500. As
others have said, the SB2000 uses FC-AL disks which limits the choice of
available disks quite a lot.
To be honest, if you don't really *need* a SPARC system I would go for a
x86 (x64) PC instead which will give you much more performance than any
of those old machines at the same cost. Heck, even a Sun W2100z (the
first generation dual Opteron workstation with AMD AGP chipset) will
very likely run circles around any SB2x00 system.
Benjamin
Nemo ad Nusquam
> SB 2000 and SB 2500 are available on ebay at PC prices. I am going to buy
> one. Specs aside, which one would gentle readers choose?
Thank you for your comments. I think I will go for the SB 2500.
Bart
> has directly connected main memory, the second processor has to go over
> the first one to access RAM which in memory-intensive applications
> affects performance),
Can you point me to any documentation that explains this any better?
I've never heard of this about the 1k/2k blades. Most any multiprocess
system architecture I am familiar with has some overhead with the
memory controller.
Thanks
Benjamin Gawert
> Can you point me to any documentation that explains this any better?
> I've never heard of this about the 1k/2k blades. Most any multiprocess
> system architecture I am familiar with has some overhead with the
> memory controller.
Standard multiprocessor computers have a common memory controller and
common memory. This is called UMA (Uniform Memory Access) architecture.
It looks like this:
[I/O]
|
[CPU0]---[CPU1]
|
[MEMORY CONTROLLER]-[MEMORY]
Good examples of UMA machines are most servers and workstations with
older intel XEON processors (pre-XEON 5500 series). These XEON
processors have a common (or with XEON 5000 series separate) FSB to
communicate with an external memory controller (Northbridge). This
basically means for a given situation the performance of each CPU
accessing memory is always the same, no matter which CPU does the access
and no matter which area of the system memory is accessed. However,
because the memory controller is outside the CPU, accessing memory takes
time (higher latency), and especially with older XEONs with common
single FSB the FSB limits the actual bandwidth available to the system
memory.
However, the UltraSPARCIII-based Sun machines like the SB1000/2000/2500
as well as AMD Opteron-based computers are NUMA[1] (Non-Uniform Memory
Access) architecture. NUMA means that every processor has its own memory
controller (which in case of UltraSPARC III and AMD Opteron is built
into the CPU) and its own local memory. NUMA looks like this:
[I/O]
|
[CPU0]-[MEMORY CONTROLLER]-[MEMORY]
|
[CPU1]-[MEMORY CONTROLLER]-[MEMORY]
|
[I/O]
The advantage is that every CPU has very fast access to its local RAM
(low latency), and it doesn't have to share the bandwidth with the other
processor. However, as soon as a CPU has to access memory connected to
another CPU, things get much slower as it has to go over the other
processor to access its memory. Now the memory performance depends which
part of the system memory has to be accessed, if it is local it is fast,
if it is connected to another processor it is slow. Therefore NUMA needs
a NUMA-aware OS (like Solaris, Windows or Linux) which distributes
processes and assigns memory in a way that processes use system RAM
connected to the processor it runs on.
As to the Sun Blade 1000/2000/2500, it is a crippled NUMA system which
basically looks like this:
[I/O]
|
[CPU0]-[MEMORY CONTROLLER]-[MEMORY]
|
[CPU1]-[MEMORY CONTROLLER]
While both processors do have memory controllers, only the first CPU can
actually have physical RAM. This means all processes running on the
second processor have to go over the primary one to access RAM as the
second CPU doesn't have local memory. This has quite a huge impact on
memory-intensive multiprocessor applications.
Ben
ChrisQ
> While both processors do have memory controllers, only the first CPU can
> actually have physical RAM. This means all processes running on the
> second processor have to go over the primary one to access RAM as the
> second CPU doesn't have local memory. This has quite a huge impact on
> memory-intensive multiprocessor applications.
>
> Ben
>
That's interesting, but I doubt that would have much of an impact on the
sort of work done by many users, other than for seriously compute
intensive applications. A B1000 is used here both as the lab server and
also for software development. Recently removed one of the cpu's to save
power and notice no difference at all in terms of interactive response
or compilation times. Juice is expensive now, so why pay to use more if
there's little benefit ?. The blade 1 and 2k series are quite power
hungry (~200 watts) compared to earlier Sparc workstation class machines.
On windows, using task manager on a dual xeon machine, the only apps
that really make use of mt or the two cpu's are those like photoshop or
lightroom, but even then the processors are really just loafing along.
Might just as well remove one of the cpu's there as well...
Regards,
Chris
erik magnuson
>
> As to the Sun Blade 1000/2000/2500, it is a crippled NUMA system which
> basically looks like this:
>
> [I/O]
> |
> [CPU0]-[MEMORY CONTROLLER]-[MEMORY]
> |
> [CPU1]-[MEMORY CONTROLLER]
>
> While both processors do have memory controllers, only the first CPU can
> actually have physical RAM. This means all processes running on the
> second processor have to go over the primary one to access RAM as the
> second CPU doesn't have local memory. This has quite a huge impact on
> memory-intensive multiprocessor applications.
>
Are you sure that applies to the SB-2500? The max RAM for the SB-2500
was twice that of the SB-1500. Bear in mind that the SB1k/2k used the
US-III processor, while the SB-2500 used the US-IIIi processor.
- Erik
Benjamin Gawert
> Are you sure that applies to the SB-2500? The max RAM for the SB-2500
> was twice that of the SB-1500. Bear in mind that the SB1k/2k used the
> US-III processor, while the SB-2500 used the US-IIIi processor.
I checked again and you are right, this doesn't apply to the SB2500
which has both CPUs connected to local memory (with one CPU only half of
the memory slots can be used).
Benjamin
Benjamin Gawert
> That's interesting, but I doubt that would have much of an impact on the
> sort of work done by many users, other than for seriously compute
> intensive applications.
It affects all multiprocessor (multithreaded) applications that make use
of a lot of memory, and it does affect singlethreaded applications as
well if the scheduler shifts them to the second processor.
But considering that these machines are now becoming close to a decade
old and being really slow now I doubt this is a problem any more as the
overall performance of these critters is low. Also, the memory interface
of the USIII is not great.
> A B1000 is used here both as the lab server and
> also for software development. Recently removed one of the cpu's to save
> power and notice no difference at all in terms of interactive response
> or compilation times. Juice is expensive now, so why pay to use more if
> there's little benefit ?. The blade 1 and 2k series are quite power
> hungry (~200 watts) compared to earlier Sparc workstation class machines.
If power is of concern then a SB1000/2000 is probably a bad choice.
> On windows, using task manager on a dual xeon machine, the only apps
> that really make use of mt or the two cpu's are those like photoshop or
> lightroom, but even then the processors are really just loafing along.
> Might just as well remove one of the cpu's there as well...
Don't know about Lightroom but IIRC Photoshop only uses multiple
processors for certain filters.
It doesn't seem any of your applications make use of multiple
processors, so you might as well just use single processor machines
which use less power.
Benjamin
ChrisQ
>
> But considering that these machines are now becoming close to a decade
> old and being really slow now I doubt this is a problem any more as the
> overall performance of these critters is low. Also, the memory interface
> of the USIII is not great.
It's still the fastest sparc based machine here. At last, a sparc
machine that equals my old 1997 vintage Alpha box in terms of
interactive response and compile times. It's just a real shame sun
stopped doing sparc based workstations. Diversity improves the breed and
the cpu gene pool is shrinking fast.
> It doesn't seem any of your applications make use of multiple
> processors, so you might as well just use single processor machines
> which use less power.
>
It can always be refitted if there is the need and would probably get
more benefit for present work upgrading to a single 1200Mhz cpu, rather
than a dual 900Mhz config.
What other options there are, without mentioning X86, of course :-)...
Regards,
Chris
Bart
Here is a document I found that provides the details on the Sunblade
1000/2000 memory and CPU architecture (Starts on Page 30).
http://ru.sun.com/products/workstations/blade1000/pics/sb1000wp.pdf
Apparently the US IIIcu has a built in memory controller and
multiprocessor systems use a buss arbitration system. I can see how
this might have a small impact in performance but the obvious benefit
is for scaling so I can also see why Sun chose this path. It provides
direct access for 1 cpu (because the USIII has a memory controller
built-in) while subsequent processors use the shared interconnect bus
(Sun called it Fireplane I guess).
Thomas Maier-Komor
If you take a look at the block diagram of the Blade 2500 in
817-5117-11.pdf, page C-3, you'll see that both cpus are connected to
two memory banks of their own and communicate with two IO bridges over a
common J-Bus.
- Thomas
Benjamin Gawert
> Here is a document I found that provides the details on the Sunblade
> 1000/2000 memory and CPU architecture (Starts on Page 30).
>
> http://ru.sun.com/products/workstations/blade1000/pics/sb1000wp.pdf
>
> Apparently the US IIIcu has a built in memory controller and
> multiprocessor systems use a buss arbitration system. I can see how
> this might have a small impact in performance but the obvious benefit
> is for scaling
Nope, it has no benefit "for scaling". In fact, it is a huge bottleneck
in multiprocessing and scales like crap.
> so I can also see why Sun chose this path.
I can, too. It was very likely a cost cutting measure and nothing else.
> It provides
> direct access for 1 cpu (because the USIII has a memory controller
> built-in) while subsequent processors use the shared interconnect bus
> (Sun called it Fireplane I guess).
It's not a bus, it's a crossbar switch which means it add noticeable
latency to the I/O.
For a workstation in this price range (when it was new, when I got my
first SB1000 the machine did cost around 30kEUR) I would have expected a
design that doesn't cut corners in important areas.
Of course today this is probably irrelevant as even the fastest SB1000
(and SB2000) is slow like hell by todays' standards.
Benjamin
Benjamin Gawert
> If you take a look at the block diagram of the Blade 2500 in
> 817-5117-11.pdf, page C-3, you'll see that both cpus are connected to
> two memory banks of their own and communicate with two IO bridges over a
> common J-Bus.
And if you read my posting from September 23rd (almost a month ago!) you
will find out that I already corrected myself re. Blade 2500 memory.
Benjamin
Thomas Maier-Komor
sorry Benjamin - I've overlooked your reply to Erik in the other branch...
Benjamin Gawert
> sorry Benjamin - I've overlooked your reply to Erik in the other branch...
Nevenr mind. At the end of the day it shows that the SB2500 is the much
better balanced system than the SB1000/2000. The second CPU provides not
only more computing performance but also higher system memory
throughput, so the SB2500 benefits much more from the second processor
than a SB1000/2000 does.
Benjamin
Casper H.S. Dik
>* Bart:
>> Apparently the US IIIcu has a built in memory controller and
>> multiprocessor systems use a buss arbitration system. I can see how
>> this might have a small impact in performance but the obvious benefit
>> is for scaling
>Nope, it has no benefit "for scaling". In fact, it is a huge bottleneck
>in multiprocessing and scales like crap.
This is why Nehalem and Opteron also use a integrated memory controller?
The issue is not the on-chip memory controller; it's more like the
shared memory bus. The latter do NOT exist in Nehalem and Opteron.
>> so I can also see why Sun chose this path.
>I can, too. It was very likely a cost cutting measure and nothing else.
No true; getting the controller closer to the CPU should allow you
to get a lower latency and faster access to lower memory.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Bart
> For a workstation in this price range (when it was new, when I got my
> first SB1000 the machine did cost around 30kEUR) I would have expected a
> design that doesn't cut corners in important areas.
>
> Of course today this is probably irrelevant as even the fastest SB1000
> (and SB2000) is slow like hell by todays' standards.
Aren't the 6 large custom ASICS in a row between the 2 processor
sockets on a SB 1k/2k motherboard essentially the fireplane
architecture? How can this possibly cost less than a single
integrated memory controller?
Dave
I've got a fully packed Blade 2000 (dual 1200 MHz, 8 GB RAM, XVR-1000, every PCI
slot full) and its frightening when you measure the power consumption. Mine is
using about 450 W, if the cheap device I bought from Maplin is to be trusted.
Certainly the room is a lot cooler now I have a much higher spec Ultra 27 (3.33
GHz Xeon, 12 GB RAM, NVIDIA Quadro FX 3800 graphics)!
That said, I like the Blade 2000, and it is still much faster for SPARC software
development than a much newer 16-core T5240 with T2+ processors, I have access
to. The T5240 is basically ill suited for software development, (at least the
sort I'm doing), though no doubt it is well suited for running web servers,
databases and similar.
I have contemplated buying a Blade 2500, as I'm still using the Blade 2000 quite
a bit, despite having the Ultra 27. Perhaps if a cheap Blade 2500 comes up on
eBay, I will not be able to resist it.
Casper H.S. Dik
>That said, I like the Blade 2000, and it is still much faster for SPARC software
>development than a much newer 16-core T5240 with T2+ processors, I have access
>to. The T5240 is basically ill suited for software development, (at least the
>sort I'm doing), though no doubt it is well suited for running web servers,
>databases and similar.
If best single thread performance is one of the Fujitsu SPARC processors;
in my lab I have a M3000 (SPARC64-VII) and it is blazing.
>I have contemplated buying a Blade 2500, as I'm still using the Blade 2000 quite
>a bit, despite having the Ultra 27. Perhaps if a cheap Blade 2500 comes up on
>eBay, I will not be able to resist it.
If you can pay the power bill.
Michael Laajanen
Casper H.S. Dik wrote:
> Dave <f...@coo.com> writes:
>
>> That said, I like the Blade 2000, and it is still much faster for SPARC software
>> development than a much newer 16-core T5240 with T2+ processors, I have access
>> to. The T5240 is basically ill suited for software development, (at least the
>> sort I'm doing), though no doubt it is well suited for running web servers,
>> databases and similar.
>
> If best single thread performance is one of the Fujitsu SPARC processors;
> in my lab I have a M3000 (SPARC64-VII) and it is blazing.
>
>
For HW simulation single thread is still important, how does it stack up
againts high end Opteron, any clue on that?
/michael
Rick Jones
> Nope, it has no benefit "for scaling". In fact, it is a huge
> bottleneck in multiprocessing and scales like crap.
Being a networking type, I'll assert that going link-based and/or
integrated memory controllers helps at what we might call the
"physical layer" but if the "data link" layer (eg the coherence
protocol) isn't up to the task there will indeed be scaling problems.
This is visible in the Opteron-based SPECcpu2006 results from both Sun
and HP, particularly when you compare 8 processor results with 4 and
two processor results. A non-trivial change for the better can be
seen with the SPECcpu2006 results using Opteron "Istanbul" processors.
Istanbul is still link-based with integrated memory controller like
its predecessors, but something else changed that allows it to scale
much better.
How a link-based Nehalem-based system will perform beyond 2P remains
to be seen. Should be interesting to watch.
I cannot speak accurately to Sun SPARC-based high-end systems, but I
suspect that both their and HP's Integrity high-end systems are, in
effect, "hybrid" systems where there are what we might call "bus
islands" of a couple or so processors on a bus with a memory
controller, the islands joined via cross-bar links, not everything
just one hop away. The HP high-end Integrity systems seem to scale
reasonably well from an SMP perspective, presumably the Sun systems do
as well. "Links" there were/are not an issue, and presumably the
coherence protocols work well.
rick jones
Look at the block diagram from high-enough up and those "bus islands"
start to look rather like multi-core processors with an embedded
memory controller and a link or three sticking-out...
--
the road to hell is paved with business decisions...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Dave
> Dave <f...@coo.com> writes:
>
>> That said, I like the Blade 2000, and it is still much faster for SPARC software
>> development than a much newer 16-core T5240 with T2+ processors, I have access
>> to. The T5240 is basically ill suited for software development, (at least the
>> sort I'm doing), though no doubt it is well suited for running web servers,
>> databases and similar.
>
> If best single thread performance is one of the Fujitsu SPARC processors;
> in my lab I have a M3000 (SPARC64-VII) and it is blazing.
For me, single thread performance is what I need.
The M3000 looks very impressive on paper, but it is still a current model, so
not much chance of finding something in my price range on eBay.
>> I have contemplated buying a Blade 2500, as I'm still using the Blade 2000 quite
>> a bit, despite having the Ultra 27. Perhaps if a cheap Blade 2500 comes up on
>> eBay, I will not be able to resist it.
>
> If you can pay the power bill.
The PSU in the 2500 seems amazingly efficient.
http://sunsolve.sun.com/handbook_pub/validateUser.do?target=Systems/SunBlade2500S/spec
------------------------------------------------------
Environment:
AC input 90 to 264 VAC, 47 to 63 Hz, 0.4 KVA
DC Output 600 W
-----------------------------------------------------
I should be able to sell some electricity to the grid at that rate!!
Rick Jones
> For HW simulation single thread is still important, how does it
> stack up againts high end Opteron, any clue on that?
For one take on that sort of thing, you could go to:
http://www.spec.org/cgi-bin/osgresults?conf=cint2006&op=form
or
http://www.spec.org/cgi-bin/osgresults?conf=cfp2006&op=form
And fine the Auto Parallel filter and have it match "no" and then go
to the bottom of the page and make the primary sort the "Result" and
ask that it be "Descending" and look from there. There will be a lot
of "clutter" with different vedor's results with the same
chips/compilers.
If you are willing to add to the filters, you could do one search
where processor is supposed to match "sparc" and then one where it
matches "opteron" etc etc... There will likely still be clutter
through which you need to wade but it might be minimized.
If single-threaded performance is important to you, you really must
make certain that Auto Parallel is "no" - a SPECcpu2006 "speed" metric
can no longer be ass-u-me-d to be single-threaded.
rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
Benjamin Gawert
>>> Apparently the US IIIcu has a built in memory controller and
>>> multiprocessor systems use a buss arbitration system. I can see how
>>> this might have a small impact in performance but the obvious benefit
>>> is for scaling
>
>> Nope, it has no benefit "for scaling". In fact, it is a huge bottleneck
>> in multiprocessing and scales like crap.
>
> This is why Nehalem and Opteron also use a integrated memory controller?
They all use integrated memory controllers because they scale better (no
bandwidth sharing), however, none of the other system manufacturers puts
them together in SMP configurations where only one processor has local
memory. Simply because it scales like crap.
After reading the the text again, I suppose Bart mean that the
integrated memory controller fas the benefit for scaling while I
(errorneously) thought that he meant the fact that the SB1k/2k only have
one CPU connected to RAM. In this case sorry for the confusion.
> The issue is not the on-chip memory controller; it's more like the
> shared memory bus. The latter do NOT exist in Nehalem and Opteron.
>
>>> so I can also see why Sun chose this path.
>
>> I can, too. It was very likely a cost cutting measure and nothing else.
>
> No true; getting the controller closer to the CPU should allow you
> to get a lower latency and faster access to lower memory.
As said above I was more talking about Sun cutting corners with the
SB1k/2k. Of course integrated memory controllers have advantages.
Ben
Benjamin Gawert
> Aren't the 6 large custom ASICS in a row between the 2 processor
> sockets on a SB 1k/2k motherboard essentially the fireplane
> architecture? How can this possibly cost less than a single
> integrated memory controller?
This is no question of choice. First, all USIII processors have
integrated memory controllers, so in a SB1k/2k with two CPUs there are
two memory controllers so Sun doesn't save any money for memory
controllers there. However, only the memory controller on the primary
processor is actually used, which means they save the money for a second
set of memory banks incl. buffers and other parts.
Second, the Fireplane crossbar switch would even be needed when both
memory controllers would be used as it is the central hub where all
external communication (with other processors and with I/O and storage)
goes through.
Ben
Benjamin Gawert
> Being a networking type, I'll assert that going link-based and/or
> integrated memory controllers helps at what we might call the
> "physical layer" but if the "data link" layer (eg the coherence
> protocol) isn't up to the task there will indeed be scaling problems.
> This is visible in the Opteron-based SPECcpu2006 results from both Sun
> and HP, particularly when you compare 8 processor results with 4 and
> two processor results. A non-trivial change for the better can be
> seen with the SPECcpu2006 results using Opteron "Istanbul" processors.
Are you sure that this is because of the protocol?
> Istanbul is still link-based with integrated memory controller like
> its predecessors, but something else changed that allows it to scale
> much better.
I would guess it is more of a better NUMA optimization in the used
operating systems, especially since not all of the older Opteron
machines had valid a SRAT (the xw9300 and the Sun Ultra 40 M1 for
example didn't).
> How a link-based Nehalem-based system will perform beyond 2P remains
> to be seen. Should be interesting to watch.
That for sure.
> I cannot speak accurately to Sun SPARC-based high-end systems, but I
> suspect that both their and HP's Integrity high-end systems are, in
> effect, "hybrid" systems where there are what we might call "bus
> islands" of a couple or so processors on a bus with a memory
> controller, the islands joined via cross-bar links, not everything
> just one hop away. The HP high-end Integrity systems seem to scale
> reasonably well from an SMP perspective, presumably the Sun systems do
> as well. "Links" there were/are not an issue, and presumably the
> coherence protocols work well.
Well, I am not aware of any platform that uses a similar config like the
SB1k/2k. Older NUMA machines with CPUs that didn't have integrated
memory controllers (like SGIs Origin series or the Sun Enterprise 3k and
above) used such "islands" where two or four processors shared a common
memory controller (these "islands" were UMA in a NUMA system). Newer
NUMA machines with processors using integrated memory controllers
usually provide each processor with its own memory. So no matter what
every processor always has direct access to RAM, either via a shared
memory architecture, or to its own separate memory.
The SB1k/2k (and the Sun Fire 280R of course) is the only machine I know
which has a CPU that has no direct RAM access.
Ben
Benjamin Gawert
> I've got a fully packed Blade 2000 (dual 1200 MHz, 8 GB RAM, XVR-1000,
> every PCI slot full) and its frightening when you measure the power
> consumption. Mine is using about 450 W, if the cheap device I bought
> from Maplin is to be trusted.
Yes, these beasts draw a lot of power. Considering the performance I
don't think it makes much sense using one for daily work.
> Certainly the room is a lot cooler now I have a much higher spec Ultra
> 27 (3.33 GHz Xeon, 12 GB RAM, NVIDIA Quadro FX 3800 graphics)!
A Core i7-based system, nice!
> I have contemplated buying a Blade 2500, as I'm still using the Blade
> 2000 quite a bit, despite having the Ultra 27. Perhaps if a cheap Blade
> 2500 comes up on eBay, I will not be able to resist it.
Well, I think the problem is the word "cheap" here. Prices for
SB1500/2500 are still ridiculously high, but on the other side rarely
one finds a buyer at that price. I suppose you just have to wait, but
when the prices become more reasonable the performance will be even more
on the bottom end than it already is.
Benjamin
ChrisQ
> Benjamin Gawert <bga...@gmx.de> writes:
>
>> * Bart:
>
>>> Apparently the US IIIcu has a built in memory controller and
>>> multiprocessor systems use a buss arbitration system. I can see how
>>> this might have a small impact in performance but the obvious benefit
>>> is for scaling
>
>> Nope, it has no benefit "for scaling". In fact, it is a huge bottleneck
>> in multiprocessing and scales like crap.
>
> This is why Nehalem and Opteron also use a integrated memory controller?
>
> The issue is not the on-chip memory controller; it's more like the
> shared memory bus. The latter do NOT exist in Nehalem and Opteron.
>
>>> so I can also see why Sun chose this path.
>
>> I can, too. It was very likely a cost cutting measure and nothing else.
>
> No true; getting the controller closer to the CPU should allow you
> to get a lower latency and faster access to lower memory.
>
> Casper
Well, whatever the theory, it's still a very nice box and for me, a
welcome return to Sun machines for interactive as well as server use. My
first workstation class machine was a Sun 3/60 back in 1993 and have
always liked sun hardware from an engineering point of view, as well as
being not Intel. It has a certain integrity that a lot of the pc
hardware lacks and they are not that expensive if you shop around. It
has internal and external fc interfaces, as well as the usual scsi and
other io ports and even has usb, so you only need to add a graphics card
and the job's done.
The only criticism is the size of the box, but we'll let that go :-)...
Regards,
Chris
Dave
> * Dave:
>
>> I've got a fully packed Blade 2000 (dual 1200 MHz, 8 GB RAM, XVR-1000,
>> every PCI slot full) and its frightening when you measure the power
>> consumption. Mine is using about 450 W, if the cheap device I bought
>> from Maplin is to be trusted.
>
> Yes, these beasts draw a lot of power. Considering the performance I
> don't think it makes much sense using one for daily work.
I would tend to agree.
>> Certainly the room is a lot cooler now I have a much higher spec Ultra
>> 27 (3.33 GHz Xeon, 12 GB RAM, NVIDIA Quadro FX 3800 graphics)!
>
> A Core i7-based system, nice!
Yes, it is a nice machine.
>> I have contemplated buying a Blade 2500, as I'm still using the Blade
>> 2000 quite a bit, despite having the Ultra 27. Perhaps if a cheap
>> Blade 2500 comes up on eBay, I will not be able to resist it.
>
> Well, I think the problem is the word "cheap" here. Prices for
> SB1500/2500 are still ridiculously high, but on the other side rarely
> one finds a buyer at that price. I suppose you just have to wait, but
> when the prices become more reasonable the performance will be even more
> on the bottom end than it already is.
>
> Benjamin
Some people on eBay do live in cloud cuckoo land, asking rediciously high prices
for things. I think some give up, and sell them as parts. There appear to be
some on eBay now, where the seller has just broken them up.