WTB: Heathkit ID-4801 EPROM Programmer

snipped-for-privacy@att.bizzzzzzzzzzzz:

What a great feeling it is to know the truth!

It's a great reparation for all the hardship of a sad life.

Reply to
F. Bertolazzi
Loading thread data ...

DRAM refresh is completely handled and scheduled by the integrated memory controller (Opteron, Nehalem, Sandybridge) or by the northbridge chipset (Pentium family, Xeon prior to Nehalem).

It has had no impact on system execution latency for decades.

If the IMC detects corrected ECC (single or double-bit) errors beyond a programmable threshhold, it will generate a CMCI (corrected Machine Check Interrupt) to the operating software. AMD has an equivelent operation (and a nice bit in the IMC that injects a corrected single-bit error on every memory reference for testing).

The point is, that DRAM refresh has not had a latency impact on running modern x86 processors for two decades.

scott

Reply to
Scott Lurndal

I don't think it ever needed to have an impact on system latency, certainly it never did on any of the Z80 systems I built.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/
Reply to
Ahem A Rivet's Shot

Ahem A Rivet's Shot:

That's why they've built multiple-pipelines processors.

The refresh, on the Z80, was done right after the instruction fetch, while the instruction decoder was busy figuring out what to do. In that time the bus would have been idle anyway, that's why Federico used it for DRAM refresh.

Reply to
F. Bertolazzi

'ey! krw.

How are you doing?

/BAH

Reply to
jmfbahciv

Ah, you can't.

I don't need to impress you. You, apparently, have a need.

I don't brag.

Your work exists because of the ground work people in a.f.c. and others did before you got potty trained. Too bad that training didn't last.

Another snot-nosed kid who needs a semi-truck of Kleenix.

/BAH

Reply to
jmfbahciv

First, refresh is cheduled. Then, refresh is pending. Then, refresh is urgent. Then, it closes the current row, and does its thing while all other access is blocked. Then, the row is reopened again. And this happens with the rate of 68ms for every row. Refresh is one of the factors contributing to the system latency.

Refresh has ever increasing effect on the CPU latency in cycles, as the speed gap between CPU and DRAM increases. The effects of refresh are very visible at sub-microsecond time scale.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Of course. If DRAM is twice as fast as processor, then refresh cycles could be free. But when DRAM is 100 times slower, the situation is a bit different.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Vladimir Vassilevsky:

Well, to be precise, that was not the case. As a matter of fact the M1 (fetch+refresh) was the most critical, for the memories. At the time a 4MHz CPU and the RAM were equally fast.

It's what I was trying to explain to a guy in another NG. With a Z80 and a modern static RAM you can easily write on video RAM while doing screen refresh.

Of course. I was about to answer also to Scott, but I thought that it was your discussion. ;-)

To be precise, the RAM is not slower, it's almost ten times faster than then. It's the processor that is some thousands times faster.

Reply to
F. Bertolazzi

"Michael A. Terrell" wrote in news:0audnf5HDd43wlbRnZ2dnUVZ snipped-for-privacy@earthlink.com:

On the contrary. But thanks for stopping by, the door is that way,

----> don't let it hit you on the way out.

--
Paul
Reply to
Paul

The DRAM controller has a queue of requests to the DRAM from all bus masters; refresh controller is one of them. Each request is assigned priority; this priority depends on the variety of things such as what subsystem originated the request, how urgent is this request, how long the request was pending, if the request falls into the currently opened row, etc. etc. etc. The request that wins the arbitration gets the access to DRAM.

It is quite possible that the DRAM controller queue will be empty at instant as the cores are running from their caches and all other masters are in idle; so the refresh request will be serviced transparently to the other operation. However, the system latency is determined by the worst case scenario rather then the best case. As such, refresh is one of the factors that have dramatic impact on the system latency; although the averaged effect of refresh on the system speed is negligible.

(Yes, I do work with DDR/DDR2 and their controllers).

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Hey Barb!

Just peachy down here in AL. How's it going in MI? Snow yet? ;-)

Reply to
krw

Vladimir Vassilevsky:

Gosh! And all those tasks are done in hardware, I suppose. Is the achitecture similar to a MMU? Does it have a sort of TLB?

Reply to
F. Bertolazzi

Why would there be any translation going on?

Reply to
krw

YKYBHTL when you misspell "Kleenex" in that particular way.

-- Roland Hutchinson

He calls himself "the Garden State's leading violist da gamba," ... comparable to being ruler of an exceptionally small duchy.

--Newark (NJ) Star Ledger (

formatting link
)

Reply to
Roland Hutchinson

Or when it's tempting to start a new fork of *nix just to use that name.

-- Patrick

Reply to
Patrick Scheible

Great!

No snow...yet. Had a 3-day wind storm which felt like I was on Mt. Washington.

Other stuff in MI is going as expected.

/BAH

Reply to
jmfbahciv

ROTFLMAO. Aw, shit.

/BAH

Reply to
jmfbahciv

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.