5 Oct
2020
5 Oct
'20
10:01 a.m.
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:
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
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