* Posts by morklebork

7 publicly visible posts • joined 25 Jun 2008

Sun's Sparc server roadmap revealed

morklebork
FAIL

I'm glad you enjoyed the list...

Matt Bryant said - Then I really enjoyed your list of features you say are lacking in commodity platforms, without mentioning there also lots of the points stated missing from Niagara. For example:

".....- being able to scale from a single CPU to 64 sockets, with no recompile (or even a reboot...)...." Niagara only scales to four scokets, period. Even Xeon has been able to scale higher than that for years in generic Windows servers, let alone more specialised designs like those from Unisys.

Clown. Did you forget that you can move a binary from a T-series to an M-series box and it'll just work? Ooh.

".....- being able to add and remove entire system boards from a running OS....." Seeing as all Niagara systems have one motherboard with the sockets directly on it, there is no way you can remove the system board as without it there is nothing to run the OS!

Did you forget about M-series? Ooh. And the E/F-series the preceded it?

Seems to me that overall, you don't know anything much about the M-series or are trying deliberately to ignore it... Either way, I think it's clear that in any case, you are just looking to poo poo the Sun kit no matter what. Nice work.

morklebork
Flame

The rumours of SPARC's death are greatly exaggerated... (or, more politely, suck on this, dummies!)

The RF chips were never listed as 16 core * 16 thread in any official slide deck shown to me. Way back when you lepers at El Reg reported it, I already knew it was wrong.

Nice to see you are humble in accepting your mistake.

Further to this - to the clowns saying the roadmap is not a roadmap at all with the rate of process shrink. Remember - Sun has been using others to do the semiconductor fabbing for ages. The T-series stuff is done by someone different to the M-series - and that special someone is in bed with IBM already making the next few processes smaller... And Sun will be able to leverage that.

It may be that Fujitsu will take a little longer to get the M-series chips to the smaller process node, but remember - with M-series, it's as much about scaling and correctness as it is about straight-line speed. What happens when an Intel CPU takes a parity error on a register? Pretty sure it won't even notice... I'll tell you what the M-series stuff will do. It'll see the parity error, it'll roll back the current instruction stream, reload and replay it...

And - saying there is no innovation - You are forgetting; There was tons of innovation in the Rock platform that's still available to them. And - they have learned the lessons in that they have actually built the systems. They just chose not to go full scale production.

If you are one of the many that look only at CPU straight line speed, you are overlooking all of the other features lacking in commodity platforms today...

Like:

- being able to scale from a single CPU to 64 sockets, with no recompile (or even a reboot...)

- being able to add and remove entire system boards from a running OS

- being able to add and remove not just PCI cards, but entire IO assemblies

- being able to have a single OS instance with a 2 or even 4 TB physical address space

- being able to physically hardware partition your large box into multiple physical systems *without* a hypervisor

- having OBP (And if you have not used it, you won't get this one...

- being able to dump the box externally if it stops (more than just an NMI and hoping...)

- being able to diagnose, the first time, if something fails

- having an extensive FMA database for that *specific* platform

- being able to take components offline whilst the system is up

- being able to configure the system with *mirrored* DIMMS, so you could potentially ride through the complete failure of a whole stick (ok - I'll grant some other platforms can do that...:)

- having on-ASIC history registers that allow the inspection of bus traffic to understand what's happening

- having all sorts of telemetry available for inspection (say, through busstat)

- having 256 and larger sized memory pages available to the system

- having 16 I/O assemblies, each with 8 * pci-E x8 slots, all available to the one OS image for Mega DB or other large workloads where you need to get bulk amounts of data into and out of the one system

I could go on and on - but I think you get the point.

Oh - And don't forget. Larry loves the idea of an appliance... They will own all of the Rock IP, and the FISHWorks group at the end of the acquisition... One of the (sadly never released) 8 socket Rock Boxes would make an ideal system for an appliance... Oracle could sell you one, and use the magic screw-driver to turn up and down the capability of the box based on the size of your requirement / checkbook. :)

Way more differentiated than just another x86 RAC environment, and you don't need to cross your fingers (and everything else) that people don't cobble queries up that cream the interconnect between nodes...

And - Remember that it's Linux, not Windows that's been eating away at SPARC marketshare, and a large part of that is due to Oracle supporting more on Linux recently than Solaris SPARC (Validating the Linux platform...). Do you think they will continue to do that when they have their *own* operating system, Solaris, which is more scalable, stable, diagnosable, etc than linux?

Let's not even *start* with the horrors presented to Oracle if they actually did kill off the SPARC platform. If someone wants a big box to run Big oracle, they only have a few choices these days... SPARC, POWER or ITANIUM.

Considering how few people buy Itanium, how little software support there is it's really SPARC and Power (Yes - I know this is simplifying, but it's close enough to illustrate the point), where will those customers be driven if SPARC goes away??? To IBM on POWER. Oracle's sworn enemy in the database space... Even Sun haters would have to concede that it would be dumb for oracle to push their biggest customers in to the arms of IBM for hardware when everyone knows that it would also drag in IBM GS, and present the opportunity for IBM's DB2 and other applications to get an airing.

In short - If you think SPARC can do *nothing* but die... you are wrong. Very wrong.

Intel pushes Nehalem EXs into 2010

morklebork
Flame

64 cores is as big as big iron gets??? Fool.

See HP Superdome, Sun M9000, (Fujitsu M9000) and a host of other servers...

The m9000 can, for example take up to 4TB of memory *now*, and 64 *sockets*... NOW.

With quad core CPUs, that's 256 cores, 512 threads - All in one OS instance (or split among many if you like.)

The Hp's are similar... (But - Who wants to run Itanium... I hear ya...)

Intel releases eight-headed* beast

morklebork
Flame

Perhaps the Reg should post an article pointing to the real roadmap

Fake Roadmaps, incorrect proclamations, bad assumptions and a complete lack of fact or vendor information.

Sounds like someone is trying to hide some of their own problems.

If Rock is dead, nobody has told Jonathan, John F, or anyone else that matters at Sun... (See recent articles already cited)

Go on, El Reg - Post an article pointing to the real SPARC roadmap. I dare you.

And - see if you can find out when Intel actually plans to release Nehalem in anything other than 2 socket variants. I read it's not till 2010, and if past experiences with large, scalable NUMA systems is anything to go by, don't be surprised if it's even later than that. Think back to the last time they tried...

HP hunts down 'rare' BladeSystem problem

morklebork

So What's New?

It's not at all uncommon for manufacturers of 'highly available' hardware to have failures like this, particularly in the power system.

Actually, thinking back, I can't remember dealing with any company that has not caused me an outage due to 'redundant' power failing.

Nonetheless, it's a good advertisement for ensuring that you architect properly and don't rely on a single blade chassis. Or rack. Or power supply. Or datacentre. Or power company. Or comms company. Or building. Or site on the wrong side of a fault-line. Or...

AMD to launch 45nm quad-core Phenoms on 8 January 2009

morklebork
Happy

Seems like an interesting proposition for a ZFS server chip!

mmm... 1.5Ghz Dual core goodness for only 22W... I know what I'll be putting into my Solaris ZFS server at the end of this year... It'll be about as fast as the CPU I have now, and use about 1/3rd or less of the power...

Happy face as I'm almost done with the high power, high cost bits for my home servers... Now I Just need to get me some cf cards to let my HDD's spin down and stay spun down most of the time... ;)

Sun's Niagara 3 will have 16-cores and 16 threads per core

morklebork
Stop

I'm amazed at just how little some folks know

Unless I missed the irony of the post about HP-UX and Solaris.

If not meant as ironic, I can't help but ask:

What platforms can hp-ux run on, and is it open?

Itanic and PA-RISC.

Oh, great range there. PA is dead. Itanic has a limited life, will be completely overrun by X86 when the new CSI architecture ships. Basically, it is a product nobody but Intel and HP have any future plans for. Even those are shaky.

And - When was the lat time you were browsing the source of hp-ux? Open? No.

What about Solaris platforms and openness?

Sparc? Yep

X86, both 32 bit and 64 bit? Yep

Highly available or commodity hardware? Yep

Open Source? Yep - http://opensolaris.org

(Granted, that's Opensolaris, not Solaris 10)

Free? Yep (Though you pay for support, though still less then Redhat...)

And - for the 87.5Mhz comment, there is little more I can say but... Get some idea before commenting on something you clearly know nothing about. You are assuming that a) There would only be only pipeline and b) the single pipeline can execute only one instruction per cycle c) The cost of waiting for memory is zero d) The cost of waiting for I/O is zero

All of these are bad assumptions, and the very reason the niagara series systems are a $1bn business...