> On Oct 5, 2020, at 11:50 AM, Jon Elson via cctalk <cctalk@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
