Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!gnu
From: gnu@sun.uucp (John Gilmore)
Newsgroups: net.micro,net.arch
Subject: net.digital: low overhead refresh controller?
Message-ID: <1179@sun.uucp>
Date: Wed, 30-May-84 05:31:28 EDT
Article-I.D.: sun.1179
Posted: Wed May 30 05:31:28 1984
Date-Received: Fri, 1-Jun-84 07:28:50 EDT
References: <398@turtlevax.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 15

It occurred to me a year or two ago that you could gain about 5% in
system performance if you had a refresh controller chip that actually
kept track of which rows needed refreshing (haven't been referenced
for 2ms) and which didn't.  Since in executing typical code you hit 90
or 100% of the rows, the 5% refresh overhead should drop to .5 or 0%.

I'm not clear on an optimal algorithm for figuring out which rows to
refresh while always hitting all of them within 2ms, but I'm sure you
could do a LOT better than refreshing every row every chance.

The chip would have to deal with memory banking or interleave but this
could probably just be done with one chip per memory bank anyway.

This idea also occurred independently to Jim Lockwood (of NCR, now Sun)
but nobody has taken either of us seriously.  Why not, isn't 5% worth it?