Clocking and bus width are certainly important factors in performance, but they are far from the only factors.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@wkyr.net] Sent: Tuesday, May 23, 2023 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural questions [WAS: Are Banks Breaking Up With Mainframes? | Forbes] I'm not asking about cache lines, necessarily. With the G3 chip set, as I recall, it had 256 byte wide cache lines, and CPU <-> C-store was using a 256 byte bus while the IOPs <-> C-store were using a 64 byte bus. What makes one system faster than the other has to do with clocking and bus width. So if RAM (C-Store) is running at say, 1/4 of the speed of the CPU, RAM is a bottleneck unless the cache area is much faster so that it buffers C-Store fetch/write. So knowing this about the other chip sets (non z) one can better do modeling to see what the ratio is in "LPARs" or CECs between the systems. I've seen something like a 7 (AIX/Power) to 1 (z800) ratio and the power system could not keep up on I/Os (bytes per second) even though its I/O system was physically faster (for 1-4 fiber optic connections) and the the z800 with slower fiber optic connections actually could do more bytes/second xfer because of how it was not BUS bound. Steve Thompson On 5/22/2023 8:48 PM, David Crayford wrote: > Good question. By bus size I'm assuming that your referring to > cache-lines? I wonder how much of a difference that makes with > OOO pipelines? What I can confirm is that my new Arm M2 MacBook > Pro which has a 32-byte cache-line sizes absolutely smashes my > AMD Ryzen 5 in Cinebench benchmarks. > > On 22/5/2023 8:26 pm, Steve Thompson wrote: >> I have a question about these systems, both z and not z. >> >> What is the current bus width supported? >> >> At the G3 level for "z" the CPU-RAM bus was 256 bytes wide, as >> I recall. >> >> For IOP to RAM it was 64 bytes wide. >> >> For the systems I run (off the shelf stuff for Linux and >> windows) the bus is still at 64bits (8 bytes). Yes it has bus >> mastering, and pathing to allow certain adapter cards to use >> 8bit "channels".... >> >> z/Arch POP has instructions for interrogating the bus sizes. I >> haven't had the time or opportunity to write any tests using >> this to find out what those bus sizes are it would report on. >> >> Steve Thompson >> >> On 5/22/2023 7:52 AM, David Crayford wrote: >>> On 22/5/2023 1:26 pm, Attila Fogarasi wrote: >>>> Good point about NUMA....and it is still a differentiator >>>> and competitive >>>> advantage for IBM z. >>> >>> How is NUMA a competitive advantage for z? Superdomes use >>> Intel UltraPath Interconnect (UPI) links that can do glueless >>> NUMA. >>> >>>> IBM bought Sequent 20+ years ago to get their >>>> excellent NUMA technology, and has since built some very >>>> clever cache >>>> topology and management algorithms. AMD has historically >>>> been crippled in >>>> real-world performance due to cache inefficiencies. >>> >>> What historical generation of AMD silicon was crippled? The >>> EPYC supports up to 384MB of L3 cache and the specs and >>> benchmarks suggest the chiplet architecture can easily handle >>> the I/O. >>> >>>> 10 years ago CICS was at 30 billion transactions per day, so >>>> volume has tripled in 10 years, during the massive growth of >>>> cloud. >>>> Healthy indeed. >>> >>> I have a different perspective on what constitutes healthy. >>> Here in Australia, I've had the opportunity to meet >>> architects from various banks who are actively involved in or >>> have completed the process of migrating the read side of >>> their CICS transactions to distributed systems. They have >>> embraced technologies like CDC and streaming platforms such >>> as Apache Kafka and distributed data stores such as Cassandra >>> and MongoDb. This shift has been primarily driven by >>> disruptive technologies like mobile banking pushing up >>> mainframe software costs. >>> >>> This is a common architectural pattern. >>> >>> https://secure-web.cisco.com/1rtinlBf65Yp0gn5XW0sNTB97uCj9DC3PxiCEuxbH0-IXG14CybdFfPOIfmEf-RXuUxXIFFoLBm_-Q1cD-AEMZ8kHw-zh49NK_BMGM15VMYv7w_NMGFL55g9iswLdGsWfvcVivEFEGID-tlzNJ_QtWUcYyndPOsxLBqlF0Jny_zhtWfStfps6vAMe90NNG7B9Sanvy892rg60j-wFK35Z8ouajlaTnZDlApkrJGr5vFGLxMeaqQpFSHzbewgjibYIdPtDQkHQQ4xTC5vUhIaUIxxWnbPAHMXVysrWcCj2ugNAfn5YmBvOfQBf-kXAIeoGcvixmdesTRb7Exswwz_Jxngy-9--X-xMhmO4Cct_Zw5JhwO2CssUXY5XfwBFCBGNnUGAhKjMEDtz-WIV1NEDogj-wF0Qr_zXE8J8-b0a5bI/https%3A%2F%2Fwww.conferencecast.tv%2Ftalk-29844-nationwide-building-society-building-mobile-applications-and-a-speed-layer-with-mongodb%23.talkPage-header >>> >>> >>>> >>>> On Mon, May 22, 2023 at 2:56 PM David >>>> Crayford<dcrayf...@gmail.com> wrote: >>>> >>>>> Sent again in plain text. Apple mail is too clever for it’s >>>>> own good! >>>>> >>>>>> On 22 May 2023, at 12:46 pm, David >>>>>> Crayford<dcrayf...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 21 May 2023, at 12:52 pm, Howard >>>>>>> Rifkind<howard.rifk...@gmail.com> >>>>> wrote: >>>>>>> Hundreds of PC type servers still can’t handle the huge >>>>>>> amount of data >>>>> like a mainframe can. >>>>>> >>>>> Of course, that's an absurd statement! By "PC type," I >>>>> assume you're >>>>> referring to x86? We can easily break this down. First >>>>> things first, let's >>>>> forget about the "hundreds" requirement. A 32 single socket >>>>> system is >>>>> enough to match up. >>>>> >>>>> AMD EPYC is the poster child for single socket servers, >>>>> running its novel >>>>> chiplet technology on a 5nm process node. AMD's infinity >>>>> interconnects are >>>>> capable of massive I/O bandwidth. You can learn more about >>>>> it here: >>>>> https://www.amd.com/en/technologies/infinity-architecture. >>>>> Each socket >>>>> can have a maximum of 96 cores, but even if we use a >>>>> conservative 64 cores >>>>> per socket, that's a scale-out of 2048 cores. AMD also has >>>>> accelerators for >>>>> offload encryption/compression, etc. >>>>> >>>>> Over in Intel land, the Ice Lake server platform is not >>>>> quite as >>>>> impressive, but the QPI (Quick Path Interconnect) yet again >>>>> handles huge >>>>> bandwidth. Intel also has accelerators such as their QAT, >>>>> which can either >>>>> be on-die SoC or a PCIe card. It's not too dissimilar to >>>>> zEDC but with the >>>>> advantage that it supports all popular compression formats >>>>> and not just >>>>> DEFLATE. You can find more information here: >>>>> https://secure-web.cisco.com/106eZotagdf7kKDcODCHB0y6fobcoBSfXi-F6dt6aVmrM_xh65OkMAO0co4OMqsC11iG8y8bVqPj0hLtf91f3nSxbF_Q7Rj-x2OUbQhYqJ17IEAAnTFZzB-q8FUhSUc2InjUWT1x_3m_drKT50A1ekkdrQ9uf1V9-_zYatRAptJPQmxuJ5hUYTkg20bV1DGltk4PUsPoW6gpPEXOrynVv0Y0MX4cIX3FxDaqUeg0NhhtlIbQ2EE9xkJ583GD-WDFEsXqPRrfFsG-4za6TDZJD9O9QsyP3QfMCIqn9KO_nUiOrSZQzN5AFxXgQQKxksa1czeXv2rdyyIwv9Cm7S2aO_M3c_fsdMvId_KKVB3zKcSpgHGU2Hyx6XnAVGFbKLGNqP-dASX0SaaTpcg7EF-fX6TTONVDen2_rcIzFdkOVFDw/https%3A%2F%2Fwww.intel.com.au%2Fcontent%2Fwww%2Fau%2Fen%2Farchitecture-and-technology%2Fintel-quick-assist-technology-overview.html >>>>> >>>>> . >>>>> >>>>> A more apples-to-apples comparison would be the HP >>>>> Superdome Flex, which >>>>> is a large shared memory system lashed together with NUMA >>>>> interconnects, >>>>> with a whopping 32 sockets and a maximum core count of 896 >>>>> on a single >>>>> vertically integrated system. HP Enterprise has technology >>>>> such as nPars, >>>>> which is similar to PR/SM. They claim 99.999% availability >>>>> on a single >>>>> system and even beyond when clustered. >>>>> >>>>> On the Arm side, it gets even more interesting as the >>>>> hyperscalers and >>>>> cloud builders are building their own kit. Although this >>>>> technology is >>>>> almost certainly the growth area of non-x86 workloads, you >>>>> can find more >>>>> details about it here: >>>>> https://www.nextplatform.com/2023/05/18/ampere-gets-out-in-front-of-x86-with-192-core-siryn-ampereone/ >>>>> >>>>> . >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> For IBM-MAIN subscribe / signoff / archive access >>>>> instructions, >>>>> send email tolists...@listserv.ua.edu with the message: >>>>> INFO IBM-MAIN >>>>> >>>> ---------------------------------------------------------------------- >>>> >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email tolists...@listserv.ua.edu with the message: >>>> INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
