9 track tapes and block sizes

[Paul Koning]

> On Oct 5, 2020, at 11:50 AM, Jon Elson via cctalk <cctalk at classiccmp.org> wrote:
> 
> On 10/04/2020 11:30 PM, Chuck Guzis via cctalk wrote:
>> The problem arose if the program either failed to keep up (e.g. competing programs demanding the CPU) or if an ECS transfer occurred. Where I got involved was with a 4-CPU configuration sharing 4MW of ECS, using the ECS for swap space. ECS transfers completely swamp the read/write pyramid, so the PP gets locked out and can't service the drive. Recovery was doing a backward-read to the BOT or preceding IRG. Lather, rinse, repeat. It was fun to watch and we never solved that one to anyone's satisfaction.
> I can't imagine any way to fix this except to put a buffer memory in the PP big enough to hold a few records of tape data.  Probably played hob with disk transfers, too, except that wasn't as visible.
> 
> Jon

Actually, on a full memory 6000 series system (32 banks) there is more than enough bandwidth to service an ECS transfer and other things too.  ECS runs at 10 MWords per second.  The bandwidth per bank is 1 MW/s so with 32 banks that only takes 1/3rd of the system bandwidth.  I don't know the 6400 memory controller, but the Stunt Box on the 6600 will happily schedule all the memory requests, whether from CPU, PPs, or ECS, and fairly issue them to the banks.  It would be interesting to run a simulation for that.

	paul