smlg1015@uxa.cso.uiuc.edu (10/26/90)
Dear sci.electronics: Now that I'm putting more memory on to the lab`s computer, it got me thinking about the refresh of DRAM. If one increases the amount of DRAM by a factor of 4, say, does this mean that the microprocessor spends 4 times as much time refreshing, and hence, less time executing useful instructions? Does refreshing occur chip by chip, or all DRAMS chips simultaneously? For all practical purposes, does the addition of more memory (after a certain limit) lose its appeal because of refresh? Just wondering, Stuart Lichtenthal
henry@zoo.toronto.edu (Henry Spencer) (10/26/90)
In article <44900017@uxa.cso.uiuc.edu> smlg1015@uxa.cso.uiuc.edu writes: >... If one increases the amount of DRAM by a factor of >4, say, does this mean that the microprocessor spends 4 times as much time >refreshing, and hence, less time executing useful instructions? Does refreshing >occur chip by chip, or all DRAMS chips simultaneously? ... In sensible designs, memory refresh is simultaneous over the whole array. Also, in general it is done by independent hardware, with the processor not involved, although the result may be occasional slight delays in processor memory accesses. -- The type syntax for C is essentially | Henry Spencer at U of Toronto Zoology unparsable. --Rob Pike | henry@zoo.toronto.edu utzoo!henry
dwaddell@pyrman2.pyramid.com (David Waddell) (10/27/90)
In article <44900017@uxa.cso.uiuc.edu> smlg1015@uxa.cso.uiuc.edu writes: > >Dear sci.electronics: > >Now that I'm putting more memory on to the lab`s computer, it got me thinking >about the refresh of DRAM. If one increases the amount of DRAM by a factor of >4, say, does this mean that the microprocessor spends 4 times as much time >refreshing, and hence, less time executing useful instructions? Does refreshing >occur chip by chip, or all DRAMS chips simultaneously? For all practical >purposes, does the addition of more memory (after a certain limit) lose its >appeal because of refresh? > >Just wondering, > >Stuart Lichtenthal In answer to the first question: no, refresh will not cause loss of cycles. DRAM refresh cycles are not dependent on the cpu the way you are thinking. Don't Worry Be Happy Lucky aka David Components Tech Opinions expressed are my own.
rick@ofa123.fidonet.org (Rick Ellis) (10/30/90)
> If one increases the amount of DRAM by a factor of > 4, say, does this mean that the microprocessor spends 4 times as much time > refreshing, and hence, less time executing useful instructions? No. Refresh is done in parallel. -- Rick Ellis Internet: rick@ofa123.fidonet.org Compuserve: >internet:rick@ofa123.fidonet.org BBS: 714 939-1041 --------------------------------------------------------------------------
thoger@solan8.solan.unit.no (Terje Th|gersen) (11/01/90)
In article <1445.272CBD1B@ofa123.fidonet.org>, rick@ofa123.fidonet.org (Rick Ellis) writes: |> |> > If one increases the amount of DRAM by a factor of |> > 4, say, does this mean that the microprocessor spends 4 times as much time |> > refreshing, and hence, less time executing useful instructions? |> |> No. Refresh is done in parallel. |> |> |> -- |> Rick Ellis |> Internet: rick@ofa123.fidonet.org |> Compuserve: >internet:rick@ofa123.fidonet.org |> BBS: 714 939-1041 |> -------------------------------------------------------------------------- Hmm.. In an old (autumn 1987) issue of BYTE they were testing 12 exTended memory expansion board. They measured and published figures for how much each board slowed down the system, just by being installed... They even got different figures for each board... They claimed that this slowdown was due to the extra time it takes to refresh the extra RAM. I don't know much about this, but that's what the article said.. ( I read this a week or so ago, so I'm sure about it..) -Terje ____________________________________________________________________________ thoger@solan.unit.no | Institute of Physical Chemistry THOGER AT NORUNIT.BITNET | Div. of Computer Assisted Instrumental Analysis | Norwegian Institute of Technology
graeme@research.canon.oz.au (Graeme Wong See) (11/05/90)
In article <1990Oct31.194436.28242@idt.unit.no> thoger@solan.unit.no writes: >In article <1445.272CBD1B@ofa123.fidonet.org>, rick@ofa123.fidonet.org (Rick Ellis) writes: >|> >|> > If one increases the amount of DRAM by a factor of >|> > 4, say, does this mean that the microprocessor spends 4 times as much time >|> > refreshing, and hence, less time executing useful instructions? >|> >|> No. Refresh is done in parallel. >|> >|> >|> -- >|> Rick Ellis >|> Internet: rick@ofa123.fidonet.org >|> Compuserve: >internet:rick@ofa123.fidonet.org >|> BBS: 714 939-1041 >|> -------------------------------------------------------------------------- > >Hmm.. >In an old (autumn 1987) issue of BYTE they were testing 12 exTended memory >expansion board. They measured and published figures for how much each board >slowed down the system, just by being installed... They even got different >figures for each board... They claimed that this slowdown was due to the extra >time it takes to refresh the extra RAM. > >I don't know much about this, but that's what the article said.. ( I read this >a week or so ago, so I'm sure about it..) > > -Terje Quite possibly because the AT Bus is running at 8MHz, so refreshing that DRAM takes longer than refreshing DRAM on the motherboard which can be refreshed at a greater speed. graeme. -- Graeme Wong See, Hardware Engineer | Net: graeme@research.canon.oz.au Canon Information Systems Research Australia | Phone: +1 61 2 805 2912 P.O. Box 313 North Ryde, NSW, Australia 2113 | Fax: +1 61 2 805 2929
mcorbin@oucsace.cs.OHIOU.EDU (Corvin Hasset) (11/05/90)
To relieve drain completely from the micro. One could use a 8203 or such chip to handle refreshing. -- mcorbin@oucsace.cs.ohiou.edu +-----+---\ +-----+ CS559@ouaccvmb.bitnet | | | | -- >| ---+ "Flat possums never DIE!" -RoADkIll +-+-+-+---/ +-----+
tjk@ccwf.cc.utexas.edu (Todd Kelman) (11/07/90)
In article <1990Nov5.063219.2266@research.canon.oz.au> graeme@research.canon.oz.au (Graeme Wong See) writes: >>In an old (autumn 1987) issue of BYTE they were testing 12 exTended memory >>expansion board. They measured and published figures for how much each board >>slowed down the system, just by being installed... They even got different >>figures for each board... They claimed that this slowdown was due to the extra >>time it takes to refresh the extra RAM. >> >>I don't know much about this, but that's what the article said.. ( I read this >>a week or so ago, so I'm sure about it..) >> >> -Terje > >Quite possibly because the AT Bus is running at 8MHz, so refreshing that DRAM >takes longer than refreshing DRAM on the motherboard which can be refreshed >at a greater speed. > >graeme. >-- The problem here stems from the fact that memory refreshing is usually carried out through DMA cycles. The implications of this are that the microprocessor must give up the bus during a refresh cycle (a normal operation of a DMA cycles, and thus cannot fetch or execute instructions that require memory accesses (which is about all of them). The exception is for cache based systems, where the bus to the cache is seperate from the main memory bus. As long as there isn't a cache 'miss' then performace is not affected. (There is more to it than that, however. If the cache is implemented as a write-through, where all writes to the cache go through to main memory, then you have the same problem.) The conclusion is that for more memory, there will be more refresh necessary, and thus more DMA cycles necessary, and more time where the processor must release the bus to the memory controller. I hope this clears things up. By the way, please excuse the etiquette(lack thereof), since this is my first attempt at a post. ----------------------------------------- Todd Kelman (tjk@ccwf.cc.utexas.edu) Computer Engineering and Computer Science The University of Texas at Austin -----------------------------------------
koch@motcid.UUCP (Clifton Koch) (11/07/90)
->>>In an old (autumn 1987) issue of BYTE they were testing 12 exTended memory ->>>expansion board. They measured and published figures for how much each board ->>>slowed down the system, just by being installed... They even got different ->>>figures for each board... They claimed that this slowdown was due to the extra ->>>time it takes to refresh the extra RAM. ->>> ->>Quite possibly because the AT Bus is running at 8MHz, so refreshing that DRAM ->>takes longer than refreshing DRAM on the motherboard which can be refreshed ->>at a greater speed. ->> -> The problem here stems from the fact that memory refreshing is usually -> carried out through DMA cycles. The implications of this are that the -> microprocessor must give up the bus during a refresh cycle (a normal operation -> of a DMA cycles, and thus cannot fetch or execute instructions that require -> memory accesses (which is about all of them). The exception is for cache -> based systems, where the bus to the cache is seperate from the main memory -> bus. As long as there isn't a cache 'miss' then performace is not affected. -> (There is more to it than that, however. If the cache is implemented as -> a write-through, where all writes to the cache go through to main memory, -> then you have the same problem.) -> -> The conclusion is that for more memory, there will be more refresh necessary, -> and thus more DMA cycles necessary, and more time where the processor must -> release the bus to the memory controller. I hope this clears things up. It depends on how the refresh is implemented, on whether or not you'll find a performance difference. A DMA channel is used on PCs (unfortunately) to refresh the DRAM. Each chip has to have each row address read or written every 4ms in order to refresh it. The DMA controller refreshes by moving a block of memory to itself. If you have a single bank of DRAM (1 bank being the number of chips necessary for one word width on the data bus) then one block move will have to be done. If you expand the chips themselves, say from 1Mbyte to 4Mbyte chips, there shouldn't be any impact on refresh. If you expand memory by adding more banks of DRAM, whether on the motherboard or on an aboveboard memory card, the DMA controller has to hit more addresses so that each chip is refreshed, and therefore has to do more block moves in the same 4ms. In a *real* refreshing scheme, you would refresh all banks at the same time, or if you want to get tricky, stagger the bank refresh so that the refresh of 1 bank coincides with a memory access to another bank.
henry@zoo.toronto.edu (Henry Spencer) (11/08/90)
In article <39251@ut-emx.uucp> tjk@ccwf.cc.utexas.edu (Todd Kelman) writes: >>>... They measured and published figures for how much each board >>>slowed down the system, just by being installed... >>Quite possibly because the AT Bus is running at 8MHz, so refreshing that DRAM >>takes longer than refreshing DRAM on the motherboard... > >The problem here stems from the fact that memory refreshing is usually >carried out through DMA cycles... Not quite; memory refreshing *on IBM PCs, clones, and descendants thereof* is usually carried out through DMA cycles. Most real computers do it within the memory circuitry, so that it doesn't need to elbow the processor off the bus, and do all boards/banks in parallel rather than one at a time, so their refresh overhead is independent of memory size. Don't confuse PCs with well-engineered computers; remember, those things were designed at a time when 256KB was a lot of memory. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
wilker@descartes.math.purdue.edu (Clarence Wilkerson) (11/09/90)
This is a little hazy, but a few years back I rewrote the PAL on the Zenith 150 memory board to use 256k chips. I seem to remember that there was a special line to activate all banks during the refresh cycle. I don't have the PAL equations handy to verify this right now.
jimc@isc-br.ISC-BR.COM (Jim Cathey) (11/09/90)
In article <5093@navy22.UUCP> koch@motcid.UUCP (Clifton Koch) writes: > It depends on how the refresh is implemented, on whether or not you'll >find a performance difference. A DMA channel is used on PCs (unfortunately) >to refresh the DRAM. >... >If you expand memory by adding more >banks of DRAM, whether on the motherboard or on an aboveboard memory card, >the DMA controller has to hit more addresses so that each chip is refreshed, >and therefore has to do more block moves in the same 4ms. As I recall, PC memory boards are informed via the bus that a special DMA on channel 0 is in progress, so they refresh all the rows of all the chips at once rather than actually doing a DMA cycle. Thus, the PC's DMA only has to cycle 128 (or was it 256) times to refresh all the memory regardless of the amount present. It's _still_ a sucky way to do refresh. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
srh@tridom.uucp (Steve Harmon) (11/09/90)
>>>>In an old (autumn 1987) issue of BYTE they were testing 12 exTended memory >>>>expansion board. They measured and published figures for how much each board >>>>slowed down the system, just by being installed... They even got different >>>>figures for each board... They claimed that this slowdown was due to the extra >>>>time it takes to refresh the extra RAM. >>>> >>>Quite possibly because the AT Bus is running at 8MHz, so refreshing that DRAM >>>takes longer than refreshing DRAM on the motherboard which can be refreshed >>>at a greater speed. >>> >> The problem here stems from the fact that memory refreshing is usually >> carried out through DMA cycles. The implications of this are that the >> .... >> >> The conclusion is that for more memory, there will be more refresh necessary, >> and thus more DMA cycles necessary, and more time where the processor must >> release the bus to the memory controller. I hope this clears things up. > > It depends on how the refresh is implemented, on whether or not you'll >find a performance difference. A DMA channel is used on PCs (unfortunately) >to refresh the DRAM. Each chip has to have each row address read or written >every 4ms in order to refresh it. The DMA controller refreshes by moving >a block of memory to itself. If you have a single bank of DRAM (1 bank >being the number of chips necessary for one word width on the data bus) >then one block move will have to be done. If >you expand the chips themselves, say from 1Mbyte to 4Mbyte chips, there >shouldn't be any impact on refresh. If you expand memory by adding more >banks of DRAM, whether on the motherboard or on an aboveboard memory card, >the DMA controller has to hit more addresses so that each chip is refreshed, >and therefore has to do more block moves in the same 4ms. > > In a *real* refreshing scheme, you would refresh all banks at the same >time, or if you want to get tricky, stagger the bank refresh so that the >refresh of 1 bank coincides with a memory access to another bank. Hmmm... My memory is a little fuzzy about the PC design (or lack of) so I'm sure someone will be kind enough to correct me if I'm way off base. As I remember it, channel 0 of the DMA controller is used as nothing more than an address generator. It periodically aquires the bus, asserts an address and starts a transfer cycle which is signaled as a refresh cycle (via -BREFRESH I believe). The amout of memory that is being refreshed is not significant to the refresh scheme. Although, memory placed on the expansion bus will probably be subject to wait states. All in all, the only reason that I see for increased refresh time for above board memory would be due to the added wait states. | | Steve Harmon @ Devient Designs Atlanta, Georgia. | UUCP: ..gatech!emory!tridom!srh | VOICE: (404) 995-5773 |
koch@motcid.UUCP (Clifton Koch) (11/15/90)
-> Hmmm... My memory is a little fuzzy about the PC design (or lack of) -> so I'm sure someone will be kind enough to correct me if I'm way off base. -> As I remember it, channel 0 of the DMA controller is used as nothing more -> than an address generator. It periodically aquires the bus, asserts an -> address and starts a transfer cycle which is signaled as a refresh cycle -> (via -BREFRESH I believe). The amout of memory that is being refreshed is -> not significant to the refresh scheme. Although, memory placed on the -> expansion bus will probably be subject to wait states. All in all, the only -> reason that I see for increased refresh time for above board memory would be -> due to the added wait states. Yup, I had forgotten about the refresh signal on the PC bus, so I was wrong (oh, well, it had to happen someday :-). -- ----------------------------------------------------------------------------- ... [uunet | mcdchg | gatech | att]!motcid!koch