It was in the mid-1970's that I worked closely with mainframe hardware.
Let me reminisce about the more interesting aspects of IBM 370 cycle-times.

- Model 145.
While 158 and 168 had a single cycle-time, the 145 cycle-time was variable: At first 180, 225, 270 or 315 nanosecs -- all multiples of 45 nsecs. 32-bit ALU operations took 45 nsec more than 16-bits. (The ALU was only 16 bits wide.) Storage ops used two cycles. But IBM couldn't quite get this
to work. Microinstruction fetch was the difficult timing IIRC. So
22.5 nsecs was added to EVERY cycle. The oscillator had a 45 nsec period,
so to achieve the extra 22.5 nsec per cycle the oscillator output was immediately XOR'ed with a toggling latch output!
Thus the actual cycle times were all multiples (9, 11, 13 or 15)
of 22.5 nsecs.
The control storage had error detection and correction but this
was NOT the reason for the fetch speed difficulty. Nothing irrevocable was done during the first 90(?) nsec of a cycle, so error detection was not a critical path: A cycle could be restarted once the error was detected and corrected. That extra delay (called 'corr' cycle) might have been 90 nsecs.

- Model 135
Cycle times were all multiples of 55 nsec; typical multiples were
5, 5+3, 5+6, 5+9, 5+12.
IIRC only a single 55 nsec extra was needed when a storage op required an already-buffered address translation.
The Model 138 was similar to the 135 but had some major differences.
In particular the TS (Test-and-Set) instruction had completely different
timing from other storage ops, and the first 370/138s which IBM shipped COULD NOT HANDLE single-bit-errors during a TS write! Obviously they didn't properly test the SBE/TS combination. I worked for AMS/Intersil and am proud that my memory diagnostic was complex enough to experiment with TS throughout
memory. (IBM FE's even used MY diagnostics on occasion, when IBM's diagnostics could not reproduce a failure.)

- Model 158.
Cycle time was a constant 115 nanoseconds. Interesting were Multiprocessors, since each processor had its own oscillator and clocking circuits. The two processors had identical speed but the phase relationship between the two varied unpredictably. This was mitigated by passing remote control signals through a series of edge-triggered latches (triggered by different phases of the local clock). Data accompanying the control would be stable by the time that signal passed through 3 or 4 of those latches, so only a handful of signals needed to be passed through such a latch series.
(The re-clocking was needed to make the probability
of a "metastability" surviving the latches infinitesimal.)

- Model 168
Cycle time was a constant 80 nanoseconds. Again the (24 tonne!) Multiprocessor was the interesting case. Each processor had its own oscillator BUT when memory was shared or cross-configured the system ran on a single clock.
Data, address and signals from one CPU to the opposite CPU's memory needed to pass through MUXes and several feet of cabling. So a memory read that ordinarily
used 4 cycles now required 5 cycles. The extra cycle took the form of half-a-cycle
outbound and a second half-cycle inbound. This was achieved by INVERTING the clock in the storage cabinets! I.e. the +40/-40 clock signal became -40/+40.

- Model 3031
The CPU and the Channel Director were each stripped 158s,
so a common 115 nsec clock was used.

- Model 3032
The Channel Director was slowed from the default 115 to 120 nsec and integrated with an 80-nsec 168 look-alike. Thus three different phase relationships were possible when the 120 & 80 nsec systems communicated.

- Model 3033
Documentation shows that the processor was designed for a 57.5 nsec cycle, exactly half the 115 nsec Channel Director. But at some point they noticed that the system ran error-free at 57/114. I don't know whether
they wanted the extra 0.9% of speed or just disliked the pesky decimal
point in "57.5". :-)
Among the reasons the 3033 CPU was much faster than the 168 was re-organization IIUC. Instead of packaging bit slices separately, logic was segregated into functional units.


Cheers,
James

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)