Posts by Kebabbert

Re: @Matt

Matt,

No, ZFS can't cluster. This is actually a claim of yours that happens to be correct, for once. Non clustering is a disadvantage, and if you need clustering, then ZFS can not help you. But you can tack distributed filesystems on top ZFS, such as, Lustre or OpenAFS.

.

.

"...More evasion. I pointed out that not one vendor has dropped expensive Veritas for "free" ZFS and all you do is go off on a tangent. Just admit it and then go stick your head back up McNealy's rectum..."

Well, I admit that I dont know anything about your claim. But you are sure on this, I suppose, otherwise you would not be rude. Or maybe you would be rude, even without knowing what you claim?

But there are other examples of companies and organizations switching to ZFS. For instance, CERN. Another heavy filesystem user of large data is IBM. I know that the IBM new supercomputer Sequioa will use Lustre ontop ZFS, instead of ext3 because of ext3 short comings:

http://www.youtube.com/watch?v=c5ASf53v4lI (2min30sec)

http://zfsonlinux.org/docs/LUG11_ZFS_on_Linux_for_Lustre.pdf

At 2:50 he says that "fsck" only checks metadata, but never the actual data. But ZFS checks both. And he says that "everything is built around data integrity in ZFS".

If you google a bit, there are many requests from companies migrating from Veritas to ZFS. Here is one company that migrated to ZFS without any problems.

http://my-online-log.com/tech/archives/361

.

.

"...Oooh, [Nexenta] a tier 3 storage maker! Impressive - not!..."

Why is this not impressive? Nexenta competes with NetApp and EMC having similar servers, faster but cheaper. Why do you consider NetApp and EMC "not impressive"?

.

.

"...More evasion. I asked you for one server vendor that has dropped Veritas for ZFS and the answer is NONE..."

What is your point? ZFS is proprietary and Oracle owns it. Do you mean that IBM or HP or some other vendor, must switch from Veritas to ZFS to make you happy? What are you trying to say? I dont know of any vendor, but I have not checked. Have you checked?

.

.

"...You failed AGAIN to answer the point and pretend that naming cheapo, tier 3 storage players is an answer. It's not. Usual fail. Maybe before you do your next (pointless) degree you should do a GCSE in basic English..."

I agree that my English could be better, but as I tried to explain to you, English is not my first language. BTW, how many languages do you speak, and at which level?

Speaking of evading questions, can you answer my question? Have you ever noticed random bit flips in RAM which has triggered ECC error correcting mechanism in RAM? No? So, just because you have never seen it (because you have not checked for it) that means ECC RAM is not necessary? I mean, users of big data, such as Amazon cloud says that there are random bit flips all the time, in RAM, on disks, etc. Everywhere. But you have never seen any, I understand. I understand you dont trust me, when I say that my old VHS cassettes deterioate because of the data begins to rot after a few years. This also happens to disks, of course.

So, I have answered your question on which vendors have seized Oracle proprietary tech: I havent checked. Probably they dont want to get sued by Oracle.

Can you answer my question? Do you understand the need for ECC RAM in servers?

Re: @Matt

"....But here is the most telling point about ZFS - no vendor wants it, even for free. ..."

Well, there are many who wants ZFS. Oracle sells ZFS storage servers, typically they are much faster for a fraction of the price of a NetApp server. Here are some benchmarks when ZFS crushes NetApp:

http://www.theregister.co.uk/2012/04/20/oracle_zfs7420_specsfs2008/

There are many more here:

http://www.unitask.com/oracledaily/2012/04/19/sun-zfs-storage-7420-appliance-delivers-2-node-world-record-specsfs2008-nfs-benchmark-2/

Nexenta is selling ZFS servers, and Nexenta is growing fast, fastest ever. Nexenta is rivaling NetApp and EMC.

http://www.theregister.co.uk/2011/03/04/nexenta_fastest_growing_storage_start/

Dell is selling ZFS servers:

http://www.compellent.com/Products/Hardware/zNAS.aspx

There are more hardware vendors selling ZFS, I dont have time to google up them now for you. Have work to do. FreeBSD has ZFS. Linux has ZFS (zfsonlinux). Mac OS X has ZFS (Z-410).

It seem that your wild false claims have no bearing in reality. Again? It would be nice if you just for once could provide some links that support your claims, but you never do. Why? Are you constantly making things up? How are expected to be taken seriously when you talk of things you dont know, and never support anything you say with credible links? Do you exhibit such behaviour at work too? O_o

Re: @Matt

"..Really? And ZFS has no limitations and never crashes and corrupts data? Not according to the online forums!.."

Of course ZFS is not bullet proof, no storage system is 100% safe. The difference is that ZFS is built up from the ground to combat data corruption, whereas the other solutions does not target data corruption. They have never thought about that. ZFS is not bug free, no complex software is bug free. But ZFS is safer than other systems. CERN did a study and concluded this. And there are other research claiming this too. It is no hoax.

Earlier, disks where small and slow and very rarely you saw data corruption. Disks have gotten larger and faster, but not _safer_. They still exhibit the same error rates. Earlier you rarely read 10^16 bits, today it is easy with large and fast raids. Today you start to see bit rot. The reason you have never seen bit rot, is because you have dabbled with small data. Go up to Petabyte and you will see bit rot all the time. There is a reason CERN did research on this: they are storing large amounts of data, many Petabytes. Bit rot is a real big problem for them.

Have you seen the spec sheets on a modern SAS / Fibre Channel Enterprise disk?

https://origin-www.seagate.com/files/docs/pdf/datasheet/disc/cheetah-15k.7-ds1677.3-1007us.pdf

On page 2, it says:

"Nonrecoverable Read Errors per Bits Read: 1 sector per 10E16"

What does this mean? Does it mean that some errors are uncorrectable? In fact ALL serious disk vendors say the same thing, they have a point about "irrecoverable error". The disk can not repair all errors. Just as NetApp research says: One irrecoverable error on 67TB data read. Read the paper I linked to.

.

"..Your claims about bit rot - which I have NEVER seen in forty years of computing.."

Let me ask you, Matt, how often have you seen ECC errors in RAM? Never? So your conclusion is that ECC RAM is not needed? Well, that conclusion is wrong. Do you agree on this? This is question A. What is your answer on Question A)? Have you ever encountered ECC RAM errors in your servers?

.

"... [you] are the salesman trying to sell a streetcleaner to the average housewife on the mythical chance she might need to clean a street some day. Pointless..."

Well, it is not I who did the research. Large credible institutions and researchers did this, such as CERN, NetAPP, Amazon, etc did it. I just repeat what they say. Amazon explains why have never seen these problems: The reason is because you dabble with small data. When you scale up, at large scale, you see these problems all the time. The more data, the more problems.

Amazon explains this to you:

http://perspectives.mvdirona.com/2012/02/26/ObservationsOnErrorsCorrectionsTrustOfDependentSystems.aspx

"...AT SCALE, error detection and correction at lower levels fails to correct or even detect some problems. Software stacks above introduce errors. Hardware introduces more errors. Firmware introduces errors. Errors creep in everywhere and absolutely nobody and nothing can be trusted.

...Over the years, each time I have had an opportunity to see the impact of adding a new layer of error detection, the result has been the same. It fires fast and it fires frequently. In each of these cases, I predicted we would find issues at scale. But, even starting from that perspective, each time I was amazed at the frequency the error correction code fired...

...

Another example. In this case, a fleet of tens of thousands of servers was instrumented to monitor how frequently the DRAM ECC was correcting. Over the course of several months, the result was somewhere between amazing and frightening. ECC is firing constantly. ...The immediate lesson is you absolutely do need ECC in server application and it is just about crazy to even contemplate running valuable applications without it.

...

This incident reminds us of the importance of never trusting anything from any component in a multi-component system. Checksum every data block and have well-designed, and well-tested failure modes for even unlikely events. Rather than have complex recovery logic for the near infinite number of faults possible, have simple, brute-force recovery paths that you can use broadly and test frequently. Remember that all hardware, all firmware, and all software have faults and introduce errors. Don’t trust anyone or anything. Have test systems that bit flips and corrupts and ensure the production system can operate through these faults – at scale, rare events are amazingly common."

.

Ok? You have small data, but when you go to large data, you will see these kind of problems all the time. You will see that ECC is absolutely necessary. As are ZFS. That is the reason CERN is switching to ZFS now.

CERN did a study on hardware raid, and saw lots of silent corruption. CERN wrote the same bit pattern all the time on 3000 hardware racks and after 5 weeks, they say that the bit pattern differed in some cases:

http://www.zdnet.com/blog/storage/data-corruption-is-worse-than-you-know/191

"...Disk errors. [CERN] wrote a special 2 GB file to more than 3,000 nodes every 2 hours and read it back checking for errors after 5 weeks. They found 500 errors on 100 nodes."

Matt, how about you caught up with latest research, instead of trying to rely on your own experiences? I mean, Windows 7 has never crashed for me, does this mean that Windows is fit for large Stock Exchanges? No. Your experience can not be extra polated to large scale. Just read the experts and researchers, isntead of trying to make up your own reality?

Re: not enough bays

"... ZFS can't cluster and offers SFA resilience as it can't even work properly with hardware RAID..."

Matt, matt. As I tried to explain to you, hardware raid are not safe. I have showed you links on this. And NetApp research says that too, read my post here to see what NetApp says about hardware raid. There are much research on this. Why dont you check up and read what the researchers in comp sci says on this matter, instead of trusting me?

OTOH, researchers say that ZFS protects against all the errors they tried to provoke, and concluded that ZFS is safe. When they tried to provoke and inject artificial errors in NTFS, EXT, XFS, JFS etc - they all failed their error detection. But ZFS succeeded. There are research papers on this too, they are here (papers numbered 13-18):

https://en.wikipedia.org/wiki/ZFS#Data_Integrity

.

And you talk about the cloud. Well, cloud storage typically use hw-raid which, as we have seen, are unsafe. And the internet connection is not safe too, you need to do a MD5 checksum to see that your copy was transfered correctly. You need to do checksum calculations all the time. Just what ZFS does, but hw-raid does not. Therefore you should trust more on your home server with ECC and ZFS, than a cloud. Here is what cloud people says:

http://perspectives.mvdirona.com/2012/02/26/ObservationsOnErrorsCorrectionsTrustOfDependentSystems.aspx

"...Every couple of weeks I get questions along the lines of “should I checksum application files, given that the disk already has error correction?” or “given that TCP/IP has error correction on every communications packet, why do I need to have application level network error detection?” Another frequent question is “non-ECC mother boards are much cheaper -- do we really need ECC on memory?” The answer is always yes. At scale, error detection and correction at lower levels fails to correct or even detect some problems. Software stacks above introduce errors. Hardware introduces more errors. Firmware introduces errors. Errors creep in everywhere and absolutely nobody and nothing can be trusted...."

.

Matt, read and learn?

Re: @Matt

Anonymous Coward:

>"Why use Windows? It is not safe and susceptible to data corruption"

>What a load of FUD.... dont forget to wrap some foil around your hard drives

You are right on requesting links, otherwise it would be pure FUD: make lots of strange negative claims without ever backing up with credible links. Here you have a PhD thesis where the research conclude that NTFS is not safe, with respect to data corruption. I suggest you catch up with the latest research if you want to learn more:

http://pages.cs.wisc.edu/~vijayan/vijayan-thesis.pdf

http://www.zdnet.com/blog/storage/how-microsoft-puts-your-data-at-risk/169

Dr. Prabhakaran found that ALL the file systems (NTFS, ext, JFS, XFS, ReiserFS, etc) shared:

"... ad hoc failure handling and a great deal of illogical inconsistency in failure policy ... such inconsistency leads to substantially different detection and recovery strategies under similar fault scenarios, resulting in unpredictable and often undesirable fault-handling strategies. ... We observe little tolerance to transient failures; .... none of the file systems can recover from partial disk failures, due to a lack of in-disk redundancy."

.

.

.

Matt Bryant:

>"...I can get built-in RAID on most PC mobos, it is reliable and cost-effective, does not impact on CPU >performance, why bother with the hassle of ZFS which steals cycles from the CPU?..."

First of all, hardware raid are not safe with respect to data corruption. Here are some information if you want to learn about limitations of hardware raid:

https://en.wikipedia.org/wiki/RAID#Problems_with_RAID

Second, it is true that ZFS uses cpu cycles, a few percent of one core. There is a reason ZFS uses cpu cycles: ZFS does checksum calculations of every block. If you ever have done a MD5 checksum of a file to check data integrity, you know it uses cpu cycles. ZFS does that (SHA256 checksum actually). Hardware raid does not do any checksum calculations for data integrity, instead, hw-raid does PARITY calculations which are not the same thing. Parity calculations are just some XOR easy calculations and hw-raid are not designed to catch bit rot.

Have you ever experienced bit rot of old 5.25" or 3.5" data discs? Old disks doesnt work anymore. This problem also applies to ECC RAM, with time, a powered on server will have more and more random bit flips in RAM, to the point it crashes. That is the reason ECC RAM is needed. Do you dispute the need for ECC RAM? Do you think servers dont need ECC?

.

>"...I run fsck via cron which is all scrub is, and so far I've not found any hobbyhorse sh*t on my drives..."

Matt, matt. ZFS scrub is not a fsck. First of all, fsck does only check the metadata, such as the log. fsck never checks the actual data, which means the data might still be corrupted after a successful fsck. One guy did fsck on a XFS raid in like one minute, think a while and you will understand it is fishy. How can you check 6 TB worth of data in one minute? That means the fsck read the data at a rate of 100 GB/sec. This is not possible with just a few SATA disks. The only conclusion is that fsck does not check everything, it just cheats. Second, you need to take the raid off line and wait while you do fsck.

ZFS Scrub checks everything, data and metadata, and that takes hours. ZFS scrub is also designed to be used on a live mounted active raid. No need to take it off line.

The thing is, to be really sure you dont have silent corruption, you need to do a checksum calculation every time you read/write a block. In effect, you need to do a MD5 checksum. Otherwise, you can not know. For instance, here is a research paper by NetApp whom you trust?

https://en.wikipedia.org/wiki/ZFS#cite_note-21

"A real life study of 1.5 million HDDs in the NetApp database found that on average 1 in 90 SATA drives will have silent corruption which is not caught by hardware RAID verification process; for a RAID-5 system that works out to one undetected error for every 67 TB of data read"

If you look at the spec sheet of a new Enterprise SAS disk, it says one irrecoverable error on every 10^16 bit read. Thus, SAS disks get uncorrectable errors. And Fibre Channel disks are even more high end, and they also get uncorrectable errors:

http://origin-www.seagate.com/www/en-us/staticfiles/support/disc/manuals/enterprise/cheetah/10K.7/FC/100260916d.pdf

Matt, again you have very strong opinions on things you have no clue about. It would be good for you if you caught up on research, otherwise you just seem totally lost when people discuss things over your head. And as usual, you never backup any of your strong negative claims, even though we have asked you to do so. Try to handle all that bitterness inside you? It is difficult to try to explain things to you, as you discard even research papers, and you continue to regurgitate things you have no clue of.

.

.

BTW, ZFS is free in a gratis and easy distro called FreeNAS. Just set up and forget. It is built for home server. Nas4Free it is called, maybe...?

Re: I don't get NAS boxes...

"...Why not build a Win 7 / Win 8 PC with shared libraries,..."

Why use Windows? It is not safe and susceptible to data corruption. Ever hard disk gets lots of read/write errors during normal usage, but gets corrected on the fly with error correcting codes on the disk. However, some of these errors are not correctable by the codes. Even worse, some of these errors are not even DETECTABLE by the codes. The codes are not fool proof, you know. They might be able to correct 1 bit errors, and detect two bit errors, but sometimes three bit errors happen. Very rare, but they happen. And those three bit errors are not correctable. Sometimes four and even five bit errors happen, and such errors might not even be detectable. This is called Bit Rot, google on it. Old VHS tapes doesnt work today, the data has begun to rot.

It is exactly the same problem in RAM. Why do you think servers need ECC RAM? ECC RAM can correct 1 bit errors, and detect 2 bit errors. Microsoft concluded (after collecting information about Windows crashes) that 30% of all Windows crashes was caused by random bit flips in RAM, something that ECC RAM would have protected against. Cosmic radiation is a big source of random bit flips, flaky power, sun bursts, etc. There are much research on data corruption.

You need a solution that always calculates checksum data of every read block on the disk, in effect doing a MD5 checksum on every read. Or SHA1, or any other checksum. This is the only way to protect against bit rot on disks. Incidentally, ZFS is designed to protect against bit rot, and does exactly that: for every block you read, it calculates a SHA256 checksum. And if the checksum is not correct, it automatically repairs the block from the raid. And, ZFS is free, as in gratis. If you try ZFS, you must not use hardware raid, because they mess up the checksum calculation. Sell it, and use free ZFS. Here is much research on data corruption on disks. And of course, if you are serious with your data, you should use ECC RAM too.

NTFS, ext, HFS, XFS, JFS, etc is not safe, and might corrupt your data (research paper) here. And ZFS is safe, according to researchers.

http://en.wikipedia.org/wiki/ZFS#Data_Integrity

Re: Take no bets

Intel x86? And POWER? Well, both of them can not show 100% performance increase every other year. Larry Ellison is a hard CEO: "just double it", no matter how technically difficult it will be to increase performance that much.

For instance, the newest Haswell had the graphics and power consumption as main targets, the cpu performance is not a priority. Haswell will only be 10-20% faster than Ivy Bridge, which is not much compared to 100% every other year. The POWER7+ is only 20% faster than POWER7, despite double cpus.

.

.

"It wouldn't be surprising to see KSplice hot splicing come to Solaris, too."

Actually, KSplice is coming to Solaris. But Solaris had a similar technique decades ago, way back in Solaris 8, where you could hot patch the kernel. Regarding DTrace in Linux, the inventor of DTrace, Bryan Cantrill says that DTrace in Linux is not a good port. Yet. Totally useless as of today.

Re: IBM do it too...

@Jesper Frimann

"...I was replying to Kebbart's link:

https://blogs.oracle.com/si/entry/zfssa_smashes_ibm_xiv_while..."

It was never clear that Oracle compared vs an POWER5 system. It is no merit to be faster than an old generation system. I will never post that benchmark again, because it is unfair.

Thanx for informing me.

Re: XIV ?

"...System z isn't very bad in terms of CPU. True, it is not a supercomputer or a Power 795..."

Well, the Z12 is a very slow cpu. No doubt about it. Where are all the IBM benchmarks? Nowhere. Why? For a reason. Have you ever wondered why IBM never have released benchmarks of Mainframe cpus? There are none. Zipp. Zero. Zilch. Nada. Why? You tell me.

On the other hand, we have loads of POWER7 cpu benchmarks everywhere of all different kinds. Well, the POWER7 happens to be a really good cpu, so we understand when IBM wants to tell the world how fast the POWER7 is. But regarding the Mainframe cpu? Well, it is "the worlds fastest cpu", but no evidence nor proof of that. Just some marketing material:

http://www-03.ibm.com/press/us/en/pressrelease/32414.wss

At least IBM could have offered ONE benchmark vs the POWER7? But no. The Mainframe cpus all get obliterated by the POWER7.

Some would call extravagant claims without any proofs to be FUD. Which coincidentally, happens to be IBM's master dance:

http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt#Definition

"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."

Re: IBM do it too...

Another one. IBM XIV vs Oracle T4 ERP. "Without any optimizations Oracle was 2.5x faster".

https://blogs.oracle.com/si/entry/zfssa_smashes_ibm_xiv_while

Re: IBM do it too...

Here is a Oracle ZFS benchmarks vs NetApp:

http://www.theregister.co.uk/2012/04/20/oracle_zfs7420_specsfs2008/

Here are some more

https://blogs.oracle.com/si/entry/7420_spec_sfs_torches_netapp

Re: XIV ?

Regarding cpu performance on the IBM system Z, they are very bad. Any decent high end x86 cpu is roughly twice as fast. So cpu performance wise, the new Z12 is very bad.

POWER7 on the other hand is a very good cpu and it is much much much faster than the IBM z12 or Z196 cpu. So I would not call the System Z, the high end. An IBM P795 packs much more cpu punch than a dinosaur z12 or z196.

Re: Comparable systems

It is not obvious that more RAM helps a certain benchmark. In this case, is the current benchmark RAM starved? If it is, then Oracle should not publish such benchmarks where the RAM differs. But if the RAM amount does not matter, above a certain threshold, then the RAM amount does not matter.

I remember a SAP benchmark where the Sun x86 machine had 256GB RAM but slow RAM, and the Linux x86 server had 128 GB RAM, but faster RAM - and still the Solaris server was slightly faster. It turned out that the Linux HP server used 128GB RAM, because the faster RAM sticks came in smaller size. So HP could choose to equip their Linux server with 256GB RAM or 128 GB RAM, and HP chose the faster RAM sticks. In this SAP benchmark, it did not matter if you had 128GB or 256GB - because had it mattered, then HP would have gone with 256GB RAM.

Thus, it is not obvious that this benchmark would have been helped with more RAM.

.

.

But I agree that this benchmark seems a bit fishy from Oracle. It needs to be investigated a bit further. For instance, is RAM crucial? Is it better to have 2TB RAM, or does it not matter? If it does not matter, then it doesnt matter and the criticism is only IBM fanboyism.

On the other hand, when IBM does fishy benchmarks, then the author Timothy Prickett does not write an article about it. Clearly IBM biased.

AIX dead

"...You know that article is from 2003, right?..."

Yes, so what? IBM talks about "multi decade time frame" before AIX is killed off. This is the first decade, and already we see signs of AIX decreasing in importance.

POWER cpus are not really that fast anymore. POWER7+ is a hodge podge, nothing new or innovative there. The Intel Westmere-EX is 14% slower than POWER7 on some workloads, but is far cheaper

http://www.anandtech.com/print/4285

The Sandybridge is 10-15% faster than Westmere. And IvyBridge is faster than Sandybridge. Very soon we will see Haswell which will be even faster. Intel x86 is rivaling POWER7 today. Very soon x86 will be faster than POWER cpus. x86 is improving much more than POWER cpus.

POWER6 costed 5-10x more than x86 and was several times faster than x86.

POWER7 costs 3x more than x86 and is 14% faster on some workloads.

POWER8... will cost 1-2x more than x86 and be as fast as x86?

POWER7+ is late and we have never heard about POWER8 yet. It is evident that POWER development is slowing down. POWER is superior any longer. IBM is only doing high margin business. Soon POWER will be cheap as x86, and then IBM will kill POWER.

AIX runs on POWER. If POWER is dead, what will AIX run on? Coincidentally, IBM has said that AIX will be killed off. That will happen sometime when x86 is matching POWER, at a cheaper price. It has taken some 10 years for x86 to catch up POWER. In another 10 years, x86 will be superior.

POWER dead => AIX dies.

Better learn Linux, boys. AIX is not innovative and hasnt been in a long time.

Re: RISC Chips

"...Must be from all that paid-for blogging [Kebabbert] used to do for Sun...."

How about you check things up sometimes, instead of just writing whatever comes to your mind? I used to have a blog, yes, it was about food and health. There was nothing IT related on my blog. Why would Sun pay me to blog about food? Maybe you will find my old blog here if look a bit. I googled on "kebabbert blogg" and couldnt find anything today, but one year earlier I could find my health blog. Maybe if you look around a bit you will find it. Have fun reading about my health and food writings. I did have a splendid Texas Chili recipe that many people liked.

http://archive.org/web/web.php

Do you have more fantasies about me that you want to add?

.

.

"...where you scream and shriek rabidly that Niagara doesn't need more cache, and yet every generation since has had more cache added..."

I never said that. I suggest you read again. I said something like: "The Niagara T2 is not dependent on having a large cache, to be 10x faster or so, than the competition on some workloads". That is what I said. I never said that T2 does not need a cache, nor doesn't need more cache. More cache is always good, but T2 does not need it to break IBM or HP.

The Niagara T2 had maybe 1-2 MB cache in total and still it was like 10x faster than IBM and HP cpus which had far larger caches. How do you explain that a "cache starved" cpu can be 10x faster than cpus with huge caches? Something does not add in your claims, if you think logically. I have asked you this many times, but you have never answered. Can you answer me now? If I say "please"? How can a "cache starved" cpu be 10x faster than the competition? Maybe 1-2MB cache suffices for T2 because of its radical novel design?

Re: RISC Chips

Anonymous,

"...As nice as these new SPARCs are, when compared to IBM's new offering, they just don't seem to be in the same league..."

Can you elaborate on this? IBM has no offering that matches these T5 cpus. In what way are POWER7 "better"? They are taking longer time to market? Is that better?

In fact, IBM is planning to kill AIX, did you know that? AIX will be deprecated, according to IBM executives. Didnt you know?

http://news.cnet.com/2100-1001-982512.html

"...The day is approaching when Linux will likely replace IBM's version of Unix, the IBM's top software executive said..."

.

"...How much better are these really than x86_64 chips in a real world situation, and is it worth the extra dosh?..."

Did you know that Oracle is projecting 2x the performance every other year? How much is x86 Intel projecting? 10% better performance every other year? How much is IBM projecting? Did you know that the previous generation SPARC T4 are more than 2x faster than POWER7 on some workloads, and T4 hold several world records. Did you know?

Re: Right problem, right application, right system, right CPU

"... but still look to have too little cache..."

If the CMT Niagara cpus have too little cache, how do you explain their superior performance to IBM cpus with huge caches? You do know that Niagara cpus holds several world records? That T4 is more than 2x faster than POWER7 on some workloads?

I prefer a Niagara CMT cpu with "too small cache" that utterly crushes the competition, to a cpu with huge cache that is left behind.

Re: RISC Chips

"...Any Sunshiners out there still trying to pretend that single-threaded performance and cache don't matter?..."

Sun/Oracle have always been very clear with the Niagara T1,T2,T3 that they are best suited for heavily light threaded work. Sun/Oracle have never said they are general purpose cpus. The T[1-3] cpus are much much faster than ordinary cpus for heavily light threaded work, and in that area they do reach (in optimal case) >50 GHz of aggregate work, just as claimed (see below*).

That is the reason there are two SPARC families, one for light threaded work (Niagara, CMT) and one for single threaded work (UltraSPARC from Fujitsu).

Thus, can you finally stop saying that Sun/Oracle claims the Niagara CMT cpus are good for single threaded work? They have never said that. I have explained this to you, umpteen times. Why do you continue to say this? And why do you continue to claim the cache is too small, when the Niagara T2 cpus are 10x faster than IBM offerings on appropriate work loads? IBM cpus have huge caches and are still crushed by Niagara. So how can Niagara suffer from a small cache?

Can you present any evidence for your false claims? Any links? As usual: No. Why do you like to FUD a lot?

.

(*)

For instance, in SIEBEL v8 one Sun T5440 matches six POWER6 servers (including P570). These POWER6 servers had in total something like 60-70GHz of aggregate speed. Which one T5440 totaling 7GHz of aggregate work matched. Hence, the Niagara cpus did reach much higher GHz, just as claimed. Just look at the benchmarks.

Or, for instance, one T2 cpu matched thirteen (13) IBM CELL cpus running at 3.2GHz, in String Pattern Matching. How do you explain this? One 1.6GHz cpu matches 40GHz of IBM CELL aggregate power?

Again we see that one single 1.6GHz Niagara reached >50 GHz worth of IBM GHz. How is this possible with a "too small cache" as you claim below? How can the Niagara be cache starved when it utterly crushes IBM cpus? It is 10x or more faster. Not 10%, but 10x.

Re: Be careful with comments

@Jesper Frimann,

"...and people like Kebabbart will twist and turn any results ..."

When have I twisted and turned any results? Can you post any links?

You on the other hand, have certainly twisted and turned results. I remember our debate on the Niagara T2+ cpu, and I showed a benchmark where Niagara had greater throughput than IBM POWER6 upon which you replied something like "throughput does not matter, POWER6 has lower latency". Later I showed another benchmark where Niagara T2 had lower latency, upon which you replied something like "latency does not matter, POWER6 has greater throughput". No matter which benchmarks I show, you always find something to nag - sometimes even contradicting yourself.

And you say that the benchmarks and white papers I show, are "twisting and turning facts"? Great. People have even complained that I always copy links to benchmarks, white papers, etc.