Tref values

[amrgb]

How do you define "best" ?

Like in best performance eg. more bandwidth ?

Or more stability ?

When I said best I meant more stable. I test for stability with Superpi 32M runs. Those 2 Trefs where the ones who gave no errors on this test. The others (I've not tested all possibilities yet, but tried 2xxx Trefs) gave me errors after loop 7, 18, etc.

After completing one Superpi 32M run, I test 2x32M, 1x16M and 1x8M superpi runs simultaneously to test the seting's stability further.

Memtest is out of the question. My results with memtest are meaningless.

PS: your problem may be your cpu memcontroller. At night I can run Superpi32M @ 291. During the day, with hotter temps, I can't.

EDIT: everest reports a 7.8us. It can be wrong, but it seems that almost all 512MB modules have 7.8us refresh rates.

[amrgb]

I must confess that this Tref thing had always intrigued me. Especially the correspondence between the Tref value and the xxxMhz y.yyus in the A64 Tweaker.

Today suddenly one comment from flexy gave me an idea.

Wonder if those values are just plain wrong.

What if the A64 Tweaker correspondence is also completely wrong? As far as I know, know one knows how those correspondences were made (is the A64 tweaker's author around here to give us an explanation?).

I've carefully analised the Tref values available at the DFI NF4 bios and excluding the odd values 0016, 0032, 0064 and 0128, I can clearly see 4 (not 8) groups of settings.

Tref* | Dif to previous Tref | refresh time x fsb (Tref formula) *(in order of appearance in the DFI NF4 BIOS)

Group 1
1552 --- 15.57x100 = 1557
2064 512 15.57x133.(3) = 2075
2592 528 15.57x166.(6) = 2594
3120 528 15.57x200 = 3113
3632 512 15.57x233.(3) = 3632
4128 496 15.57x266.(6) = 4151
4672 544 15.57x300 = 4670
0032 ---

Group 2
0776 --- 7.78x100 = 778
1032 256 7.78x133.(3) = 1038
1296 264 7.78x166.(6) = 1297
1560 264 7.78x200 = 1557
1816 256 7.78x233.(3) = 1816
2064 248 7.78x266.(6) = 2075
2336 272 7.78x300 = 2335
0032 ---

Group 3
0388 --- 3.89x100 = 389
0516 128 3.89x133.(3) = 519
0648 132 3.89x166.(6) = 649
0780 132 3.89x200 = 778
0908 128 3.89x233.(3) = 908
1032 124 3.89x266.(6) = 1038
1168 136 3.89x300 = 1167
0016 ---

Group 4
1536 --- 15.69x100 = 1569
2048 512 15.69x133.(3) = 2092
2560 512 15.69x166.(6) = 2616
3072 512 15.69x200 = 3139
3684 612 15.69x233.(3) = 3662
4196 512 15.69x266.(6) = 4185
4708 512 15.69x300 = 4708
0128 ---

Each group has 7 (not 4) entries from 100Mhz to 300Mhz (not 200). Under the assumption that the Tref=refresh time x fsb formula holds (and from what I know at this moment I believe it does),then we have the following relations:
- group 1: 15.6us
- group 2: 7.8us
- group 3: 3.9us
- group 4: 15.6us (again)

The refresh times implied by each group were found minimizing the mean absolute difference between the Tref value and the value given by the formula.

Group 4 is weird, because if the difference between were always 512 (only one exception to this), the implied refresh rate would be either 15.36 or 15.69.

What do you think about that?

[blackjok3r]

hmmm, interesting...I wonder what all this means exactly. amrgb, those are some good findings there, at least we know there is only 4 diffrrent refresh rates now, and not eight of them.

To find if the refresh period, changes with clock frequency, we need to try all values at stock (DDR400) to see, which one is the most stable, to find the optimal refresh if our ram. Then we need to use the formula to calculate the tref that wil give that refresh period for say DDR500, And test all values again. Then we can see if the refresh period changes, as the speed increases. I dont really have time to do this as I have exams next week, so I hope someone can check this out for me. If no one does then I will test in 2 weeks.

[AMDnewbie]

2336 works for me for 300Mhz tccd here....
other values will pop out errors at memtest #8 maybe after 10 loops or lesser
with 2336 I can go 50 loops without errors...superpi 32M is passable too...

keep up the works ...guy

[Agent-Sharp]

Hello,

I am Sharp from the DFi forums, Someone has taken my name here
Agent-Sharp is my alternative.

I have some questions too about the tREF values.
Since having my DFI board I have questioned the original tREF table post #46.
The values do not make any sense and it would be really good if the person that made it could explain it.

And the values shown in A64 Tweaker are odd too.

My favourite memory benchmark utility has helped a bit but still the program is not 100% accurate.

RMMA - Rightmark memory analyser.
This program will show you the refresh rate.

Using RMMA I have tested some of the values in the BIOS and they do match the calculation but there are a few unexpected results.

http://cpu.rightmark.org/download.shtml

Here are my findings so far. (I have screenshots if anyone wants too see but try it for yourself too.)

RMMA Results, (Anyone not understand this?)
==============BIOS==RMMA==========
5ns/200Mhz.........3120 = 15.6...cal confirms
5ns/200Mhz.........1560 = 7.8....cal confirms
5ns/200Mhz.........780 = 3.9.....cal confirms
5ns/200Mhz.........388 = 3.9.....expected 1.95
5ns/200Mhz.........016 = 3.9.....expected 0.08

10ns/100Mhz........3120 = 15.6...weird
10ns/100Mhz........1560 = 7.8....weird
10ns/100Mhz........780 = 3.9.....weird

7.5ns/133Mhz.......2064 = 15.6...cal confirms***
7.5ns/133Mhz.......1032 = 7.8....cal confirms
7.5ns/133Mhz.......516 = 3.9.....cal confirms

6ns/166Mhz.........2592 = 15.6...cal confirms
6ns/166Mhz.........1296 = 7.8....cal confirms
6ns/166Mhz.........648 = 3.9.....cal confirms


***Notice there are 2 2064 values in the BIOS.

Top one was used above and it came out as expected.
When I used the bottom 2064 value it came out wrong.

Bottom 2064 x 7.5ns/133Mhz = 7.8us?

END=======================

What I have to say about RMMA.
- The program does not seem to display actual values and it rounds to either 3.9/7.8/15.6

- Using 200Mhz/5ns and max tREF cycles in the BIOS RMMA displayed N/A
- Using 200Mhz/5ns and 0016 RMMA displayed 3.9us.
- And it did not work for 100Mhz.

So it is hard to measure all the values but (big but), when changing the frequency and using calculated values for 3.9/7.8/15.6 RMMA always confirmed the results.

I am still not happy with the results but it is much closer than anything else that I have seen.

Also I would have tested over 200Mhz but my power supply will not allow me to OC. (20pin).

RMMA did not work for 100Mhz so will it work for anything over 200Mhz?


Maybe someone can contact RMMA and ask about all of this?


I would be grateful if everyone (as many as possible) could test this with RMMA (confirm my results and go beyond) as I may have made some mistakes.

Also I would like say thanks to everyone for sharing their results/findings.

[Jimbo Mahoney]

Hey Sharp!

Good to see you!

Thanks for giving me the spark to investigate all this Tref stuff!

Thanks for those RMMA tests! Interesting...

[EMC2]

Here's a little info from the CPU side of the Tref picture...

Tref is controlled by 5 bits in one of the memory configuration registers of the A64. There are 4 "stock" refresh values, 1.95uS, 3.9us, 7.8us, and 15.6us. There are 8 MemClock frequency settings (based on a 200Mhz FSB) ranging from 100Mhz to 200mhz (you can see this in the divider ratios of the DFI BIOS).

What you get is a table that looks like that shown below, with values that don't correlate to the Tref settings in the BIOS... other than there are 4 groups of 8



Peace

[AMD-me]

gah this stuff is so mind boggling lol

I just used the guys calculator, it worked too 4128 is best for ddr500-ddr490 :cheers:

[dexx]

How do we know that the memory refresh rate is 7.8ns (or whatever)?
Isnt this just the value which would apply if you are running your sticks at SPD (eg 200MHz 2.5-3-3-8)? Would this value vary depending on your MHz and timings?

[Bugs]

lo peeps,
well I´ve been playing with tref for some time
have a DFI nF4 and 2 x 256 KHX (BH-5)
So far Tref=3120 seems to be the best value (wich is the default value for the auto option)
I´ve calculated theorical Trefs with this datasheet from Kingston (that may help ppl with 2x256MB BH-5 modules) and theory ain´t help or our formulas may be wrong.
Anyway 270 MHz is the max for #5 memtest error free so far with 3,7V.
I´ll keep testing Trefs, anyway 275 MHz is SuperPi 32M error free.
I´ll post a64tweaker screen later when I get home.
Edit: Last BIOS ain´t help me climbing HTT either, can´t remember wich BIOS I´m using atm but I know it´s an old one, last BIOSes like 5.x-x didn´t help, and I´m using orange slots.
Greetings

[astaris]

Here's a little info from the CPU side of the Tref picture...

EMC2 where you got that table? From the Amd Tech Doc we have only the values of the Tref register field for 15.6us, 7.8us and 3.9us:
00000b = 100 MHz 15.6us
00001b = 133 MHz 15.6us
00010b = 166 MHz 15.6us
00011b = 200 MHz 15.6us
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
Moreover some settings have the same Tref in memclocks cycle, i.e. 200 MHz 7.8us and 100 MHz 15.6us are 1560 clock cycles. Why two different values of the tref register (01011 and 00000) if the clocks are the same? Maybe Tref is derived not from the memory clock, but from the cpu clock?

[flexy]

this whole issue is still a mystery.

Because all the values in tables etc. which look they would be ideal dont work for me.

I found that 4708 actually works best (most stable)...which is actually weird since this is the highest value and i assuem means the refresh happens LEAST often.

Factors to consider:

MAYBE its really the case that a LOWER Tref value indeed would refresh the sticks more often...THUS implying more stability.....but THEN at the same time generates more heat (because of the more refreshes)....BUT THEN also again generates instabilty because of more heat

TO TEST:

Whether a lower TREF would be more stable with LESS voltage..or a instable setting at LOWER VDimm voltage can get more stable with a lower TREF.

[EMC2]

How do we know that the memory refresh rate is 7.8ns (or whatever)?
Isnt this just the value which would apply if you are running your sticks at SPD (eg 200MHz 2.5-3-3-8)? Would this value vary depending on your MHz and timings?

The needed (approximate) refresh rate depends on the chips themselves. It is determined by how many rows are in the chips... easiest way to tell (other than data sheets) is to set the timings to "default" and look in the advanced settings of memtest to see what it's set to (advanced timings option of memtest)... or use everest, sandra, etc. and see what it says in the SPD.

The refresh rate should stay the same regardless of the frequency you are running at (for example 15.6uS no matter what). Too high a refresh rate causes the chips to use more power, get hotter and thus slow down, and also generate more noise limiting your FSB. Too slow a refresh rate and data can be "forgotten" by the chips (it gets corrupted actually).

Maybe Tref is derived not from the memory clock, but from the cpu clock?

Why else would they have dif reg settings with the same MemClock count. There are distinct patterns in the reg settings too

Peace

[dexx]

The needed (approximate) refresh rate depends on the chips themselves. It is determined by how many rows are in the chips... easiest way to tell (other than data sheets) is to set the timings to "default" and look in the advanced settings of memtest to see what it's set to (advanced timings option of memtest)... or use everest, sandra, etc. and see what it says in the SPD.

But wouldnt this (eg 7.8ns) only be applicable at SPD eg at 200MHz. How do we know that it isnt 5.6ns at 300MHz?

[EMC2]

But wouldnt this (eg 7.8ns) only be applicable at SPD eg at 200MHz. How do we know that it isnt 5.6ns at 300MHz?

The refresh rate needed isn't based on the frequency you're running at

DRAM cells (individual bits in the memory) use a capacitor to "remember" the data (specifically to remember 1's... discharged capacitors are 0's). There is leakage in the cells and over time the capacitor "slowly" looses it's charge if it isn't refreshed... and the data gets corrupted (changes). During a refresh cycle, the data is read out of the memory cells and then written back... renewing the charge on the individual cells' capacitors.

Peace

[astaris]

Why else would they have dif reg settings with the same MemClock count. There are distinct patterns in the reg settings too

Well i see the patterns:
Bits 12-11 -> Refresh cycle in us
Bits 10-8 -> Frequency with the same pattern of DRAM MEMCLK Frequency field of DRAM Configuration High Register
But atm i'm not able to figure a correspondence between these settings and the Tref values in DFI bios that i think are realy messed up.

[astaris]

Well i posted this over Dfi-Street, lemme know your opinions:

1) How Tref works
Tref is selected through the Tref field in DRAM Timing High Register of the Athlon 64. This field is made of 5 bits, so we have 32 Tref values. When we select a Tref in Dfi bios, that value is stored in this Cpu Register.
From the Amd Tech Doc:

These bits (the bits in the Tref field) are encoded as follows:
00000b = 100 MHz 15.6us
00001b = 133 MHz 15.6us
00010b = 166 MHz 15.6us
00011b = 200 MHz 15.6us
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

Each setting translates in MemClock cycles between two Refresh Command, i.e. 100 MHz 15.6us is 1560 Clock Cycles, 200 MHz 3.9us is 780 Clock cycles....
Now the values in the DFI bios that set these Tref are the following:
15.6 us
1552= 100mhz
2064= 133mhz
2592= 166mhz
3120= 200mhz
7.8 us
0776= 100mhz
1032= 133mhz
1296= 166mhz
1560= 200mhz
3.9 us
0388= 100mhz
0516= 133mhz
0648= 166mhz
0780= 200mhz
Well we have covered only 12 values. There are still 20 values of the Cpu register that are undocumented. We can deduce these values by analyzing the way the Tref Bits are encoded. The Tref Field can be splitted in two subfileds:
1st subfiled is made of Bits 4-3 and set the Tref cycle in us:
00 -> 15.6 us
01 -> 7.8 us
10 -> 3.9 us
11 -> ?
Well 11 is undocumented but you see the pattern right? so we have (maybe)
11 -> 1.95 us
2nd subfield is made of Bits 2-0 and set the frequency at which the Tref is given:
000 -> 100 Mhz
001 -> 133 Mhz
010 -> 166 Mhz
011 -> 200 Mhz
The other settings are undocumented, but we can deduce their values through the DRAM MEMCLK Frequency field (i.e. the memory divider) of the DRAM Configuration High Register. On Dfi we have:
100 -> 120 Mhz
101 -> 140 Mhz
110 -> 150 Mhz
111 -> 180 Mhz
So we have 4 Groups of Tref (15.6, 7.8, 3.9, 1.95 us) each made of 8 different entries for 8 different frequency values (100, 120, 133,...200 Mhz). But we don't have the correspondents Tref in Dfi Bios, i.e 15.6 us 120 Mhz is 1872 Clock Cycles that can't be chosen from the bios, why?....
2) All the Tref values in the bios that set an undocumented refresh cycle, don't reflect the real refresh cycles in memory clocks because are derived by an incorrect interpretation of the Tref field:
Bits 4-3
11 - > 15.36 us
Bits 2-0
100 -> 233 Mhz
101 -> 266 Mhz
110 -> 300 Mhz
111 -> this value is not translated in Mem Frequency and generates the odds values 16, 32, 64 and 128.
Now we can find the real correspondence between the Tref value in the Dfi Bios and the Tref in the Cpu register:
New Dfi Tref Table
15.6 us
1552= 100mhz
2064= 133mhz
2592= 166mhz
3120= 200mhz
7.8 us
0776= 100mhz
1032= 133mhz
1296= 166mhz
1560= 200mhz
3.9 us
0388= 100mhz
0516= 133mhz
0648= 166mhz
0780= 200mhz
1,95 us
1536= 100mhz -> 195 Mem Clock cycles
2048= 133mhz -> 259
2560= 166mhz -> 324
3072= 200mhz -> 390
15.6 us
3632= 120mhz -> 1872
4128= 140mhz -> 2184
4672= 150mhz -> 2340
0064= 180mhz -> 2808
7.8 us
1816= 120mhz -> 936
2064= 140mhz -> 1092
2336= 150mhz -> 1170
0032= 180mhz -> 1404
3.9 us
0908= 120mhz -> 468
1032= 140mhz -> 546
1168= 150mhz -> 585
0016= 180mhz -> 702
1.95 us
3684= 120mhz -> 234
4196= 140mhz -> 273
4708= 150mhz -> 292
0128= 180mhz -> 351
3) How Athlon 64 Tweaker reads Tref:
This great prog don't read the value stored in the bios, but the setting stored in the Cpu register in this way:
Bits 4-2
100 -> 15.6 us
101 -> 7.8 us
110 -> 3.9 us
111 -> 1.95 us
All other values -> (?) us
Bits 1-0
00 -> 100 Mhz
01 -> 133 Mhz
10 -> 166 Mhz
11 -> 200 Mhz
So a 100 Mhz value can be 100 or 120 Mhz, a 200 Mhz value can be 180 or 200 Mhz...
Through the incorrect Tweaker report and the Amd Tech Doc i was able to build the new Tref Table for Dfi. I'm still not sure if 11 in bits 4-3 is really 1.95 us (i.e reduced refresh period) or maybe 31.2 us (i.e. extended refresh period), but i think all the other values on the table are correct.

[amrgb]

Nice investigation.

But I got lost somewhere when you say that for instance 100 -> 120 Mhz and not 100 -> 233 Mhz. How can you be so sure of this?

If I understood it right the 3632 Tref setting is in fact a 1872 value (3632= 120mhz -> 1872) and it's the bios who label it wrongly. Is that what you mean? I can't see why will they label it in this way.

(If I got it right) According to you theory, the Tref of 0064 is in fact 2808. How can you explain the fact that this setting is extremely slow and even freezes several people's systems?

[astaris]

But I got lost somewhere when you say that for instance 100 -> 120 Mhz and not 100 -> 233 Mhz. How can you be so sure of this?

Well if you set 100 on the DRAM MEMCLK Frequency field you get the 120 Mhz Mem Divider. Now if you want a 15.6 us Refresh rate when you run this divider, you need a 15.6 us 120 Mhz refresh rate. So if the Cpu Memory controller has the 120 Mhz Mem Divider option, a 15.6 us 120 Mhz Tref setting must be present. On the Athlon 64 the DRAM MEMCLK Frequency can be programmed in order to have lower divider than 1:1, but in this case we have:
100 -> 216 Mhz
101 -> 233 Mhz
110 -> 250 Mhz
So 100 can be 120 Mhz or 216 Mhz. Anyway on the DFI you cannot choose these dividers, so 100 has to be 120 Mhz.

If I understood it right the 3632 Tref setting is in fact a 1872 value (3632= 120mhz -> 1872) and it's the bios who label it wrongly. Is that what you mean? I can't see why will they label it in this way.

They label it wrongly cause they assumed 100 = 233 Mhz, but i'm pretty sure that 100 = 120 Mhz.

(If I got it right) According to you theory, the Tref of 0064 is in fact 2808. How can you explain the fact that this setting is extremely slow and even freezes several people's systems?

Well i don't know why on the bios you have these odd settings, 16, 32, 64 and 128. But i'm sure that:
16 -> 10111
32 -> 01111
64 -> 00111
128 -> 11111
Now these settings are all undocumented and maybe for these values of the Tref register we have different refresh rates, but hey here i made some hypothesis and there's no way to test the real refresh values.

[amrgb]

...there's no way to test the real refresh values.

Actually there is a way to test if your theory is on the right track or not. In theory a slower Tref will heat up memory modules.

Let's pick the 2064 (15.6 100Mz) and the 4708/292 (1.95 150Mhz). If your right when changing from 2064 to 4708 we should observe a rise in the ram temperature. If the DFI values are right, we should observe the opposite. It's just a question of testing it.

For me it's hard to believe that DFI got it wrong, but definitely this Tref thing is weird. So I'm open to new theories. And you might have one hell of a theory if can be backed up by this temp testing (or another test one can remember of).

[astaris]

What I have to say about RMMA.
- The program does not seem to display actual values and it rounds to either 3.9/7.8/15.6
- Using 200Mhz/5ns and max tREF cycles in the BIOS RMMA displayed N/A
- Using 200Mhz/5ns and 0016 RMMA displayed 3.9us.
- And it did not work for 100Mhz.

I think RMMA reads the Bits 4-3 of Tref register and then converts these bits in us:
00 -> 15.6us
01 -> 7.8 us
10 -> 3.9 us
11 -> N/A
If you see my table (still under construction) you'll notice that 388 and 16 are under the 3.9 us group so i'm agree with your RMMA results.
I think that if you try a xx us value RMMA will display xx us no matters what divider you set.
The max Tref Cycle (4708) has the bits 4-3 = 11, for this reason RMMA shows N/A.
Moreover the bottom 2064 value is 01101 and then is taken by RMMA as a 7.8 us value.

[burningrave101]

We still get the correct tREF setting though by taking the refresh rate (7.8us) times the speed of the memory modules correct guys?

Or do we select the tREF value based on the MEMCLCK frequency divider were using like 200, 180, 166?

I hope someone figures this out soon so we can just have a simple table to look at instead of having to read the logics behind it all lol.

[felinusz]

The foolproof way to find the best tREF, is to go through every single value, testing for changes to stability with memtest86 after each change.

Keep notes, run memtest for ~10 loops of test #5 per change, and keep the value that

~ Doesn't adversely affect bandwidth
~ Runs most stable

This will take you an entire afternoon. BUT, it will get you an ideal tREF value.


Alternatively, I am very interested in seeing someone hook a highly-accurate temperature sensor up to their memory IC's, and see how different tREF values affect peak load memory IC temperatures. This would of course involve a very stable ambient temperature, and a sufficiently lengthy time period to get the chips to a consistant peak temperature.

[uwackme]

Its my understanding the Tref count works off the MEMCLK signal that is 200Mhz for us running 1:1. And it counts out for 7.8us refresh for 512M sticks. So 1560 @ 200Mhz 1:1 MEMCLK is the correct setting. In other words the FSB clock is not relavent to this discussion, the refresh period is not based off of it. Refresh happens at a fix rate in time, how fast the RAM is actually being accessed isnt involved in the capacitor refreshing function.

The only thing that matters is how big is the stick, and what its rated refresh requirement is. Most 512M sticks are 7.8us, which off the 200Mhz MEMCLK setting is achieved with a 1560 setting for Tref. 7.8us would be something else for one of the dividers....say 180 (9/10), etc. I also believe that refresh occurs on a PER DIMM basis, so it doesnt matter if you have 1 or 2 or 4 DIMMs populated, each has its own refresh access happening in parallel. The only # that matters is the single stick refresh spec of the module.... 7.8us for most 512M sticks.

Funkyness will occur mixing 256M sticks with 3.9us requirement with 512M sticks with 7.8us....since the A64 controller isnt designed to support seperate settings PER DIMM. The only PER DIMM setting I know of is the MEMCLK enable function (accessible in A64 tweaker)....something Oskar should add to the bios for folks using only 2 sticks....shut off the unused DIMMs clocks for higher OC in some instances.

[13oost]

i found so far that 7.8xMemory frequency, helps me most...

i havent really ventured outside that to aweful far