In CI Nos 1,070, 1,072 and 1,075, Peter White looked at what IBM can technically achieve – given its cautious des ign rules – in its next two generations of top-end CPUs, and today it all comes together.
It is the physical data skew caused by the channel protocol, described in CI No 1,075, that has led to widespread speculation that the 20Mb a second channel that IBM is expected to launch, will in fact use a new serial protocol. We know the fast channel is coming because it was pre-announced at La Hulpe earlier this year. The speed however is dependent upon how quickly a component, in this case a laser, can switch. By going to a serial protocol, IBM has put a strain on this technology, and it will have to signal a lot faster than its old parallel protocol just to deliver the same overall speed. But the belief is there that laser technology can already take it to 20 (or as was predicted at La Hulpe, 18Mb) per second now, and eventually on up to 200Mb a second. This isn’t the theoretical limit of this technology, but its as fast as the internals of an IBM machine could receive it, so until there is a new architecture in the middle, that is as fast as IBM could want. Marketspeak Shrewd observers will note that a new channel architecture like this is a perfect opportunity to introduce a new CPU architecture. You can have all these wonderful storage goodies, as long as you buy a Summit processor has that strange compelling IBM marketspeak about it. But the attractions of what will appear as a superfast channel can’t be sold for Summit only, people will want them now, not when their machine goes off lease, or when they’ve saved enough for a new one. And IBM traditionally allows storage technologies to overlap architectures, and a more reasonable strategy would be to implement the fast channels first on the 3090S models, and to have even faster ones appear later, exclusively for implemenation on Summit.
But to retrofit a new input-output protocol into a machine like the S would be expensive and upsetting to customers. What about all that storage attached already which cannot be converted to serial input-output? It is therefore reasonable to assume, as is rumoured, that IBM has already fitted components into the S that will do high speed translation between the two input-output protocols, and it would be a typical component area for the GaAs parts that it is known to be fabricating, because IBM will need an extremely fast chip to do the job, probably faster than any currently commercially available chip. In effect the CPU would eventually be able to treat the outside world as it if was Expanded Storage, but in the meantime ES acts as a huge fetch buffer between a soon-to-be 18 megabyte a second physical world, and the main CPU memory. Questions immediately arise such as how fast the disks need to go if there is sufficient prediction of all the data needed. And the answer is likely to be that the faster the disks rotate, the easier the problem will be for IBM to overcome. To facilitate a storage architecture of this type, IBM will want faster access times, and this may even mean smaller disks, smaller platters, and better still, multiple disk heads on smaller platters – which is just what disk guru Jim Porter is forecasting. IBM says that some head-of-string drives can be eliminated under ESA (although the claim that this can more than pay for your new expensive and massive internal memory have to be taken with more than a pinch of salt). What will control all this data at the end of a 18/20/200Mb a second channel? IBM has already entrusted the care of all the world’s data to DFSMS, the series of storage management products that was announced with ESA.
The answer is a processor that runs not DB2 (although a version of that could be there as well) but the SMS Storage Management System. At the moment little would be gained from putting an SMS processor at the other end of a 20 Megabytes a second line, but little may well be enough, along with a new serial protocol for input-output, to give top-end users some relief from storag