Buying for tomorrow: Cryptography and SPARC/CMT

Buying for tomorrow: Cryptography and SPARC/CMT

Summary: When in doubt, bet on the future coming sooner rather than later - because it's better to be ahead of the eight ball, than under it.

TOPICS: Oracle, Hardware

Earlier this week I got a note from someone I don't know asking for advice about buying Sun gear for a company I know nothing about - not exactly a broad informational basis for advice making, if you know what I mean.

The one thing I was able to point out to him, and that I now want to spread a bit more widely, is the perception that cryptology is becoming significantly more important -and that Oracle's Sun CMT gear has some serious advantages over its competition, including the more traditional SPARC and Power gear, in this area.

Sun blogger Joerg Moellenkamp offers a clear summary on how Intel's approach to hardware cryptographic support differs from Sun's:


The AES-NI stuff is an extension to the x86 instruction set, that implements some of the important steps in hardware needed by AES ... and it just accelerates AES. Those instructions are an extension to the instructions not unlike SSE for example. So they are part of the normal flow of instructions in the pipeline. It's not a cryptographic coprocessor, it's the usual approach in x86 to extend the instruction set as needed and to use the normal cores for this tasks. It doesn't accelerate hashing and it doesn't accelerate public key cryptography. It's really just for the symmetric ciphers in the AES realm.


The T3 implements cryptography in the form of cryptographic coprocessors. Each core provides one coprocessor. So a T3 has 16 cryptographic units. This accelerator is controlled by control words written into memory, it takes data from memory and writes it to another location - encrypted or decrypted depending on the direction you took. From the main processors perspective controlling the crypto unit is nothing more than some store instructions. From that point the crypto accelerators work in parallel at the clock speed of the processor. The core can work on something else while the crypto coprocessor is doing its work. That's why marketing has called this zero-cost cryptography - not only because the crypto accelerators are part of the CPU, but because they are integrated in a lightweight way working without using resources of the residual core.

In a footnote he provides, furthermore, a a particularly valuable reference and link to a 2009 Hotchips presentation on the "rainbow falls" cryptology co-processors done by Lawrence Spracklen that's well worth reading - and, if you want to see how Spracklen's predictions worked out in the hardware the Sun performance reporting blog compares cryptology throughput between the T2+ and T3 lines.

Unfortunately what that particular report illustrates rather better than the effects of the hardware change, is the lag between hardware change and matching software/skills change - and this is something you have to watch out for too. Hardware isn't magic: hardware can enable, but without the skills and software needed, your expensive new tools won't be magical, they'll just be expensive.

Oddly, there's another very recent report on the performance blog where this is a bit clearer: one trumpeting the joys of using SPARC to replace Lintel. Here's their summary:

One of Oracle's SPARC T3-2 servers was able to consolidate the database workloads off of thirty older x86 servers in a secure virtualized environment.

Thus their goal seems to have been to show people looking at racks of two and three year old servers that alternatives exist to just ordering replacement PCs - unfortunately they had to run the lintels at 10% utilization to get the result they wanted and that makes the story rather less than compelling for people who can divide 30 by 10.

I think the reason this happened to them, and thus the reason they couldn't max out those 30 lintels on I/O to make the case for real, was that they wanted to show a 1:1 mapping from lintel servers to Solaris containers - and because that falls afoul of the rule that the stronger you make the virtualization boundaries the less efficient the machine gets, they initially maxed out at somewhere around 5% utilization and then doubled that by using limited processor pools to cheat a little bit.

In effect they crippled their own demonstration by assuming that the customer would rather do something stupid than change - and, really, that's what Intel is doing with their 7 AES instructions too: assuming that customer intellectual inertia will force sales despite the disadvantages of doing things the 80s way.

But as we move into a world in which storage cryptology becomes an audit checkmark and https becomes "de rigueur" for just about everything web, more and more larger IT customers are going to have internal voices whispering about the advantages of ZFS, on board cryptology co-processors, and the use of Solaris to avoid PC style virtualization.

Basically, the cost of refusing to adopt better technologies is about to go up again - so my bottom line advice to the guy I don't know from the company I don't know was simple: bet on the world getting smarter, and consider the role cryptology seems likely to play in your life before today's new boxes hit retirement age.

Topics: Oracle, Hardware

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Rudy the price must be right

    Larry is keeping SPARC and the ecosystem around it expensive. That will help make it less popular and niche.

    On chip cryptography has never been a strong point in x86 but there are little gems that have been around for a while like VIA's Padlock technology which is affordable but not popular.

    Future meshing of GPU/CPU technology by Intel/AMD will enable much more capability for a good price and as long as SPARC remains bad value for money it will continue to loose ground. GPU's are increasingly being used for successful password cracking but are also capable of performing very strong encryption very quickly and cheaply. This advantage that SPARC chips may now have will be made irrelevant and if you now buy SPARC you are pretty much limited to using just Solaris and will be screwed over by Larry.

    SPARC is a foolish long term buy. Why?
    It's 2010 it's Intel/AMD it's ARM it's GPU and it's cheap.
    If Sun had made more of an effort to aggressively port Linux (Red Hat) to SPARC and build an community around that that than that would give more choice but SPARC advantages stay stuck on Solaris which Linux is eclipsing.

    Argue all you want but the rise of Intel and Linux in the Server space and the decline of Solaris and SPARC cannot be disputed.
    • RE: Buying for tomorrow: Cryptography and SPARC/CMT

      <strong> /</strong>

      <h1><strong><a href="">Free Puzzle Games</a></strong></h1>
      <h1><strong><a href="">House Design</a></strong></h1>
  • RE: Buying for tomorrow: Cryptography and SPARC/CMT

    Have you considered what you will write about when Sun fails? I think even you have to admit the writing is on the wall Rudy. I preferred Betamax to VHS, but they're both dead now.

    There will come a time in the near future when Sun and SPARC will only exist in Wikipedia. It may be time for you to start improving your skill set. Time to try OOP, forget the trees and see the forest and realise that in the end it's modern applications that matter and they are built on the OS you love to hate.

    Are you capable of adapting Rudy or is the museum going to close soon? If you can't bear to touch MS, Unix is still around and the column is actually called managing L'unix, so hopefully we could see more articles on the OS and less of your favourite hardware manufacturer that got bought out.
    • RE: Buying for tomorrow: Cryptography and SPARC/CMT

      @tonymcs@... These days Rudy likes to use this blog as a platform for his redneck, inbred take on politics and reality.
    • Here's my perspective


      Even though Sun has lost sales for years, it does seem to be coming around. The last 2 companies I worked/work for are using Sun and have plans to increase that use. I see IBM making big inroads with their AIX Power servers also. What I DON'T see is HP - anywhere. They have dropped off the (UNIX) radar faster than the Itanic sank. I think they proved that minimal/elegant hardware relying on complicated software is a non-starter.
      So as Larry increases the maintenance cost of Sun servers to 12%/month of the purchase price (pay DOUBLE for SPARC in less than 1 year!) - it looks like people are reacting like this is a bargain Rolex instead of an overpriced Timex.
      Roger Ramjet
      • Not the numbers I'm seeing

        @Roger Ramjet <br><br>People I know who have support contracts on new CMT gear aren't paying 12% per month - not even half that. <br><br>So I have two questions:<br><br>1 - what are you getting for that 12%? and,<br><br>2 - how many others are being asked to pay that kind of rate?<br><br>Could anyone with info on this please get in touch? murph at will get to me..
      • 12% is per year

        @Roger Ramjet

        The official standard for Oracle's 24 x 7 Gold support is 12% per year of the discounted price - if the contract is initiated with the hw/sw purchase.

        Costs go up if you want platinum (2 hr on site) support, if you go with the warranty for the first year and then add support, if you don't want to accept Oracle's terms on things like the number of authorized claimants etc, or if you want to put the gear somewhere oracle doesn't have a support operation.

        Note too that CMT core multipliers are officially set at 0.25so whether total licensing cost for an rdbms/tools/application(s) set are higher or lower than what you'd pay or the same number of users on AIX/Power or Lintel depends on the specifics of your environment - the better it fits the cmt model, the better the price comparison looks.