* Posts by MadMike

110 publicly visible posts • joined 13 Feb 2014


It's about forking time: Node.js, io.js to mend differences, remerge


Java is Enterprise, C# is not

Enterprise is characterized by stability and very long support cycles. Some Mainframes still run very very old code today. Java is targeting Enterprise, and therefore the language evolves very slowly. This was an outspoken goal by Sun. But the development of all libraries should be very fast, but the language development slow and thoughtful. Java is not about adding every feature available, like C++ or C#. It is about maturity and stability.

Pre-IPO Tegile looking at flash tiering, scale-out and the cloud


Re: Fate...

If customers are not satisfied with a product, word usually spreads by anonymous commentors on discussion forums. But no complaints nowhere. Anonymous monikers on different forums are happy and recommend Nimble. If you are anonymous, you can complain. But they dont.

Celebrating 20 years of juicy Java. Just don’t mention Android


Re: Sigh, here we go again.....

Nasdaq super fast stock exchange system Inet (wall street) with sub 100 micro second latency and enormous throughput is written in java. The trick for high performance is to handle memory yourself-> shut down garbage collector. In fact, several super fast stock exchanges are written in java. Or C/c++.

Intel raises memory deflector shields in Xeon E7 processor refresh


x86 no match for POWER/SPARC in business software (databases, SAP, etc)

because x86 does not scale to many sockets. The big difficulty is to make scalable servers. That is the reason x86 is low end, and only POWER/SPARC are high end.

Scale-out servers (clusters with 100s of sockets such as SGI UV2000, ScaleMP, etc) can not run monolithic business software, such as databases, SAP, etc. The reason is such code branches too much, so there will be too much communication between all the nodes. Guaranteeing data integrity in transaction heavy envrionments (locking, rollback, etc) is very communication intensive which punishes nodes far away. Scale out servers can only run HPC number crunching workloads where each node runs a tight for loop, with less communication.

Scale-up servers (large Unix/Mainframe servers with up to 32-sockets) can run business software (databases, SAP, etc). The largest x86 scale-up server has 8-sockets.

This is the reason x86 is no match for high end Unix/Mainframes: scale-up x86 servers that can run business software has maximum 8 sockets. This gives low performance. You need 16 or 32 sockets for really good performance. Scale-out servers can not run business software, so you will never see any scale-out server records in SAP benchmarks because latency suffers.

This is the reason it is impossible to get high SAP scores with x86: scale-up servers stays at 8-sockets which is bad. Scale-out servers with 100s of sockets can not run business software. If you look at the SAP benchmark top list, all are Unix servers: SPARC or POWER. There are no x86 server records at the top. Nowhere can SGI UV2000 servers be seen: they are unsuitable for SAP benchmarks.

I invite anyone to post a SAP benchmark with high score, using a x86 server. You will not find any good SAP x86 scores. Impossible. So, x86 is no match for high end Unix servers running SAP, databases, etc

Debian ships new 'Jessie' release with systemd AND sysvinit


Re: systemd a copy of Solaris SMF


"...With modern Linux, there's very little advantage to using a legacy *NIX unless one is just deeply attached to it or to legacy software that will only run on legacy *NIX..."

As I explained above, there are no large Linux servers suitable for business ERP systems, SAP, Database, etc. The only large Linux servers out there, are all clusters (SGI, ScaleMP, etc) and they have 100s of sockets - a true cluster. When you try to run business software, the largest servers are all Unix, and they have 16 or 32 sockets. There are no such large Linux servers aimed for business, and have never existed (google if you want). You have no other choice than use Unix or Mainframes for large business software servers.


Re: systemd a copy of Solaris SMF

@Bronek Kozicki

Yes, you are correct in that Linux are typically run on the supercomputer top500 list, with 10.000s of cpus, or even 100.000s of cpus. I was sloppy and for that I apologize.

I meant: "nobody use Linux on large 16/32 socket servers to run business ERP systems, such as SAP, databases, etc".

The supercomputers are all clusters, consisting of many compute nodes on a fast switch. You simply add another node, and performance of the supercomputer increase. These servers are called scale-out servers. Scale-out servers are only fit for embarassingly parallel workloads, such as HPC number crunching, scientific computations, etc - where there is not much of communication going on between the nodes. Each node runs a tight for loop which fits in the cache, and when computation is done, the result is finally sent for aggregation and summation. Like SETI@home, which runs distributed stuff on many pc nodes. This code seldom branches, so everything can fit into the cache.

However, I was talking about scale-up servers. One huge large server with 16 or even 32 cpus. They are not clusters, but a single large server. Business software (databases, ERP, SAP, etc) are monolithic and the code branches very heavily, going all over the place. So there are lot of communication going on between the nodes. This type of code makes scaling very difficult, and the limit is typically 16/32 sockets and this domain belongs exclusively to large Unix boxes, such as IBM E880, Oracle SPARC M6, Fujitsu M10-4s, Mainframes, etc.

In fact, until recently, the largest Linux server I have ever seen, was a 8-socket x86 server from IBM, Oracle, Dell, etc. Now there are a 16-socket Linux out there, as far as I know. From Bull, it is called Bullion. But the scaling is awful, as Linux can not handle 16 sockets well in a scale up server. There are no SAP benchmarks this server has won. It is not even on the SAP list. On scale-out clusters, Linux scales excellent.

Ideally to scale well, every socket need a connection to each other socket. And the number of connections increase as O(n^2). Which means that if you have 32 sockets, you will have hundreds of connections! This makes constructing large scale-up servers very difficult. Now imagine a SGI UV2000 server, which has 256 sockets. This Linux server, is exclusively used for scientific computations and no one use them to run business software. With 256 sockets, you would need 35.000 connections, clearly that is not doable. So there are lot of short cuts in the SGI UV2000 server, maybe there are only a few hundreds of connections. So SGI Linux server can not run code that branch much. Hence it is only for scientific computations.

SGI explains themselves about their large Linux server (the Altix is the predecessor to UV2000):


"....Typically, much of the work in HPC scientific code is done inside loops, whereas commercial applications, such as database or ERP software are far more branch intensive. This makes the memory hierarchy more important, particularly the latency to main memory. Whether Linux can scale well with a ERP workload is an open question. However, there is no doubt that with each passing month, the scalability in such environments will improve. Unfortunately, SGI has no plans to move into this [scale-up] market, at this point in time...."

The ScaleMP has a similar server, a huge Linux server with 100s of sockets. It is also exclusively running HPC number crunching workloads.


"...The vSMP hypervisor that glues systems together is not for every workload, but on workloads where there is a lot of message passing between server nodes – financial modeling, supercomputing, data analytics, and similar parallel workloads. Shai Fultheim, the company's founder and chief executive officer, says ScaleMP has over 300 customers now. "We focused on HPC as the low-hanging fruit..."

No one runs SAP on these Linux clusters. SAP is for monolithic scale-up servers. On the SAP benchmark top list, there are no SGI / ScaleMP Linux scale-out servers. All the top benchmarks are Unix scale-up servers with 16/32 sockets. Fujitsu even has a 64 socket SPARC server.

BTW, SAP Hana is a clustered database. And clustered databases have lower performance than a monolithic database, such as Oracle database. If you run a 64TB SAP Hana cluster, vs a Oracle SPARC M7 server with 32 sockets and 64TB RAM - the Oracle scale-up server will crush the cluster in terms of performance.

Scale-up servers with 32 sockets are incredibly expensive. Scale-out servers with 100s of sockets are very cheap. For instance, one single IBM P595 server with 32 sockets used for the TPC-C record, costed $35 million. You can buy many SGI clusters for that sum. Large business servers costs very much, and the big money is there. Look at IBM incredibly profitable Mainframe business. Clusters are not profitable, it is just a bunch of PCs stringed together on a fast switch.


>>Still don't understand why businesses buy [big SPARC M6 servers with 32 sockets] instead of scaling-out [SGI 256-socket clusters]. Cost? Complexity?

>I'm not saying that Oracle hardware or software is the solution, but "scaling-out" is incredibly difficult in transaction processing. I worked at a mid-size tech company with what I imagine was a fairly typical workload, and we spent a ton of money on database hardware because it would have been either incredibly complicated or slow to maintain data integrity across multiple machines.

>Generally it's just that it's really difficult to do it right. Sometime's it's impossible. It's often loads more work (which can be hard to debug). Furthermore, it's frequently not even an advantage.



Regarding Linux being bloated. Well, Linus Torvalds himself says so.


"...Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two per centage points at every release, for a cumulative drop of about 12 per cent over the last ten releases. "Is this a problem?" he asked.

"We're getting bloated and huge. Yes, it's a problem," said Torvalds."


systemd a copy of Solaris SMF

systemd is an abomination of Solaris SMF. For instance, SMF is great on large servers, where the boot time can be long. For instance, IBM P570 server takes 90 minutes to boot (no typo). SMF parallelizes the boot sequence so it is much quicker on Solaris servers. Nobody uses Linux on large 16/32 socket servers (this domain are only for large Unix servers, AIX and Solaris) which means that Linux is mostly for small servers, 1-4 sockets and on the desktop. And on such small computers, you dont need some fancy parallelizing of boot sequence. There are other advantages of Solaris SMF, that systemd does not understand and violates. Why would you build a shell into systemd?

The point is, btrfs is a bad copy of ZFS. systemtap is a bad copy of Dtrace. systemd is a bad copy of SMF. etc etc. Heck, even Linux is a bad copy of Unix, as it is bloated and messy.

Oracle gets ZFS filer array spun up to near-AFA speeds


IBM worst in class

Funny how IBM is so bad; over priced and under performing. Best in the graph is down, to the right. IBM is the opposite; high, to the left.

IBM is exiting all hardware, putting all resources on services. IBM will exit storage too, as they dont seem to interested in developing storage, look at the bad performance and price.

Syneto: Behold, blockheads – an all-flash array... based on ZFS



Tegule runs on OpenSolaris, not solaris. They have also rewritten the zfs dedupe engine. But oracle just bought greenbyte with their superior zfs dedupe engine, which solaris will use now.



ZFS dedupe best in class.

Oracle bought Greenbyte this summer, who rewrote the old memory hungry zfs dedupe engine. The greenbyte zfs dedupe engine will be used in the next solaris upgrade this year. It is fastest and best in class. It can dedupe 5,000 fat VDI virtual machines using 210 TB disk space, down to 4 TB. You can also activate compression in addition. ZFS dedupe will be a real killer when using VMs, and boot 6,000 vms in just five minutes or so.


Critical 0-days in open source? The problem isn't code, it's CASH



The new sparc M7 cpu this year, will be invulneranle to heartbleed and similar attacks/bugs.

BlackBerry's money-making QNX unit touts virty dual-OS devices


Re: Real time is also general purpose

Well, real time Linux is not real time. It is a big difference between soft real time OS and hard real time. Nobody use linux in hard core real time systems. Linux is a toy "real time" system and does not cut it. Just like real time windows does not cut it.

SAP's 10-year HANA gamble: A life without the big boys and girls


What "performance gulf"??

How can he claim that HANA is much faster than oracle? What has he been smoking?

Hana is a clustered ram database, and we all konw that clusters have bad latency when trying to reach far away nodes, i.e performance sucks in clusters especially in latency critical applications (such as databases).And we also know that one single server does not have latency problems, ie SMP servers latency always are superior vs cluster latency. The only advantage of running clustered ram database is that it can scale much more than a single server, ie handle larger workloads (not faster workloads). That is, clusters are slow but handles larger workloads, whereas an SMP server handles smaller workloads much faster. But Hana is a ram database, so it should also be very fast, and handle large workloads at the same time! Or?

Well, this is wrong because, imagine a huuuuuge SMP server, shouldnt it be fastest? Low latency and huuuuge workloads at the same time? Well, this is exactly what oracle will release this year. The sparc M7 server will have 64TB ram, 32 sockets, 1024 cores, 8192 threads. Each M7 cpu will do SQL queries at 120GB/sec. Add in compression (10 to 1)and it can run huuuuge databases directly from ram.

Contrast this with each Hana node; they are tiny. Only a few sockets, and each socket does maybe 5GB/sec SQL queries. And they have little ram, only a few TB. So one sparc M7 server will be much faster than a reasonable sized Hana cluster. So instead of having a Hana cluster with... 100 small x86 nodes, imagine a Hana cluster consisting of two or three sparc M7 servers. A x86 cluster with many nodes will always have much slower latency (when reaching nodes far away), than a small cluster consisting of two or three nodes.

Besides, it is very difficult to do a distributed database while keeping performance up. Data integrity is difficult, and to synchronise data among all nodes. How do you rollback, for instance? Clustered databases are very difficult and error prone. And slower than a single huge SMP server. But maybe the Hana guy did not know of the new coming sparc M7 monster?

Linux kernel set to get live patching in release 3.20


Solaris had this way back

Of course, Solaris had hot patching of the kernel years before linux. Back in... Solaris 8? Or earlier?

SAP unveils its biggest thing for 20 YEARS: Core suite with HANA


Nobody says that Hana only runs on clusters. What I AM saying though, is that Hana clusters runs on x86. And the largest x86 server is tiny, it has only 12tb ram. Almost like the IBM p795 which only has 16tb ram. Or the newest IBM Power8 server called E880, which also has 16tb ram. This means your largest data set in a single x86 node is only 12tb. When you use two or more nodes the performance degrades significantly. Sure, it will still be faster than hard disks, but can't compare to a single 64tb SMP server, which oracle release this year (sparc M7 server will have 32 sockets, 64 tb ram, 8,192 threads, 1,024 cores, and each CPU will do 120gb/sec SQL queries)

So I repeat what I have said all the time: the fastest ram database solution is from oracle, it is not a Hana cluster. The sparc M7 server will crush everything. Imagine running huge databases from ram, lightning fast. Regarding the current sparc M6 which has 32 tb ram, Merrill Lynch liked it, because they had queries which never finished, but on the M6 the queries finished in a couple of hours (it is the largest ram server on the market, so it can hold more data in ram than anyone else, boosting capabilities beyond everyone else). The sparc M7 CPU is 4x faster than the M6 cpu, and does SQL queries much much much faster. And holds twice the ram. I'm telling you, it will crush.

Now, imagine a Hana cluster consisting of several 64tb ram servers from oracle. That should give the highest possible performance. Ever.


Of course ram based Hana is "damn quicker" than oracles disk based solutions. But have you tried oracles ram databases? Oracle have the largest ram servers on the market. Today they have 32tb ram sparc m6 servers. The competition have half of that, maximum


SGI is a cluster


Where is the fud? Please point it out.

First of all, IBM p795 which has only 16tb of ram, is tiny compared to the 64tb ram sparc m7 server. Also, one sparc m7 CPU does 120gb/sec SQL queries. Couple that with 32 sockets and compressed ram database and you will realize it will crush IBM p795 in analytics and other database work. The old power7 CPU, does it do 3-5gb/sec SQL queries? Or less?

Besides the IBM b795 is old and previous generation. The new power8 server, the E880, only has 16 sockets and maximum of 16tb ram. The performance is roughly equal to the old IBM p795 (32 sockets, 16 tb ram). So E880 will be no match for sparc m7 server.

Second, the SGI altix and uv2000 servers, with 10.000s of cores and 64 tb ram, are clusters. Sure it runs single image Linux kernel, but it is only used for clustered work loads. Look at the use cases, all SGI customers are running clustered HPC number crunching. No one use those servers for SMP enterprise business workloads. No one runs SAP on them. But HANA might be suitable, because hana is clustered.

Besides, SGI themselves explicitly says in articles that their servers are only for clustered HPC work loads, and are not suitable for SMP business workloads. You want to read those links? Where are the SMP business benchmarks? They don't exist, because no one use SGI for SMP work loads. Show us sap benchmarks.


Oracle SPARC servers much larger and faster than HANA clusters

HANA is clustered ram database. And clusters can never compete with a single SMP server, the latency as nodes communicates to each other in a cluster is too bad. So the best performance will be within a single node. And the HANA nodes are tiny and have small amounts of RAMS. Also, the cluster is not too big either, there is a limit how many nodes can be added.

Contrast this HANA cluster with (In total 10-20TB(?) RAM with bad latency) to the Oracle sparc m7 server release this year: 64 TB ram in a single SMP server. It is not cluster, so it will be wicked fast with low latency. Apply RAM compression and you can run very very very large databases from memory. Much faster than HANA clusters. Also, consider that one sparc m7 CPU can do 120GB/sec SQL queries, and you have 32 of these CPUs at your disposal. One x86 CPU does... 5GB/sec queries(?).

The conclusion is clear: the fastest database servers are from Oracle. So if you need the fastest SAP analytics you need a 64 TB single SMP database server.

VMware hangs with the cool kids in the Containers gang


Re: Containers = Ancient tech

Containers are quite new, popularized by Solaris. Mainframes had heavy weight virtualization for ages, where mainframe starts up a new whole kernel (using much ram). The difference to Solaris containers are that there is only one kernel active, and all container api calls are mapped to the single kernel. This uses very little ram, ie 40mb for every new container. One guy booted 1,000 containers on a 1gb ram Solaris pc. It was slow (swapped to swap file) but it worked.

Contrast this to VMware heavy weight solution: if you boot 1,000 VMs then each VM will use 2gb ram, eating up 2tb ram.

IBM has copied Solaris containers into AIX and calls them WPAR. Btw, Solaris has copied IBM LPAR virtualization and calls them LDOM.

Years ago, many solaris people considered not zfs nor dtrace being the killer feature, but Solaris containers. Today, years later, everyone is copying Solaris containers., ie docker, WPAR, etc.

Some have started to copy lesser known Solaris tech as well: SMF. Linux calls it systemd. SMF is great in large 32 socket servers, but not great in desktops. Systemd is useless in desktops. Linux has also copied Solaris crossbow (virtualized NIC) and calls it Open vSwitch. Great together with Solaris containers.

However, joyent SmartOS (opensolaris derivative) runs docker in a container, for increased security. In addition, you can run Linux binaries in a SmartOS container. Each Linux app call gets translated to the Solaris kernel api. So if you run 1,000 Linux instances in SmartOS docker, only one Solaris kernel is active, consuming less ram

Five years of Sun software under Oracle: Were the critics right?


Solaris for high end, said Larry

He said that he loves Linux, but it is for low end. Solaris is high end.

Of you look at oracle largest and fastest servers, sparc m6 and the new m7, they exclusively run Solaris. These supercluster servers have many sockets, and as we all know, Linux does not scale well beyond 8-sockets. So how could oracle offer Linux on 32-socket servers? That's not possible. Linux is good for small servers, but you have never found Linux on large servers. I invite you to post links to larger than 8-socket Linux servers.

IBM p795 can run Linux,but it is a unix server, and nobody runs Linux on such a server because of bad performance. Hp Big Tux runs Linux, on their unix integrity server, with 40% CPU utilization under full load! which is bad. SGI altix and UV2000 servers are clusters, and exclusively used for HPC number crunching workloads. ScaleMP servers are clusters too.

The firm that swallowed the Sun: Is Oracle happy as Larry with hardware and systems?


X86 servers are clusters. SPARC are single SMP servers.

The reason to buy oracle/sparc instead of several cheap x86 servers is simple. There are workloads (typically business workloads or databases) that can not run fast on a cluster. You need a large SMP server with as many as 16 or even 32 sockets. In fact there have never existed a larger Linux server than 8 sockets (standard IBM/hp/oracle servers). I invite anyone to post links to a Linux server with more than 8 sockets. And unix servers such as IBM p795 with Linux tucked on top, does not count. It is a unix server, not a Linux server. Besides, Linux scales awful beyond 8 sockets, google big tux. It is a hp unix server with 40% CPU utilization running Linux! under full load.

All large Linux servers with 10.000s of cores, such as SGI altix or UV2000 servers or ScaleMP servers, are clusters. And are exclusively used for HPC number crunching workloads, serving one scientist. In contrast, tightly coupled SMP servers such as huge Unix servers with 32 sockets or IBM mainframes, typically run business workloads serving thousands of users.

Clusters run number crunching for loops in separate nodes with bad latency to nodes far away, you can not run monolithic software, all code is embarrassingly parallel. In SMP servers you run code that branches everywhere with good latency to other CPUs, such as business or database workloads. No one use distributed databases for large workloads, it is too difficult to synchronize data between all nodes. It is much cheaper to buy a huge 32socket unix server.

In fact, SGI and ScaleMP both say their servers are not used for business SMP workloads, and instead only are used for HPC number crunching, I have links where they say that.

Oracle will release the spare m7 CPU with 32 cores, this year which is at least twice as fast than the fastest x86 CPU, and power8 (probably much faster than so). One CPU can do 120GB/sec SQL queries (no typo, x86 and power8 can do... 5gb/sec queries?). It is also immune to the heart bleed bug and others, because of unique security functions. The m7 server will have 32 sockets, 64TB ram and 8.192 threads. It will crush everything. SAP talks about HANA their distributed clustered ram database, but you need a single SMP server for true database performance. With compression you can run very large databases from memory in the sparc M7 server. Wicked fast. A cluster with x86 stands no chance.

Big Blue's biggest mainframe yet is the size of a fridge


Re: Burroughs beat IBM by over a year with the B5000.

"...I suspect IBM's *existing* dominance in the market place, Lawyers, FUD and marketing muscle had a fair amount to do with 360's success...."

That is correct. In fact, the very term FUD originates from IBM, handling the Mainframe competitors:


"...FUD was first defined with its specific current meaning by Gene Amdahl the same year, 1975, after he left IBM to found his own company, Amdahl Corp.: "FUD is the fear, uncertainty, and doubt that IBM sales people instill in the minds of potential customers who might be considering Amdahl products...."


Mainframe cpus are dog slow

I dont get it how IBM can claim that their latest Mainframe can emulate 8.000 x86 servers? Considering that a Mainframe cpu is much slower than a decent x86 server, something does not add up.

This z13 Mainframe gives 110.000 MIPS in the largest configuration z13-NE1, costing millions of USD.


This is only 40% faster than the even slower z12. Since z13-NE1 only has 21 sockets, and each socket is much slower than a decent x86 cpu, how can it replace 8.000 x86 servers? Well, it turns out that IBM assumes all x86 servers idle at 1-2% load, and the Mainframe is loaded to 100%. Now, imagine 21 of the x86 servers start to do some work, how can 21 slower z13 cpus keep up with the work load? It is impossible. IBM marketing division is over ambitious again.

Also, in the link above, the IBM die hard Timothy Pricket Morgan explains that an old IBM P795 Unix server gives 1.6 million CPW. Whereas this z13-NE1 gives 735.000 CPW. This means that the old Power7 server is much faster than this z13 cpu.If you normalize, 32 sockets POWER7 cpus, vs 21 sockets z13 cpus, you see that the old POWER7 cpu is 43% faster than this brand new z13 cpu.

Ergo, the old POWER7 cpu is about 50% faster than this spanking new z13 mainframe cpu. And we also know that the latest x86 cpus are much faster than the POWER7, and even faster than the latest POWER8 cpu. So, tell me how 21 slow z13 cpus replace 8.000 x86 servers?

BTW, this z13 mainframe has 10TB RAM. That is chicken sh-t, considering that the latest x86 servers with 8-sockets has 12 TB RAM. And Oracle SPARC M6 server has 32 TB RAM. And this year Oracle will release their M7 server with 64 TB RAM.


Re: Burroughs beat IBM by over a year with the B5000.

"...The B5000 may have been groundbreaking but, as it ended up being emulated on Xeon processors, doesn't that mean that the original architecture was a dead end?..."

Well, you can emulate IBM Mainframes on a laptop with TurboHercules.


Does that mean z/OS is a dead end? In fact, IBM has threatened and sued TurboHercules, because it was so effective in emulating IBM Mainframes. An old 8-socket x86 server can emulate a mid sized IBM Mainframe, which scared IBM so the TurboHercules emulator has been stopped. Or... "effective" is maybe wrong to say, more correct would be "IBM mainframe cpus are so slow, so you can easily emulate a mid sized Mainframe on a x86 server giving decent cpu performance".

Emulate an IBM Mainframe on a raspberry pi:


Dedupe, dedupe... dedupe, dedupe, dedupe: Oracle polishes ZFS diamond



As long as you stay on ZFS version 28 you can freely switch operating systems between Oracle Solaris and others: Mac OS X, Linux, OpenSolaris, FreeBSD, etc.

Oracle ZFS and OpenZFS diverge after v28. So make sure you do not upgrade ZFS beyond v28 if you want to freely switch OS and avoid vendor lockin. I dont think Oracle ZFS dedupe force you to upgrade zfs beyond v28, which means you could switch OS to Oracle Solaris and make use of heavy dedupe. If it doesnt please you, you just switch back to another OS.

HPC bod SGI racks UV brains, reaches 30 MEEELLION IOPS


Re: Clusters


You are misinformed. There are (at least) two different types of scaling:

1) horizontal/scale-out scaling, i.e. a cluster (typically have 10.000s of cores and 100s of TB RAM)

2) vertical/scale-up scaling, i.e. a single large fat server (typically have 16-32 sockets and 8 TB RAM) in a SMP style

The SGI servers have always been clusters. Even SGI confirms this. Whenever you see a server larger than 16/32 sockets, you know you are dealing with a cluster. Clusters are only used for cluster workloads, such as HPC number crunching workloads or other parallel workloads. Clusters are typically serving a single user, a scientist that starts up a workload running for hours/days. All the large Linux servers having 10.000s of cores out there, are clusters. Clusters are very very cheap, you basically pay the hardware cost. If you buy a cluster with 100 cpus, it costs 100 x 1 cpu.

SMP servers are very very expensive and difficult to make. In this category you have large Unix servers and Mainframes. IBM 32 socket Unix P795 server for the old TPC-C world record, costed $35 million. Yes, one single server. To create a huge server with as many as 16 or 32 sockets, are very very difficult. Scaling up is very difficult, and that is why these servers are very very expensive. Why do you think huge SGI servers with 10.000 cores are cheap, and 16 socket Unix servers are very very expensive? You could buy many clusters for the price of one large Unix SMP server. SMP servers are typically serving many 1000 of users, running business software. If you look at the SGI customers on their homepage, none of them are using SGI servers for business ERP software, all Altix/UV servers are used as clusters. For isntance SAP HANA is clustered software.

Clusters can not replace SMP servers on business workloads. That is the reason there is always a market for huge Unix 16/32 socket servers, including Mainframes. There have never been a Linux vendor selling 16/32 SMP servers. Such large Linux SMP servers have never been for sale, they simple have never existed. You are invited to link to a Linux server with 16 or 32 sockets. Good luck finding one. Linux can not scale to 16/32 socket servers, because the hardware has never existed. Of course, people have compiled Linux onto large Unix servers, such as IBM P795 / HP Unix Integrity 64 socket server (google Linux Big Tux) - but the scaling is awful. Nobody buys a huge Unix 16 socket server for many millions to run Linux.

In short, SGI clusters are never used for SMP business workloads, just look at the use cases. They are exclusively used for clustered workloads.

SGI and ScaleMP (another Linux vendor with 10.000s of cores) explains this best. Both of these servers use a single image Linux kernel. Here they say that SGI and ScaleMP are only used for clustered workloads, and their huge Linux servers can not replace a huge 16 socket Unix server (because clusters can not be used for SMP workloads):


"...The success of Altix systems in the high performance computing market are a very positive sign for both Linux and Itanium. Clearly, the popularity of large processor count Altix systems dispels any notions of whether Linux is a scalable OS for scientific applications. Linux is quite popular for HPC and will continue to remain so in the future,


However, scientific applications (HPC) have very different operating characteristics from commercial applications (SMP). Typically, much of the work in scientific code is done inside loops, whereas commercial applications, such as database or ERP software are far more branch intensive. This makes the memory hierarchy more important, particularly the latency to main memory. Whether Linux can scale well with a SMP workload is an open question. However, there is no doubt that with each passing month, the scalability in such environments will improve. Unfortunately, SGI has no plans to move into this SMP market, at this point in time..."


"Since its founding in 2003, ScaleMP has tried a different approach. Instead of using special ASICs and interconnection protocols to lash together multiple server modes together into a SMP shared memory system, ScaleMP cooked up a special software hypervisor layer, called vSMP, that rides atop the x64 processors, memory controllers, and I/O controllers in multiple server nodes....vSMP takes multiple physical servers and – using InfiniBand as a backplane interconnect – makes them look like a giant virtual SMP server with a shared memory space. vSMP has its limits.


The vSMP hypervisor that glues systems together is not for every workload, but on workloads where there is a lot of message passing between server nodes – financial modeling, supercomputing, data analytics, and similar parallel workloads. Shai Fultheim, the company's founder and chief executive officer, says ScaleMP has over 300 customers now. "We focused on HPC as the low-hanging fruit "


Here is another discussion on huge scale-out clusters can never replace 16 socket SMP servers for enterprise business workloads:


"I'm not saying that Oracle hardware or software is the solution, but "scaling-out" is incredibly difficult in transaction processing. I worked at a mid-size tech company with what I imagine was a fairly typical workload, and we spent a ton of money on database hardware because it would have been either incredibly complicated or slow to maintain data integrity across multiple machines. I imagine that situation is fairly common.


Generally it's just that it's really difficult to do it right. Sometime's it's impossible. It's often loads more work (which can be hard to debug). Furthermore, it's frequently not even an advantage. Have a read of https://research.microsoft.com/pubs/163083/hotcbp12%20final.... Remember corporate workloads frequently have very different requirements than consumer."



These Linux servers are nothing more than a cluster, which is evidenced if you look at the workloads they are used for. For instance, SAP HANA is clustered. These SGI clusters can not replace a large SMP server such as 32-socket IBM P795 or Oracle M6-32. Clusters are only used for parallel workloads such as HPC number crunching, never for SMP business workloads.

Just look at all the SGI business cases, in every single case they are used for parallel workloads.

Amazon, Docker hop in bed: What happens in Vegas WON'T stay in Vegas


Solaris Containers

Back in the days when Solaris 10 was released, there was a big stir about ZFS and DTrace. Some people said that those are not that interesting, but Containers were the big thing. Containers were a new type of virtualization, a light weight virtualization where you only used one kernel. Solaris Containers used 40MB RAM and 100MB disk space for each new container. The Linux camp never got ZFS nor DTrace nor Containers. Later, BTRFS was created as a ZFS wannabe. And Systemtap as a DTrace wannabe. While Solaris people were talking about the big benefits about Containers, they were ignored by the Linux camp (Linus Torvalds said he never believed in virtualization and it was not a priority in Linux). Now, finally, the Linux camp also has realised that light weight virtualization is something wickedly cool. A couple of years late to the party, they tout lightweight virtualization as the greatest thing since sliced bread.

But still Linux camp has not grokked Solaris Containers. Solaris containers were reworked many times, and work started 2001 (or was it 1999?). It was called BrandZ and rewritten again under a new name, etc etc etc. After a couple of iterations Solaris Containers were released 2004. The difference to Linux version is that you can install other OSes in Solaris Containers, such as Linux. All Linux API calls are mapped to Solaris API calls. You could create a FreeBSD container as well, the code stubs are there. IBM has also copied Solaris Containers and call it WPAR. BTW, I think Bill Joy was involved in CHROOT back in the 1980s (one of the founders of Sun Microsystems and Solaris).

Kryder's law craps out: Race to uber-cheap storage is voer


The actual reason for slowdown is greed - HDD crisis was fake

Actually, just before the Thailand floodings there were 4 HDD vendors and HDD prices fell rapidly, competition was fierce. But the fourth vendor got bought, so the remaining three vendors formed an oligopoly. Slightly after the Thailand floodings occured, and the three vendors declared HDD shortage and prices skyrocketed (2-3x increase) and never actually came down to the old rapid development pace. Competition disappeared.

But fact is, during that flooding year, all three vendors shipped MORE disks than ever, and they posted record profits. There never were a disk shortage. It was all a lie. That is the reason we stayed at 2TB disks for several years, and no HDD development occured. With the old pace, we should have seen disks double in capacity fast, just as before the floodings. Instead of staying at 2TB disks, we should rapidly have seen 3TB, 4TB, etc. Today we would have seen 12-14TB or so, and 6TB would probably would have been standard. But because of the HDD oligopoly the pace crawled to a halt, why would the vendors spend money on R&D when they could stay at expensive 2TB disks?

Then came SSDs and the pace quickened a bit again. So lately (as 1TB SSDs have been announced) we have seen 8TB HDDs. Thanks to the SSD competition 4TB disks are not considered large enough, so they quickly released 6 and 8TB disks as of late. When SSDs reach 2-3TB, only then we will see 12-14TB disks. Not before.

Here is a series of articles, uncovering the fake HDD crisis and the oligopoly:


IBM, backing away from hardware? NEVER!


Re: Need to know who @MadMike is

You're welcome. :-)


Re: Need to know who @MadMike is


I know you enjoy attacking and tearing Power apart because you fear it and it threatens what you know and like. Understandable.

Well, if the IBM crowd had not spread so much FUD about SPARC ("SPARC is dead", etc) and other cpus during the years, none of my posts would have been written. "What comes around, goes around". But it is always funnier to attack others, right? Suddenly when I post links about IBM says AIX is going to be killed, all over the place - it is not fun anymore right? The difference is that IBM crowd FUDs and make up lies. I do not, I only post links from IBM, etc. So when you spread FUD it is ok. When someone links to IBM - it is not ok. Right?

Don't care about M6 other than Power8 E870 delivers almost 4X the number of SAP Users per core. That translates into less software licenses and cost while doing more work on each processor. Stronger cores make for more efficiency.

So you acknowledge that SPARC M6 exists? So SPARC is not dead anymore? Are you contradicting yourself again?

Regarding core talk. A company buys servers looking at business gains. If one cheaper server can serve 10.000 users, and another server only has 16-sockets and can only serve 5,000 users - which server do you think provides the most business advantage? You tell me.

With regard to M7 - I'll take the bet now that M7 won't be twice as fast as Power8....not on a per core basis.

So you admit M7 might be twice as fast as POWER8, cpu wise? So the M7 cpu might be a twice as fast as a POWER8 cpu. In my book, that makes the M7 cpu twice as fast as POWER8 cpu. But not in your book, because POWER8 might have faster cores. Even if POWER8 core is faster, it does not carry over to make the POWER8 cpu twice as fast.

Have you heard about comparing apples to oranges? You reason about apples, and try to make everyone believe about oranges too. That is faulty logic.

On your last T2+ and Cell comment - it's time to take your medicine again. The shadows are coming out and beginning to attack you.

But these benchmarks exists, you really do need fourteen POWER6 cpus to match four SPARC T2+ cpus. Am I crazy for have studied these benchmarks? I can give you links, so you can study them too - which also will make you crazy. Everybody that study a benchmark where SPARC beats POWER are crazy. Well, that is perfect and fine IBM logic. "Have you studied the SPARC T2+ benchmark SIEBEL v8? Then you are a tainted soul and crazy!"


Re: Need to know who @MadMike is


SPARC is dead.

This is pure FUD when you say this to your customers. Do you have anything to back this up? Interviews from Oracle or Sun executives? Or did you just make this up? Just like IBMers chanted all the time: "SPARC is dead" spreading FUD?

If you want to stand on the fact that a SPARC derivative exists running Solaris, fine.

In case you did not know, SPARC M6 is alive and well. And next year SPARC M7 arrives. It will be at last twice as fast as POWER8 in general. And in SQL queries it will be at least 10x faster than POWER8, or maybe even 20x faster?

It's a decent chip for the T series. It finally doesn't suck after the first 3 generations did

Well the 2nd generation SPARC T2+ beat the sh*t out of POWER6 in SIEBEL v8 benchmarks. You need fourteen POWER6 cpus running at 4.7GHz to match four SPARC T2+ cpus running at 1.6GHz. I dont know what IBM POWER6 architects did, but it is awfully bad in some aspects. So you are wrong here again.

For instance, you need thirteen (no typo) CELL cpus at 3.2GHz to match one single SPARC T2+ in string pattern matching. Second generation SPARC beat the sh*t out of CELL too, on this.


Re: Companies buy software and a neck to throttle


Wow, pathetic! 883 and 996 is all you need to know. That is the # of Users per core for Power8.

I am sure companies prefer servers with the highest SAP capacity. What good does a single core server do with a very high core SAP number? Let us say one single core server reaches SAP 2000 users. And another server has 1024 cores, each core serves 500 users - now which server do you think companies prefer if they need to do SAP work?

Companies look for the total server throughput, in case you did not know.


Re: @MadMike - get a life


That article uses Intel material that came from their Ivy Bridge announcement. Go figure they made those claims. It is also preposterous. Your extrapolations are wrong again and further damage your credibility.

So you reject that article, because the benches came from Intel. But you insist on us accepting benches from IBM? Where is the difference?

The benchmarks are out there. Go look for yourself. SPEC, SAP, Oracle.

Oh, yes, just like the POWER roadmap is out there for me to find, if I look hard enough? IBMers = no links nor benchmarks. No nothing. Just "trust me"

I've done my best to not call you a Troll here but with idiotic statements like this it makes me think you are just a flame thrower, trouble make

Calm down, you are loosing it. It makes you look bad when you try to insult others. Regarding the E880. An 12TB RAM server can run things almost as fast as a 16TB RAM server, if the data fits into RAM. An 12TB RAM server is much faster than a 16-socket E880 server with 128GB RAM, because it will need to swap all the time. Having much RAM is more important than having many cpus and less RAM.


Re: Funny how


Your also on repeat with the 15 Power6 procs vs four T2+ procs. Listen and listen well so it sinks in. The fourteen you reference is fourteen cores or 7 dual chip modules or 7 processor books or 7 sockets. Your T2+ with four procs is actually 4 x 16 cores or 64 cores. So, you are trying to convince the reader a SPARC T2 with 4 beats a Power6 with 14 when in fact it is SPARC T2 with 64 and Power6 with 14. This is what you do, why you have no credibility and why it's not worth wasting my time answering each of your other crazy points.

Sorry to say this, but... you are wrong on the facts. Again. Or you know this, and try to spread FUD. Or ignorant. I can not tell. Maybe a combination?

The four SPARC T2+ running at 1.6GHz, has 8-cores each (not 16 cores). Which means the SPARC server T5440 has 32 cores in total. Running at 1.6Ghz makes them 32cores x 1.6 GHz = 51.2 GHz.

Fourteen dual core POWER6 running at (give or take) 4.7GHz has in total 28 cores. So these three POWER6 servers spend in total, 28 cores * 4.7GHz = 131.6 GHz.

We see that no matter how you count (cores or cpus or GHz), the SPARC T2+ gravely humiliates POWER6 and beats the sh*t out of POWER6. So you were wrong again on "Nothing SPARC has beats the sh*t out of Power. Not Power4, Power5, Power6,..."

Apparently you are discussing which cores is fastest (SPARC T2+ cores humiliates POWER6 in SIEBEL v8 benchmarks). The rest of the world, discusses cpus. Not cores. I do not claim that "SPARC core is the fastest!", no. I claim "SPARC cpus have superior performance". Which you also have to admit if we consider cpus, instead of cores or GHz or bandwidth. But that is the reason IBM and you, so desperately cling to the Core talk. Because if we talks about cpus, then IBM looses big time. And you know that. And IBM knows that. That is the reason you adamantely refuse to talk about CPUs.

I dont get it. How can you claim superiority of the POWER cpu, when you talk about cores? Let us assume you establish superiority of POWER core, but then you can not claim superiority of the CPU. Superiority of cores does not carry over to cpus. Dont you get it? I have tried to explain this to you many a times, but to no avail.


I have a open offer to Oracle and you @MadMike.

What have Oracle to do with this? I have never worked at Oracle nor Sun, I have always worked in Finance. Now I do algorithmic High frequency trading math stuff at a large bank.

But you know you would loose. When I say "Oracle SPARC reaches 10,000 in this benchmark, whereas POWER8 only reaches 2,000" and you say "the POWER8 has a stronger core, therefore the POWER8 server is faster" you will only look dumb. No one (except IBMers) would claim that a 2,000 server is faster than a 10,000 server. People would just consider you a lunatic when you claim that "2,000 is a larger number than 10,000. It's true! IBM numbers are much stronger than other numbers!". I advice you to avoid that humiliation to meet me in a debate, you can not even win here. IBM executives would only feel embaressed.

Actually, there was another IBMer here (J... something), who claimed that "POWER6 is faster than x86 on linpack because POWER6 core scores higher". And still, the x86 linpack benchmark was twice as high as the POWER6 benchmark. But he was dead serious on POWER6 being faster on linpack calculations. It only made him look like a lunatic, but still he continued.


You can continue to make false and inaccurate statements on here with little accountability

Hmmm... ?


Power8 outperforms x86 by 2X, SPARC by 3-4X.

Do you have links proving your claims? For instance, here it says that Intel x86 E7 is twice as fast as POWER7, and POWER8 is also twice as fast as x86, which makes x86 as fast as POWER8. Which means you are wrong. Again,


The Linux on Power servers have price parity with x86,

So you agree that POWER8 servers are as cheap as x86 now, making them low margin business. IBM only does high margin bizz. If trend continues with even lower prices than x86, IBM has to kill off POWER.

These are the 2 socket 24 core servers that match Ivy Bridge 4 socket 60 core servers in performance

Links please. Above here, you confessed that IBM and IBMers said that SPARC was dead. At the same time there were no credible links confirming this; no interviews with Sun executives, no nothing. This is actually the pure definition of FUD: spreading false negative made up rumours - Fear Uncertainty and Doubt regarding SPARC. So now that you confirmed that IBM and IBM crowd FUDs how can we believe you on this? That is why we all ask for links. Where are the POWER roadmap with POWER9?

Customers that demand maximum reliability, serviceability, consolidation and performance will go with enterprise servers. These servers scale to 192 cores and 16 TB of Ram.

You realize that IBM P880 with 16 sockets and 16TB RAM is chicken sh*t? An 8-socket x86 server today has 12TB RAM. And x86 is twice as fast as POWER7, making it in par with POWER8 according to my link here. POWER8 does not scale much more than x86. Why is that? Limitations of the POWER8 architecture?

You keep talking about these 120GB SQL queries Troll. Oracle internal benchmarks I'm guessing

No, Oracle executive (Larry or John Fowler?) said this officially on stage when presenting SPARC M7. What do you say if this turns out to be true? What do you say if M7 really do 120GB/sec SQL queries for real? You realize that POWER8 has nothing to counter this?


Re: Need to know who @MadMike is

I enjoy technology, desire competition and respect competitors. I don't suffer liars and cheaters very well.

But you confessed in a post above here, that IBM and the IBM crowd said that "SPARC was dead" with no links to back that up. For instance, there were no interviews from Sun executives saying that they were going to kill off SPARC. In short, this is pure FUD (spreading false negative made up rumours). So, how can you dont "suffer liars and cheaters"?


Re: Companies buy software and a neck to throttle

Hello Troll hunter

You have some nice numbers there. Do you have links too so you can give us the SAP benchmarks for the Fujitsu vs IBM POWER8. That would be interesting, who has the fastest servers? SPARC or POWER? I am not interested in core per core, nor GHz per GHz, nor Bandwidth vs bandwidth, etc.

Just give us the SAP benchmark numbers and dont modify the benchmarks to make them look good.


Re: Funny how


@MadMike You are a troll who looks for IBM Power articles to spew your constant lies and hyperbole. Your agenda and goal are obvious. You get off on stirring things up. In a courtroom you would be labeled a vexatious litigant or serial abuser of these forums. Responding to you is pointless as you lack character

But now you ARE responding to me. :) But I would rather much prefer if you answered my questions instead: Why is IBM exiting all hardware bizz, Why is there no POWER roadmaps anymore? What does IBM mean when they say "AIX is going to be killed and replaced by Linux", etc etc etc? Maybe you wont answer, because you know I am going to ask for links - and the IBM crowd rarely have links to back up their claims. Some would think such claims are unsubstantiated and made up?

Nothing SPARC has beats the sh*t out of Power. Not Power4, Power5, Power6,...

Well, you do know that you need fourteen (14) POWER6 cpus clocked at 4.7GHz or so, to match four SPARC T2+ clocked at 1.6GHz at official SIEBEL v8 benchmarks? You need 65GHz of IBM POWER6 to match 6.4GHz of SPARC T2+. What does that tell you, except that SPARC T2+ is much much much faster clock per clock than IBM POWER6? It tells you that you are WRONG. Again. SPARC beats the sh*t out of POWER6 on some benchmarks.

And above all, SPARC T2+ is much faster clock per clock than POWER6. This must mean that SPARC always is much faster than POWER6. Right? Because SPARC T2+ is much faster clock per clock, it must mean that the SPARC T2+ cpu is the faster cpu.

...Power7 or Power8. Here is the scoop Troll. Sun and Oracle's approach is to create servers with weaka$$ cores but lots of them. 256 then 384 and 512. You run a benchmark to get a result. Because you have 512 cores and 32 chips you claim victory and the worlds fastest processor because that is what Troll's do. The reality is that your servers are pieces of sh*t and you have to lie about Power because that is who you fear the most. Power8 is delivering roughly 2.7 - 4X the performance per core on about every benchmark that are common between them

But who in earth is interested in the fastest core? Does it matter which cpu do more work, core per core? No, we are comparing CPUs to cpu. We are talking about the fastest cpu. Not which cpu does more work clock per clock (SPARC T2+ wins) nor core per core.

SPARC is clearly the SUPERIOR cpu because it beats the sh*t out of POWER on total benchmarks. If you want to talk about core vs core, then I can talk about Hz vs Hz. or bandwidth vs bandwidth, or ALU vs ALU, etc. Dont you think it is stupid to say that one cpu has higher Bandwidth, and therefore it is the faster cpu? You need to look at the BENCHMARK. No one claims superiority by benchmarking one core, or one Hz, or the Bandwidth.

How many GB does POWER8 do, in terms of SQL queries? SPARC M7 does 120GB/sec SQL queries. Can POWER8 manage 1-5GB/sec SQL queries? Anyway SPARC M7 beats the shit out of POWER8 on SQL queries (which is expected as Oracle is a database company, IBM is not).

If you don't like the "per core" conversation how to you control (and reduce) software licensing/maintenance while delivering the consolidation and performance required for all workloads? You either say "per core" performance matters or it doesn't. The sum of the cores equal the chip/socket performance so it needs to matter somewhere.

Well this is plain WRONG. You need to factor in how MANY cores you have too. The sum of the cores equal the cpu performance - is so wrong on many levels that either IBM has not understood basic logic, or IBM are trying to fool everybody. What is most likely? Maybe both?

Explanation: Say cpu AA) has only one core, but the core is slightly faster than the core in cpu BB). But cpu BB) has 16 cores. Which cpu is faster? IBM says that AA) is faster, because it has one single core, which is slightly faster. But BB) has 16 cores! So clearly you need to factor in how many cores each cpu has. You can not look at only one single core and conclude the entire cpu is faster, ignoring how many cores there are.

It is like: "SPARC T2+ does in general 2x more work Hz per Hz than POWER6. Therefore the SPARC T2+ is twice as fast as POWER6". But here we dont factor in how many Hz each cpu has. Maybe SPARC T2+ has very few Hz, and POWER6 has many Hz. Then it is not true that SPARC T2+ is twice as fast as POWER6, just because T2+ is more effective Hz per Hz.

So, as I tried to explain to you numerous times on this: YOU CAN NOT COMPARE CORE VS CORE AND CONCLUDE ONE CPU IS FASTER. That is WRONG. If you still did not understand this, please read it again, and reread. But slowly.

If I have £1 and you have $16 - who has more money? I have more money, because 1 GBP equals $1.5? Wrong answer. We need to factor in how many pounds I have, and I have only one pound. So I am not richer than you. Even though IBM tries to make fool everyone that if you have one single stronger unit, it is better than having many weaker units.

I never heard anybody from IBM say SPARC64 is dead. I've heard many a customer, pundit and competitor to include IBM and partners alike say that SPARC is dead Troll.

So you confess you IBMers said that SPARC is dead? And all the time, there were no interviews from Sun saying they were going to kill off SPARC. There were no such credible links. All the time the IBM crowd (including IBM) told everyone that with no links to back up - that is the exact definition of FUD. So you confess that the IBM crowd FUDed on this. Just what I claimed. I would not be surprised if you were one of the FUDers too. This is the reason everyone asks about links from IBMers. They FUD so much. Now where are the POWER roadmap? Or is it just FUD again?

I never actually understood why the IBM and the IBM crowd FUDs so much. If you have inferior products, you need to FUD. If you have good products and still FUDs, it means you want to play unfair.

I remember when IBM said that SPARC Niagara many lower clocked cores are dumb and a dead end. The future was 1-2 core high clocked cpus. Because "databases like strong cores best". So IBM mocked SPARC Niagara and talked about future stronger 6-7GHz POWER cpus with 1-2 cores. Late to the party, IBM realised that high GHz is a dead end, and parallellisation is the future. So IBM finally understood that if you want many cores, you need to clock them lower to not exceed the wattage budget. And today POWER8 is very similar to SPARC cpus, with many cores and many threads. But today it is the best thing since sliced bread, and IBM never talks about the fiasco with single high clocked core CPUs instead. I would not be surprised if IBM claims they did not copy SPARC Niagara design. So, where are the 7-8GHz single core POWER cpus today? Fiasco.


Re: Just a few things..


I've been in the business for 20 years now and one thing I know is that selling an entire solution is much more profitable than just selling the parts

This is true. That is why Oracle are selling their engineered database boxes.

The very highest deals, in fact, are those that begin with a business consulting engagement. If a company can successfully diagnose a problem or discover an opportunity on the business side, then their technical solution to that problem/opportunity, despite a high price tag, is almost unassailable by less well-informed competitors. Bottom line: Solutions = $$

This is also very true. IBM consulting team hopes to drive sales. But future IBM sales will be based on x86 and Linux. It will be much cheaper than developing their own OS and CPU (that are only slightly better than x86 and Linux).


Re: Funny how


I would also point out that being 'in the know' doesn't necessarily mean anything. Take the Sun Rock processor example that a lot of people cite in these comments. Sun repeatedly told the analyst community, myself included, that Rock was healthy and coming along. Maybe a little late, but it's going to be awesome when it's released. We all know what happened there, right?

Rock did taper out and Sun ran tests on it. It was too slow though. But parts of Rock has finds its way into SPARC M7 cpu, which is going to be a real killer (120GB/sec SQL queries).

But the main thing about Rock, is that it never went into the official roadmap. Companies try out different stuff all the time, but most of the tries fail. It is only when it is on the roadmap we know that the company is serious with bringing the product to the market. So, there are no POWER9 on the roadmap. And if it were, it will most likely take 3-4 years before it arrives, at which point x86 will have 32 cores (just as SPARC M7) and beat the sh-t out of POWER9. So there is no point in releasing an inferior POWER cpu. IBM knows this.

And, why would a roadmap be under NDA? The point of a roadmap is that customers can plan long term, so they know what is coming. If the customers are not allowed to know, it kind of defeats the purpose of a roadmap, they can not plan along.

So you are not a journalist? I would love to publish an article here on AIX and POWER. I just need to reformulate my posts and correct my language. That article would draw much attention, it would have lot of links to IBM and benchmarks. :) :) :)


Re: Funny how

Why is that the IBM crowd always "hears" something or "sees" something, but never post any links? Nothing to back up things, just posts rumours. That might be true or made up. No benchmarks, no roadmaps, no nothing. I remember when the IBM crowd vehemously assured us that they heard Sun executives telling them in confidentiality that SPARC64 is dead, and we all better migrate to POWER7 quick. They posted no links or so, they just heard something from a "very credible Sun source". And how dead is SPARC64 today?


Re: Companies buy software and a neck to throttle

SPARC does not scale as well in single threaded performance as x86 or POWER

Have you heard about Fujitsu SPARC64 Venus cpu? It has only two threads per core, and they are very strong in the 64-socket M10-4S server. Also, Oracle's SPARC can nowadays dedicate an entire core, to a single thread. On the fly. So the SPARC core can have massive throughput or single strong threads.

Regarding scaling, IBM scales only to 16-socket with their POWER8 nowadays, P880. It has only 16 TB RAM. x86 scales to 8-sockets and having 12TB RAM. Not much of a difference to the largest POWER8 server P880. They play roughly in the same ballpark today RAM wise. And cpu wise, the fastest x86 are twice as fast as POWER7. And POWER8 is also twice as fast as POWER7. Which means that x86 and POWER8 are roughly equal in performance. Except that x86 has more RAM.

Whereas SPARC scales to 64 sockets and 32TB RAM today, and next year will have 64TB RAM. And 8.192 threads. And a single SPARC M7 cpu will do SQL queries at 120GB/sec. Let us see POWER8 or x86 try to match that, what do they achieve now? 1 GB/sec queries? Or even 5 GB/sec? Anyone know? Do they climb over the 5GB/sec fence? Any DB admin that can chime in here?


BTW, I like the statement from Anonymous Coward below: "the advantage of not updating AIX is that you dont have to recertify your software". Wow, I never heard that one before. Maybe Microsoft should try that one? Or how about this one (also from IBM): "No one cares about performance anymore, Oracle's superior performance claims are so 2000ish". Yes, its true! LOL!


"...Companies today, IBM Parris argued, have different priorities than the raw speed of chips..."

How about SPARC M7 detecting buffer overflows and what not, then? Heartbleed bug would have been stopped dead in its tracks. Not even Coverity could detect Heartbleed bug (now they added that functionality recently). Besides SPARC M7 being more than twice as fast as POWER8, it is much safer too. Of course, if we talk about SQL queries, then M7 is probably 10x faster or even more. I doubt an entire 16-socket IBM P880 server can reach 120GB/sec. I would not be surprised if a single SPARC M7 cpu is faster than an entire P880.


What "broader portfolio" of IBM? IBM has no portfolio left. IBM has sold off almost all hardware. Only POWER and Mainframe and Storage is left. Everything else is sold.

POWER is next in turn to be axed. This was most probably the last POWER roadmap, no new roadmaps with POWER9 will find its way out of Amarok. Just like last Itanium roadmpa.

x86 has catched up on POWER8 now. IBM knows that, and IBM foresees that POWER9 will be slower, and cheaper than x86. Why resist? Why not just switch to x86 cpus instead of IBM developing it's own cpu which is slower and also try to be cheaper? No point in doing that.

BTW, I would like to see a x86 or POWER cpu that does 120GB/sec SQL queries. That would be interesting and put pressure on SPARC M7 cpu.


Re: Funny how


Never seen your rants before reading this but looking at your posting history you clearly work for Oracle and spend most of your time with pathetic slating of the competition.

You're a bit pathetic, aren't you?

How about you answering my questions instead of resorting to name calling? It seems you have nothing to say, no links to counter my questions?


Re: Funny how


If you can publish such an IBM defending article here, then I can publish too, as a counterweight. I can brush up this article and publish it, sure. That would be fun to see here. :)

1. "AIX is dead" I don't see or hear this at all from IBM, anyone working at IBM, or customers - either formally or informally....The article you link in your reply is from 2003....11 years ago....and has obviously not come to pass.

In the article IBM says AIX is a dead end. I did not make this up, it comes straight from the horse's mouth. Further, IBM says regarding "11 years ago":

"...A replacement "won't happen overnight," Mills said, but years of experience designing operating systems at IBM and other companies means developers know just where Linux needs to go. "The road map is clear. It's an eight-lane highway". No one believes replacing AIX with Linux could happen quickly, or that IBM will leave its AIX customers in a lurch. But the degree of Mills' Linux support surprised some.

"They've denied it would replace AIX in the past," said Illuminata analyst Gordon Haff. "Perhaps their thinking is beginning to shift. They've been quite clear that they see Linux as picking up AIX technologies maybe a year, two years later, but they've certainly been quite circumspect about saying Linux would ever replace AIX."

"Steve's view is really on a multidecade time frame," said Nick Bowen, vice president of Unix and Intel server software development at IBM."

Look at the last line. In 20 years AIX will be dead. We can see the signs now: no new AIX releases, development has slowed down, or halted. Why is IBM betting more on Linux than AIX, and why has IBM said AIX will be killed?

2. There is also a Power processor roadmap that includes Power9 and other processors. From what I've heard from very reliable sources, there are Power9 processors running in labs today.

Yeah? Show us the roadmap then. "Show me the money". And you "heard" something from someone's aunt's dogs friend's owner that once saw Elvis Presley on the train? That sounds really credible. Or not. Instead of claiming unsubstantiated things, show us the links and we can stop the discussion.

3. x86 vs. Power: Intel revs their processors more quickly than IBM revs Power processors. The typical pattern is that a new Power processor will offer significantly higher performance than the cream of the crop x86 chip... So comparing today's best Intel processors vs. older Power7 designs isn't exactly informative or fair.

x86 can release more often, because the x86 companies spend more on R&D than IBM. In the beginning, x86 could not catch up on POWER. But now x86 catches up all the time. The trend shows that POWER is not that much faster anymore.

And I did compare x86 to the latest POWER8 too, not only POWER7. I said that POWER8 is 2x as fast as POWER7. And x86 is also 2x as fast as POWER7 today. Which means x86 is as fast as POWER8 - but has more RAM. Which makes x86 2-socket server faster than POWER8 2-socket server, because if you have more RAM, you can work faster and dont need to swap to disk.

And BTW, IBM claims that one mainframe can replace 1.500 x86 servers. It turns out that all x86 servers are antique with 256MB RAM and 800MHz or so, and they all idle. It is not fair to compare the latest Mainframe to antique x86 servers as IBM do. But IBM does compare new hardware to old hardware

5. You use the words 'desperate' and 'desperately' a few times in your masterful summation. However, I have to point out that I'm not desperate to defend much of anything,

Some would wonder why there are an article out there stating that "No, AIX and POWER will NOT be killed, trust me" arguing against what IBM has officially said "AIX will be replaced with Linux". It reeks.. something. Maybe not desperation. But something.

And again, I have never worked at Oracle nor Sun. I have always worked in finance. I work in a large financial institution with algorithmic trading, doing the heavy math stuff.

And lastly, to the IBM crowd out there: What goes around, comes around. Or, you reap what you sow . If you had not done what you did, people would not have to write posts like mine. Are you having a good time? Like this much? Rub it in?

'Urika': Cray unveils new 1,500-core big data crunching monster


Re: Met Office

8TB RAM for 1,500cores? That is chicken sh*t. Oracle has 32 socket SPARC servers with 32TB RAM, Fujitsu has 64-socket 32TB RAM SPARC servers today.

And next year SPARC M7 32 socket servers will have 64TB RAM.

Hey - who wants 4.8 terabyte almost as fast as memory?



Do you call SPARC M7 vaporware? Well, the M6 server today has 32TB RAM. The largest on the market, by far. The competitors largest servers has half of the memory, and half the number of sockets.


If we talk about TB sized RAM caches, what is better than real RAM (which is faster) and more of it than 4TB cache?

"Put up with SPARC"? The SPARC M7 server released next year, will be at least twice as fast as anything else if we talk about cpu power. And 64TB RAM can store lot of data, so you dont have to go out to disk - which makes the M7 server even faster. A single cpu can make 120GB/sec SQL queries. Worlds fastest server it will be.


Why not buy a 32TB SPARC server, then you have all the RAM you need. Next year the SPARC M7 will be 64TB RAM. :)