Printable View
Did you look at EMC's chart in Post 89? he has calculated the actual Tref for everything from 200 to 300FSB at the various settings (not all are there)
I find that an actual refresh of 5 - 6 seems to be the most stable, etc.
What is the fastest for a bench etc....is another matter.
what would be the best for mi TCCD @ 300mhz?
Thanks for bringing that post to my attention. That table is consistent with the formula I posted. I guess what I'm still trying to clear up is whether or not I can expect more stability from a lower refresh period. Right now I'm at 15.6us so If I lowered it to 7.8 or around 5 - 6 like you suggest I would get more stability. And the higher the refresh period the more bandwidth.
I thought I'd give this a bump. Anybody have an answer for my last post.
Ok, so I got really interested in this thread, because myselft didnt know what the optimal value was for my DIMM's but I think its best we let AMD manual speak on the subject to clear up a few things:
http://www.amd.com/us-en/assets/cont...docs/26094.PDF
"
Refresh Rate (Tref)—Bits 12–8. Specifies the refresh rate of the DIMM requiring the most frequent
refresh. These bits are encoded as follows:
00000b = 100 MHz 15.6us
00001b = 133 MHz 15.6us
00010b = 166 MHz 15.6us
00011b = 200 MHz 15.6us
31 23 22 20 19 13 12 8 7 6 4 3 1 0
reserved Twcl reserved Tref
reserved
Trwt reserved
Twtr
Bits Mnemonic Function R/W Reset
31–23 reserved R 0
22–20 Twcl Write CAS Latency R/W 0
19–13 reserved R 0
12–8 Tref Refresh Rate R/W 0
7 reserved R 0
6–4 Trwt Read-to-Write Delay R/W 0
3–1 reserved R 0
0 Twtr Write-to-Read Delay R/W 0
106 Memory System Configuration Chapter 3
26094 Rev. 3.28 October 2005 BIOS and Kernel Developer’s Guide for the AMD Athlon™ 64 and
AMD Opteron™ Processors
01000b = 100 MHz 7.8us
01001b = 133 MHz 7.8us
01010b = 166 MHz 7.8us
01011b = 200 MHz 7.8us
10000b = 100 MHz 3.9us
10001b = 133 MHz 3.9us
10010b = 166 MHz 3.9us
10011b = 200 MHz 3.9us
"
o0hh.. scary stuff!
The GIST of it
TREF is the # of clock cycles between RAM refreshes. (Information in RAM is stored in capacitors and decays/disipates over time.. requiring periodic refresh of information before it disappears)
http://en.wikipedia.org/wiki/Dynamic..._access_memory
Lower # of clock cycles is less stringent and should be more easily handled... but the more often you refresh, the more of your time you take up doing it instead getting down to business of getting and changing data. So, for optimal performance, the TREF should be as large as your memory can handle. (According to my SDRAM lecture notes it typically accounts for 2-4% of memory time)
Whats the deal with "200Mhz 7.8us" vs "166Mhz 7.8us"?
Suppose that the absolute latest that you can deley RAM refresh is 5.0us. Well, that will translate to different number of clock cycles dependent on the frequency of the chips. It has nothing to do with multipliers, fsb, htt, command rate or anything else. In its infinite wisdom the memory controller periodically cycles through all the memory banks and refreshes their data contents.
Now, by no means am I a full fledged memory controller designer or something so I still havent figured out for example why my BIOS likes to select 200Mhz 15.6us for my 2x512MB of BH5, but if I can confirm that previously mentioned relationship between capacity/#banks and the micro-second rating, I'll get back to you guys right away.
http://www.jedec.org/download/search/3_09_04R10.pdf
PS: Jedec is the international standards organization that makes sure that your DIMM from korea works with motherboard made by a different taiwan company...
NOTES
1. Pin numbers and pin count are for
reference only. This is a pin rotation
only. Package dimensions are not specified
at this stage.
2. CBR refresh is the only standardized
method of refreshing non–synchronous
DRAMs with densities of 256Mb and
higher.
3. The standard refresh interval (tREF) for
256Mb DRAMs is 64ms. (7.8 s per row
with 8K rows, 3.9 s with 16K rows.
4. (NC, VREF) is VREF on devices that
require an external voltage reference.
5. The VDDQ designator is used when the
power supply pins for the DQ I/O drivers
are internally dc isolated from the other
VDD power supply pins.
6. The VSSQ designator is used when the
ground reference pins for the DQ I/O
drivers are internally isolated from the
primary ground references (VSS)
Let me know if you find some memory manufactuter data sheets which specify the tref for winbond bh5
(ex, I think this is BH5.. http://www.valueram.com/datasheets/KHX3200UL_512.pdf)
4.1.1.8 tREF (Refresh Rate)
The tREF is not an SPD ROM parameter but a field that the DRAM controller requires and that can
be obtained from several bytes in the SPD ROM. Typically, the entire DRAM must have every row
refreshed at least once every 64 ms. The average time between two row refreshes is thus based on the
number of rows in the DRAM and the clock frequency.
The clock frequency was previously derived. The number of rows in the implementation can be read
from SPD byte 3. This provides the number of row address bits for each of the two possible chip
selects on a DIMM. (Note that each chip-select range of a two chip-select DIMM uses devices that
have the same number of rows). A design with 12 row address bits implies 4k rows per internal
device chip select. This maps to a refresh every 15.6 µs on average. There are also 8k (13 row address
bits) and 16k (14 row address bits) row devices. By knowing the number of rows and the frequency,
the DRAM controller configuration register can be correctly programmed. All 4k row devices require
an average refresh interval of 15.6 µs and all 8k and 16k row devices require a 7.8 µs average refresh
interval
But I am still confused because RightMark Memory Analyzer, reads spd at "7.8us self-refresh", but Sandra shows refresh rate as 5.0us.. A64 tweaker reflects what states in the BIOS.. aka 200Mhz 15.6us.
Im lost
I'm right behind you, everest says 7.8 refresh, but A64 is giving me 200mhz 3.9us, I don't know where to find SPD in Sandra though.
Pulled up a datasheet for Micron 5B-D
http://download.micron.com/pdf/datas...DDRx4x8x16.pdf
Says 5us at DDR400 if I am reading this correctly
More here:
The addressing is generated by the internal refresh controller. This makes the address
bits a “Don’t Care” during an AUTO REFRESH command. The 512Mb DDR SDRAM
requires AUTO REFRESH cycles at an average interval of 7.8125μs (MAX).
I dont believe I had 512Mb chips because, they are double sided, 2x512MB kit. 16 chips for 512MB, means 256Mb (I think all Winbond BH5 is 256Mb or lower).
As for Sandra, you need to check under "Motherboard Information".
I'm glad I'm not the only one getting totally different tref values reported by different programs ;)
Sandra says 5.00Quote:
Originally Posted by ***Deimos***
Maybe sandra is just wrong?:confused:
how about UCCC? Does anyone know the opimum refresh rate for all of these great Gskill PC4000HZ 2GB kits we're buying? I have mine set at 3684 for no other reason that that is what i've seen a few others use... my cpu does 285 without any problems, so im trying to get these sticks to catch up, and I cant get 32m stable to save my life above 270! ... DOH!
and wth does this mean in Everest?: "Refresh Rate: Reduced (7.8 us), Self-Refresh"
when A64Tweaker shows: 100mhz 1.95us*
These inconsistencies is what we are trying to figure out.
When I first started reading this thread, I thought that perhaps this TREF would be th wholy grail that would give me an extra 5Mhz. (like what burn-in failed to do).
Alas, all indications I've seen point to that TREF has negligible impact on performance, and unless incorrectly set to begin with, would not improve overclockability.
for example: if manufactuter requires refresh every 100s, and you have it set to 120s, then you'll obviously have errors. But, you might get away with 105s without errors, and any more frequent would be redundant. Applying this example to clock cycles, if default is 100 clk, higher like 120 clks would probably give errors, and lower would be redundant. Since the RC delay is not very clockspeed dependent, the faster you clock your RAM, for any given #clk refresh rate, the faster it refreshes, so unless TREF is set incorrectly to begin with it should not be a factor in overclockability.
Then why do people claim certain settings give them higher bandwidth? And how would I be able to find the exact clks my memory uses :)
I ususally just test all the tref settings and whichever one gives me the least errors, I leave it at that.
Errors with what test? I have found that errors in memtest seem to be random with me, such as if I get 4 errors with a certain setting and restart, I will get more or less than the first time
tests 5 and 8, 1 run with 5, then 1 run with 8, both sets of data will help u determine the best tref. (btw, best tref to me is the one that errors the least, not the tightest timing one)Quote:
Originally Posted by MikalCarbine
Any if you have no errors in either test? Set it to something so it does?
yeah, you'll have to ramp up your fsb until u get a managable amt of errors, like go up 1 fsb until u can get like 20 or so errors, just enuff so you can tell the diff. u don't want it erroring out 20,000 times, hard to tell what is working better then.Quote:
Originally Posted by MikalCarbine
Well, my theory is the following:
Basically we can group all tref values to 4 groups (see image). The problem is, that the values of the 4th group are almost the same as the ones from the first group, so I made both of them to 15.6 uS.
As we know, the CPU stores the delay time in two bits:
00b => 15.6uS
01b => 7.8uS
10b => 3.9uS
11b is undocumented
We have 4 groups of tref values, so it's obvious, that they mean 00b, 01b, 10b, 11b
However, it would be logical, that 11b should mean 1.95uS, but DFI has 15.6uS at this place. this means, that either the undocumented 11b means 15.6uS, or DFI has made a mistake, when interpreting tref values.
The odd values 0016, 0032, 0064 and 0128 clearly stand out, and I believe, that they are a mistake in the DFI BIOS.
2) There are also values for 233, 266 and 300 MHz MEMCLK in the BIOS, so we get our 4 groups(the formula you can check is basically A/B = C)
3) 1032 and 2064 are represented multiple times, but it's no wonder, because the tref period for 133MHz 15,6uS and 266MHz 7,8uS are Identical ;)
4) This table does not eliminate testing, but once you have substantially checked your RAMs tref, you can look it up in the table, and if you change your MEMCLK you don't have to test it again.
5) I am still waiting for a prog, that reads the CPU registers correctly (bitwise), one may help me...:)
http://img156.imageshack.us/img156/2423/tref0fh.gif
As with other timing parameters, TREF does have a small impact on bandwidth. DRAM is not always accessing and must periodically refresh the rows...
now, ~60ms might not seem like much, but for DDR SDRAM running at 200,000,000 cycles per sec, its a lot, and thus even if your refreshes are twice as frequent as necessary the performance/bandwidth impact will be minimal (then again, even tRAS has small impact).
Although I'm no expert and base this mostly from the Athlon64 manual, I don't think fsb/htt has anything to do with TREF, since the DRAM controller is on the CPU, and not connected to the HTT. MEMCLK is derived my dividing the CPU frequency by multiplier for corresponding "ratio". Ofcourse, raising HTT does raise CPU speed, and for some ratio, the MEMCLK, but its not direct relationship (just coincidence, not correlation). That is why TREF values are specified as "200Mhz, 7.8us" : the DRAM frequency and refresh interval for the corresponding DRAM density
(PS: with "183" ratio, and 9x CPU, MEMCLK is CPU/10)
In case somebody missed the AMD quotes, in general:
(these are typical, but really depend on the row size, and manufacturer stores correct TREF in the SPDROM)
CHIP SIZE IN BITS_______us
128Mb 15.6us
256Mb, 512Mb 7.8us
1024Mb 3.9us
If you have a single sided DIMM (ex 8 chips), then 8x128Mb = 128MB
If you have double sided DIMM (ex 16 chips), then 16x128Mb = 256MB
Lets say I'm overclocking and optimize TREF (in DFI bios where its in clock cycles), to be the maximum allowable. Lets say I have 200Mhz DDR SDRAM with nominal TREF 7.8us (1560 clks). If I overclock, say to 233Mhz, I'm still fine, because now refresh interval is less than 7.8us. But, I can get a bit more performance by increasing the TREF slightly (1816 = 7.8us a@ 233Mhz) Lets assume row refresh takes 10 clks.
Using 1560 setting, the DRAM is NOT accessible for 10/1570 = 0.00636 (0.6% of the time)
using the better TREF its 10/1826 = 0.00548. If during that extra time the memory is being fully utilized, thats about 0.636-0.548 = 0.088% bandwidth improvement!! (dont y'll gasp at once)
http://www.winbond.com/s-winbondhtm/....asp?Pname=918
Can somebody confirm if this is the "BH5" datasheet.. and if not, does anyone have link or post attachment with it.
Great information guys! I'm trying to find the best tRef value for my 1GB sticks of G. Skill PC4000 HZ and i'm running it on a 166 divider. I looked at a couple of the charts and i'm thinking maybe i should try 0648? I'm guessing that 1024MB DiMMs are 3.9us and since i'm using a 166 divider 0648 would be closest to the right value. By default my DFI NF4 board uses 3120 since that is 15.6us and 200MHz divider. Alot of people are recommending the 3684 tRef for my RAM but thats 15.6us and 233MHz and that doesn't make sense to me. I dont get why this has to be so difficult and why there isn't an accurate way to calculate it outside of just randomly testing numbers to see what works.
Try 4708, 166mhz, 1.95μs.Quote:
Originally Posted by burningrave101
3684 also worked very well for me. Running HZ too.