Getting data in and out of a top-end CPU is stretching IBM to its limits in design capability. One solution is simply to keep adding more memory to the CPU, and keep more and more data active. That is all right so long as memory is cheap, which it isn’t at the moment, but IBM reckons that it anyway hits theoretical limits at around 512Mb of real storage, given its current storage design. The circuit density on IBMs memory chips means that more and more miles of interconnect wiring exist inside the machine, and although the mean time between failures of both chip and interconnect can be held up incredibly high (IBM tells customers that its memory chips have an mean-time-between failures of four centuries), there are so many chips and so much wiring that a memory failure of some description is in current technology still likely to occur every 15 or 16 months in each processor.
Addressing problem If you move up into the 2.5Gb of main memory instead of using Expanded Storage, it would bring that down to an unacceptable one failure every eight hours. IBM claims it is these problems in perfecting a technology of sophisticated storage at that level that has stopped it at 512Mb of main storage and made it turn to Expanded Storage which is far easier to build, and which uses about 70% fewer circuits than real memory. Competitors have always claimed that IBM simply has an addressing problem rather than having reached some kind of theoretical maximum, which might be equally true, although IBMers strenuously deny it, and are happy to go on at length about the relationship between the TCM, logic chips, CPU cache and the memory it all addresses. It must be remembered that Expanded Storage has no storage protection keys, no execution circuits, and can cope with only 4K-page addressing, and it is reasonable to accept it as a temporary fix technology to take the memory limit on the machine up to the 2.5Gb a 600S running ESA can need in maximum configuration. IBM proudly proclaims that it is quite an achievement in its own right, and that neither Amdahl-Fujitsu nor Hitachi have delivered any Expanded Storage of their own. That’s not strictly true since both companies simply place the same old real-memory chips in the place of Expanded Storage, and reckon that their chips are reliable enough to sustain it. IBM maintains that this will lead to reliability problems, but both Fujitsu and Hitachi believe believe they have a sufficiently large lead on IBM in terms of basic chip reliability and so don’t feel compelled to go off and build a special extra reliable and simple memory chip for Expanded Storage. However Amdahl has announced a form of ES on its new 5990, which just began shipping, but no word yet. But where will the IBM customer go from here? What can IBM offer once it has installed 512Mb real, 2Gb Expanded? It is interesting to note that some observers have spotted that the Expanded Storage chip card using 1 ES megabit chips is only 25% occupied. That leaves room for a fourfold growth in memory, and an increasing tendency within the 3090 architecture for one very high speed core, being fed via the memory bus by up to 8Gb of Expanded Storage.
That would probably take ES to its own theoretical limits of circuitry, and any growth beyond there would lead to the same reliability troubles that IBM had forecast for its real memory. It is difficult to say how much performance improvement can be gained merely by increasing the Expanded memory, but it seems likely that it will yield a noticeable amount and that any competitor wanting to follow suit needs to make its own memory chips, or it will have trouble joining Enterprise Systems Architecture at the 8Gb level and above which is signalled, especially while the current memory shortage endures. But still the bottleneck created by the IBM channels looms large, and getting stuff through them at their current speed of 4.5Mbytes a second remains a problem. Keeping 8Gb of Expanded Storage full up with the right data when it is filling up so slowly still requires an awful lot of channels, which i
n turn require MIPS to manage. If IBM could take the Start I/O command out of the vocabulary of the CPU, it would speed things up considerably. IBM makes no secret that what it would like to do is bring data from disk at the same speed that it is fed along the internal memory bus, at 200Mb a second, but there are a few technologies it must crack first. It would also like to extend the synchronous nature of data that is pre-fetched and ready for action that it has achieved with its advanced high speed buffer algorithms inside the latest CPU cache. IBM already talks no longer in terms of pre-fetching data and instructions for a predicted branch in a program, but in terms of lining up the correct intructions for the branch, without the CPU getting involved with the management of the branch itself. It calls this Pre-Execution. That’s all very well, but if at the end of the day data is still out on disk, then the Expanded Store, the cache and the CPU wait what must seem an eternity in comparison with processing speeds, for that data to arrive. What IBM needs to achieve is a complete predictive sequence that means that the next piece of data will never be out on disk, and that the furthest away it could be is on a medium that moves at the speed of its memory bus, 200Mb a second. The only other answer is to keep all of the data in fast memory like Expanded Store all the time.
Back-end machine The work IBM has done to insulate the CPU from the effects of disk is probably the centre of the rumours that have been emanating from the company for the past eight years, that it plans to build a back-end database processor. The issue on a processor like this is not that it runs DB2 at super fast speed, but that it can get things through the channel arrangement and into the CPU, before the CPU evens knows it needs it. That means cache from CPU to storage, from storage to Expanded Storage, from ES to back-end machine, cache out to the relevant disk controller, and data all the way back in, in the time it takes to pre-fetch an instruction and read it before loading it into the CPU. An ambition of that magnitude has to overcome a number of major obstacles. The cabling that is the data highway of the channel can’t go fast enough. At the moment it operates under a parallel protocol, and regardless of the medium used (in fact fibre optics), as long as data is sent in parallel, it is subject at very high speeds to corruption. Explained simply this is the tendency for one bit from a byte packet not to arrive on time, and to get mixed up with the next one. It all comes about because although components can be made to operate faster, they can’t be made to send at exactly the same speed, and once you get above IBM channel speeds, they start to become difficult to deal with. Other companies manage, but IBM is unhappy with the potential for disaster on that particular horizon, given its conservative design nature.
