Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
posted by requerdanos on Sunday September 05 2021, @11:05PM   Printer-friendly
from the virtually-indestructible dept.

A brief overview of IBM's new 7 nm Telum mainframe CPU:

From the perspective of a traditional x86 computing enthusiast—or professional—mainframes are strange, archaic beasts. They're physically enormous, power-hungry, and expensive by comparison to more traditional data-center gear, generally offering less compute per rack at a higher cost.

This raises the question, "Why keep using mainframes, then?" Once you hand-wave the cynical answers that boil down to "because that's how we've always done it," the practical answers largely come down to reliability and consistency. As AnandTech's Ian Cutress points out in a speculative piece focused on the Telum's redesigned cache, "downtime of these [IBM Z] systems is measured in milliseconds per year." (If true, that's at least seven nines.)

IBM's own announcement of the Telum hints at just how different mainframe and commodity computing's priorities are. It casually describes Telum's memory interface as "capable of tolerating complete channel or DIMM failures, and designed to transparently recover data without impact to response time."

When you pull a DIMM from a live, running x86 server, that server does not "transparently recover data"—it simply crashes.

Telum is designed to be something of a one-chip-to-rule-them-all for mainframes, replacing a much more heterogeneous setup in earlier IBM mainframes.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 1, Interesting) by Anonymous Coward on Sunday September 05 2021, @11:39PM (13 children)

    by Anonymous Coward on Sunday September 05 2021, @11:39PM (#1174830)

    Yes, of course.

    I wonder how this compares to running a room full of servers on a network when the apps can move to a working server?

    Is the model of the computer presented to the app different?

    Maybe with a mainframe, the computer it runs on is near perfect and with the network the odds might be better, but the app has to do some considerations to make it so?

    • (Score: 5, Informative) by Anonymous Coward on Monday September 06 2021, @12:38AM (5 children)

      by Anonymous Coward on Monday September 06 2021, @12:38AM (#1174846)

      The room full of servers is trying, badly, to reinvent the mainframe.

      Typical mainframe challenge: I have a huge, non-stop stream of transactions. I can absolutely not miss one, quite likely because of nasty legal ramifications if I do. I can't just put them off indefinitely and batch them (even if that were feasible) because I have to be able to offer real-time responses with ACID compliance and uptime guarantees. BASE is not an adequate answer, moving apps is not an adequate answer, internal network latencies are not acceptable and so on.

      If you want to run a forum for exchanging cat pictures on the internet, go right ahead with your room full of pleasure. If you want to run an interbank forex system - yeah, it's a safe bet there's a mainframe behind it. Or several.

      • (Score: 2, Insightful) by Anonymous Coward on Monday September 06 2021, @06:14AM (4 children)

        by Anonymous Coward on Monday September 06 2021, @06:14AM (#1174889)

        It's a safe bet there's a mainframe behind it, yes. They bought it in 1978 and it's still there, costing a million dollars a year just for the service contract, and everyone involved desperately wishing they had something else. With the possible exception of the people who it provides job security to.

        • (Score: 0) by Anonymous Coward on Monday September 06 2021, @06:30AM (3 children)

          by Anonymous Coward on Monday September 06 2021, @06:30AM (#1174891)

          What will they do when all the COBOL programmers die off?

          • (Score: 0) by Anonymous Coward on Tuesday September 07 2021, @03:45AM (2 children)

            by Anonymous Coward on Tuesday September 07 2021, @03:45AM (#1175206)

            Dumb question.

            Easy answer, the going rate of pay for Cobol programmers will rise until the demand is met. Who knows, you may even choose to learn Cobol when the big bucks are dangled in front of you?

            • (Score: 0) by Anonymous Coward on Tuesday September 07 2021, @03:52AM (1 child)

              by Anonymous Coward on Tuesday September 07 2021, @03:52AM (#1175210)

              But how will you get that 20 years experience they're looking for? Think ahead kiddo, learn COBOL.

              • (Score: 2) by maxwell demon on Tuesday September 07 2021, @07:19AM

                by maxwell demon (1608) on Tuesday September 07 2021, @07:19AM (#1175245) Journal

                Well, if you have lived for at least 20 years, you've got 20 years of experience (because you were experiencing something every day). So as soon as you learn to program in COBOL, you're a COBOL programmer with 20 years of experience! ;-)

                --
                The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 1, Informative) by Anonymous Coward on Monday September 06 2021, @08:30AM (5 children)

      by Anonymous Coward on Monday September 06 2021, @08:30AM (#1174900)

      You don't really runs apps on Mainframes in some traditional server comparison or sense. See them as a specialized computer built for a single purpose -- processing transactions. It is what it's built to do and it does it well. All the hardware infrastructure around it is just there to serve that purpose with redundancy. "restarting" to fix problems isn't really an option or the solution.

      • (Score: 0) by Anonymous Coward on Monday September 06 2021, @01:24PM (4 children)

        by Anonymous Coward on Monday September 06 2021, @01:24PM (#1174933)

        "See them as a specialized computer built for a single purpose -- processing transactions. "

        OK, so that morphs the question to given that a mainframe is a really good way to reliably do transactions, could a distributed system do it even better if one were able to start with a fresh sheet of paper?

        Seems to me that some things in ACID must be done in a localized manner. (Like making sure commits appear to proceed on a single, consistent time line.) Perhaps a distributed system with a few special purpose hardware blocks for these critical functions might be even more scalable and reliable than the mainframe path?

        No doubt, getting the ability to use a fresh sheet of paper is a big problem. There is a lot of business knowledge in the code for any large business. But if one were a better way...

        • (Score: 4, Informative) by looorg on Monday September 06 2021, @02:23PM

          by looorg (578) on Monday September 06 2021, @02:23PM (#1174960)

          Sure. I'm sure it could be possible to reinvent the Mainframe. But in essence then you are trying to reinvent the wheel again. Not to mention that IBM and a few others are more or less constantly reinventing or evolving the Mainframe already. So I'm not quite sure why you would want to do that. It's not like the Mainframe today is just some relic that hasn't changed in the last 50-60 years. Those old machines still run today in a VM in a new Mainframe, chugging along like it was still the 1960's. Except faster, safer and better.

          Also it's not going to be cheap as the cost of reinventing the Mainframe would probably be enormous and make paying IBM (or whomever you pay) just look cheap in comparison. The potential win would be very, very far into the future if it would ever materialize. There might not even be a market for it. Trust has a price-tag to.

          Also Mainframes already does all those things you suggest or are looking for. System and workload sharing, balancing and distribution, transaction auditing and scheduling. Running so many virtual machines.

          It's not like all Mainframes live in the same room next to each other. They can be spread out and connected just like other machines. You can rent processing capacity when needed from other machines, or the ever hated unlocking capacity in a machine(s) you already have.

          It runs Linux to if you want to, not sure why you would want to run it instead of z\os but it's an option. Mostly I think you have them running in virtual machines doing something that that Linux is good at but still being a slave under the Mainframe. Some kind of front-end things where there is interaction that then gets feed into the transaction processing machine.

          I find it hard to believe it would become more reliable, or much more reliable or more reliable to be worth it. To make Mainframes even more reliable or something more reliable then a Mainframe would be one of those things where the cost probably just increases exponentially to achieve like an extra nine or whatever you want to measure your uptime in. It's not like you are somehow going to completely remove an eventual restart on downtime. You might be able to push it some more but eventually somethings will need a restart.

          So I'm not sure why you would really want to reinvent something that works and works well for it's purpose. Unless it's just to show that it's possible. But I'm not sure someone would sink to much money into that project.

          I don't think there is a large market for some kind of FOSS Mainframe. The market is already somewhat locked down so to speak. The once that need it are already there and I am not sure they would trust someone else or something new. It would fall on you to show that you are somehow 100% compatible and they would just not be willing to risk you being wrong.

        • (Score: 0) by Anonymous Coward on Monday September 06 2021, @03:17PM (2 children)

          by Anonymous Coward on Monday September 06 2021, @03:17PM (#1174973)

          On a conceptual level, this is entirely possible.

          Consider ... oh, let's call it a stack of Raspberry Pi, all plugged together with ethernet. Set it up so that multiples can gang together and literally duplicate each other's workload (thus offering redundancy with failure tolerance, analogous to the old Tandem systems). Have everything done with asynchronous message-passing so that any one failure doesn't cascade to locking up other units. Have them all able to do specialised jobs such as storage, transaction handling, UI, blahblahblah...

          You could even make it out of COTS units that one could plug together ad hoc to resize or repurpose your installation. You could have multiple parallel back ends that are all hotpluggable, so that losing your ethernet switch wouldn't kill it all ... and so on.

          And in the end it wouldn't cost that much. The real expense would be in getting the software done, tested and verified.

          • (Score: 0) by Anonymous Coward on Monday September 06 2021, @04:24PM (1 child)

            by Anonymous Coward on Monday September 06 2021, @04:24PM (#1175017)

            "Watch me pull a rabbit out of my ass"
            "But Raspfairy Pye Shit Never Works"
            "This time FOR SURE"

            PRESTO!!!

            • (Score: 0) by Anonymous Coward on Tuesday September 07 2021, @03:58AM

              by Anonymous Coward on Tuesday September 07 2021, @03:58AM (#1175212)

              That's not a rabbit!

    • (Score: 1, Interesting) by Anonymous Coward on Monday September 06 2021, @05:22PM

      by Anonymous Coward on Monday September 06 2021, @05:22PM (#1175039)

      I wonder how this compares to running a room full of servers on a network when the apps can move to a working server?

      Is the model of the computer presented to the app different?

      Don't forget the part where the mainframe is still running the same apps with no problem (and maybe fewer and fewer bugs) until 2030 and or even past 2040. In this world uptimes of many decades aren't that rare. The competition in this arena is stuff like this: https://en.wikipedia.org/wiki/NonStop_(server_computers) [wikipedia.org]

      Meanwhile in the more hipster world you've been forced to rewrite your app and migrate to a different framework/platform twice because various vendors have stopped supporting those frameworks/platforms in favor of newer "better and cooler stuff". And thus you have more bugs again, maybe even service outages. Add that to your downtime calculations.

  • (Score: 1, Troll) by Subsentient on Monday September 06 2021, @12:04AM (2 children)

    by Subsentient (1111) on Monday September 06 2021, @12:04AM (#1174837) Homepage Journal

    Are they PGA or LGA, or BGA?
    This is very relevant to determine how many of the chips I can fit inside my ass. Naturally, I prefer PGA.

    --
    "It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
    • (Score: 0) by Anonymous Coward on Monday September 06 2021, @01:28AM (1 child)

      by Anonymous Coward on Monday September 06 2021, @01:28AM (#1174857)

      Smuggling them out of the country, or do you just prefer to get fucked by IBM?

      • (Score: 2) by Subsentient on Monday September 06 2021, @02:03AM

        by Subsentient (1111) on Monday September 06 2021, @02:03AM (#1174862) Homepage Journal

        Wait, you don't use microprocessors for... never mind...

        --
        "It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
  • (Score: 0, Disagree) by Anonymous Coward on Monday September 06 2021, @12:44AM (2 children)

    by Anonymous Coward on Monday September 06 2021, @12:44AM (#1174849)

    Once you hand-wave the cynical answers that boil down to "because that's how we've always done it"

    That is literally the only reason. "Reliability" is the rationalization.

    There is a reason that nobody who went into business after 1995 has mainframes.

    • (Score: 0) by Anonymous Coward on Monday September 06 2021, @01:15AM

      by Anonymous Coward on Monday September 06 2021, @01:15AM (#1174855)

      They are idiots

      MS has main frames running their business / back office.
      Oracle runs there too with software releases for them. SAP again.

      Intel and like are scientific computers. Non are designed for accounting functions. IBM …business… designs for businesses Ed’s processing. With real numbers (currency). Not the 1.04e10 crap

    • (Score: 2) by Runaway1956 on Monday September 06 2021, @03:31PM

      by Runaway1956 (2926) Subscriber Badge on Monday September 06 2021, @03:31PM (#1174982) Journal

      There is a reason that nobody who went into business after 1995 has mainframes.

      And, cost has nothing to do with it, right? A small business or startup business can fill a server room with Opterons for far less money than they can buy a mainframe.

  • (Score: 4, Informative) by takyon on Monday September 06 2021, @01:02AM

    by takyon (881) <takyonNO@SPAMsoylentnews.org> on Monday September 06 2021, @01:02AM (#1174854) Journal

    Did IBM Just Preview The Future of Caches? [anandtech.com]


    On a single chip, we have eight cores. Each core has 32 MB of private L2 cache, which has a 19-cycle access latency. This is a long latency for an L2 cache, but it’s also 64x bigger than Zen 3's L2 cache, which is a 12-cycle latency.

    Looking at the chip design, all that space in the middle is L2 cache. There is no L3 cache. No physical shared L3 for all cores to access. Without a centralized cache chip as with z15, this would mean that in order for code that has some amount of shared data to work, it would need a round trip out to main memory, which is slow. But IBM has thought of this.

    The concept is that the L2 cache isn’t just an L2 cache. On the face of it, each L2 cache is indeed a private cache for each core, and 32 MB is stonkingly huge. But when it comes time for a cache line to be evicted from L2, either purposefully by the processor or due to needing to make room, rather than simply disappearing it tries to find space somewhere else on the chip. If it finds a space in a different core’s L2, it sits there, and gets tagged as an L3 cache line.

    What IBM has implemented here is the concept of shared virtual caches that exist inside private physical caches. That means the L2 cache and the L3 cache become the same physical thing, and that the cache can contain a mix of L2 and L3 cache lines as needed from all the different cores depending on the workload. This becomes important for cloud services (yes, IBM offers IBM Z in its cloud) where tenants do not need a full CPU, or for workloads that don’t scale exactly across cores.

    This means that the whole chip, with eight private 32 MB L2 caches, could also be considered as having a 256 MB shared ‘virtual’ L3 cache. In this instance, consider the equivalent for the consumer space: AMD’s Zen 3 chiplet has eight cores and 32 MB of L3 cache, and only 512 KB of private L2 cache per core. If it implemented a bigger L2/virtual L3 scheme like IBM, we would end up with 4.5 MB of private L2 cache per core, or 36 MB of shared virtual L3 per chiplet.

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 1, Interesting) by Anonymous Coward on Monday September 06 2021, @04:31AM

    by Anonymous Coward on Monday September 06 2021, @04:31AM (#1174878)

    IBM's philosophy is build toward no perceptible failures so you apps don't worry about failure. Modern engineering is design to expect failure and recover from it.

    Both approaches breeds different kinds of engineers. We have both setup in the global bank I work for - neither is necessarily "better" than the other, they each have pros/cons and weaknesses/strengths.

  • (Score: 2) by tangomargarine on Monday September 06 2021, @05:35AM (1 child)

    by tangomargarine (667) on Monday September 06 2021, @05:35AM (#1174884)

    Is there a reason we need to keep doing this with the weekly article on this topic for the last couple months?

    I notice that the scare quotes on "7nm" aren't in the original submission, nor am I seeing an explanation of it on a quick Ctrl+F of the article.

    --
    "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
  • (Score: 2, Interesting) by jahaven on Monday September 06 2021, @02:00PM (3 children)

    by jahaven (12434) on Monday September 06 2021, @02:00PM (#1174947)

    The mainframe used to be loved by developers and operators. But it was hated by the financial department, since it used to have a MLC (Monthly license charge) licensing. Which it means, no matter how old is your mainframe, you have to paid a lot each month because the operating system is not yours, it is rented. Now the Mainframes have Linux without MLC, but the old school programs that needs to run under S390, ZOS or MVS, may still apply for the MLC.

    As a machine it still is incredible reliable.

    • (Score: 0) by Anonymous Coward on Tuesday September 07 2021, @04:00AM (2 children)

      by Anonymous Coward on Tuesday September 07 2021, @04:00AM (#1175215)

      Reliable? Can it handle a cup of coffee spilt over it? A kid yanking out all its cables? Wake me up when they invent one of those.

      • (Score: 2) by maxwell demon on Tuesday September 07 2021, @07:28AM

        by maxwell demon (1608) on Tuesday September 07 2021, @07:28AM (#1175248) Journal

        A business that lets kids play with the main servers deserves to fail anyway.

        Next in: All the bridges are not reliable because they don't withstand a meteor impact.

        --
        The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 0) by Anonymous Coward on Sunday September 12 2021, @08:34AM

        by Anonymous Coward on Sunday September 12 2021, @08:34AM (#1177190)

        Wake up. They've invented one of those. You can even replace the broken parts without even turning the whole thing off.

(1)