Noob question, but how does the tref value in bios work out to the value's in A64 tweaker, ie if I wanted to use 133- 7.8us what value would that be in bios.
thanks Jeff
Printable View
Noob question, but how does the tref value in bios work out to the value's in A64 tweaker, ie if I wanted to use 133- 7.8us what value would that be in bios.
thanks Jeff
Do a search there is a post in this forum somewhere with the values listed for your board I believe. Every board is different though.
thanks for that, thought there was some sort of mathamaticial equation for it :stick:Quote:
Originally Posted by c42
133 @ 7.8µs is 1032 in bios it seems, for you migth be relying on a similar document as mine which raises a doubt about what the real value is. I will look in my bios and report back.Quote:
Originally Posted by jiff
here is somewhat of an incomplete list of all possible values...
1552= 100mhz(?.?us)
2064= 133mhz(?.?us)
2592= 166mhz(?.?us)
3120= 200mhz(?.?us
---------------------
3632= 100mhz(?.?us)
4128= 133mhz(?.?us)
4672= 166mhz(?.?us)
0064= 200mhz(?.?us)
---------------------
0776= 100mhz(?.?us)
1032= 133mhz(?.?us)<---?
1296= 166mhz(?.?us)
1560= 200mhz(?.?us)
---------------------
1816= 100mhz(?.?us)
2064= 133mhz(?.?us)
2336= 166mhz(?.?us)
0032= 200mhz(?.?us)
---------------------
0388= 100mhz(15.6us)
0516= 133mhz(15.6us)
0648= 166mhz(15.6us)
0780= 200mhz(15.6us)
---------------------
0908= 100mhz(7.8us)
1032= 133mhz(7.8us)<------?
1168= 166mhz(7.8us)
0016= 200mhz(7.8us)
---------------------
1536= 100mhz(3.9us)
2048= 133mhz(3.9us)
2560= 166mhz(3.9us)
3072= 200mhz(3.9us)
---------------------
3684= 100mhz(1.95us)
4196= 133mhz(1.95us)
4708= 166mhz(1.95us)
0128= 200mhz(1.95us)
courtesy of Jess1313 at Overclockers forum.
Edit:
interesting, this was probably a trick question, for as indicated in the chart I am providing here, a DFI bios (nf4 in my case), also shows the same conflict of information.
That is, the same 1032 value being used in 2 banks of different µs timing. I dunno the answer to this one!
1168 should take your VX high and stable. But other ones works also.
4672....best performance for BH5/BH6/UTT. :)
Can someone show me how to calcalate a tref if I set my FSB to a certain value in the BIOS, what formula shoud I use to calcalate the correct value so my system won't crash, reboots or freezes? According to Everest, my default Memory Refresh Rate is (Reduced 7.8us - Self-timered) or something like that.
Thanks in advance...
I am also totally confused about this. I mean it is almost impossible to make a logical or an intellegent choice when you are trying these. They are not in any kind of order, and I don't have a clue, which one is tighter or more loose.
I'd also like to know if this is possible....because if for no other reason then straight-out stability I'd like to know the optimal tref value for any of my given htt speeds I might be hitting...cus I actually went through at stock clocks, and even at lower memory speeds, some tref values will not boot into windows....I'd find it very usefull to see which relate to which clock speeds more appropriately.Quote:
Originally Posted by jcniest5
Check this thread out. ..
I was just reading it the other day.. But unfortunatly im no math wiz and it looks like a different language to me..hehe..
refresh time = time in us, so for example 15.6us = 1.56E-5
FSB = megahertz so say 300Mhz = 3E08
Reftime / 1/FSB = Tref(cycles) OR cycles = FSB x reftime so for example 3E08 * 1.56 E-5 = 4680
:shrug: :confused: (hmm close but not real obvious yet)
So try this: TREF / reftime = FSB or 4708 / 15.6us = 302Mhz FSB
Interestingly enough, 4672 is a bit closer to 4680 and FSB = 299.5 based on the previous discussion
Just for grins I carried this out to it's logical conclusion and made up a table of FSB vs TREF :fact:
I stopped putting down the useless values after a few lines and left out the ridiculously small values.
TREF 15.6 7.8 3.9 1.95
FSB values for a TREF value
1552 99.5 199 398 796
2064 132 265 529 1058
2592 166 332 665 1329
3120 200 400 800 1600
3632 233 466 931 1863
4128 265 529 1058
4672 299.5 599
1032 66 132 265
1296 83 166 332
1560 100 200 400
1816 116 233 466
2336 150 299.5 599
1168 75 150 299.5
1536 98.5 197 394
2048 131 263 525
2560 164 328 656
3072 197 394
3684 236 472
4196 269 538
4708 302
Maybe this may help, everyone report if this helps
Now off to see if this has any connection w/ reality :shrug:
I'm still a little confused. So, I have to choose a TREF that is equal or very close to what my FSB (HTT) frequency is, correct?
For example, if my HTT/FSB is at 260, I would have to find a value of TREF that is closest to the 260 I set. Or else, my system wouldn't be stable, is this correct or not? :confused:
im so lost, someone come up with a clear table please, all those number lost me as their is no columns or labels or anything :(:(:(
133 MHz 7.8us = in bios = 4128
Just trying out my table, tried 2336 (see my table above, = 299.5 FSB @ 7.8) and running memtest on 300x9 2.5-3-3-6 @ 2.65 Vdimm (will pass test 5 no problem, (runs and checks again in 'da lab' ) looks like test 8 also :D ) Would never have gotten that value from anywhere else. And since the CPU fan is temp controlled on the test bench, get audible indication of what stresses teh CPU more. (This seems to not stress it as much when you 'get it right'. :D ) Also if you can a slightly less FSB value seems to work better than a value that is higher than the target FSB..
All the exponents cancel out after all is said and done so just take a TREF value (cycles) and divide by the 'offical' :fact: refresh rates (15.6, 7.8, etc) which is how I got my table. Seems like 7.8 is a good value so far :hrhr: . That is how I got teh table above. It is also helping me to get 250x11 @ 3.27vdimm(PITA since there is nothing in the table between 236 and 263 FSB so its a crap shoot), will find out if all this helps vcore also later today.
Oh well, back to testing! :banana:
P.S. Read up on the GSkill 3200 thread, Agent-JC gave me the other part of the equation for fiddling w/ drive strengths. :clap: :toast:
@WSP: use space a column marker, or grab it and dump it into a .txt doc and tab it out (sorry no table software on this machine) make improve your settings :D
anybody got any more info on how to set my tref accordingly? i would think this would be highly researched as it can have a HUGE impact on bandwidth.
Im sure someone in the programming/coding forum can come up with a simple GUI proggie to convert the values. Try posting in there. :toast:
What was posted in that other forum seems to make sense. Basically tRef is the number of clockcycles between each refresh of the RAM banks. Now RAM has a certain ideal refresh time, but this is an absolute time not a clockspeed. So basically you need to set tRef so the number of clock ticks between refreshes will correspond to the amount of absolute time you need between refreshes.
In order to do this, you need to know how long one clock tick is, but that's easy it's just 1s/clockspeed. Then you take the RAMs ideal refresh time in seconds, and divide by the time per clock tick to get the number of clocks you need to wait. Then just pick a tRef that corresponds to this (i.e. closest without going over).
I would also guess that due to potential instability, RAM might need more frequent refreashes as you overclock it, so you may want to factor this in.
Hold on, are you saying that depending on your memory's clock frequency, you will need a different TREF value for optimum stability? That doesn't seem to add up with my testing.
I've found that a TREF setting that gets my BH-5 stable at 240 MHz/3.2v, where it is unstable with other TREF settings, also helps get my BH-5 stable at 260 MHz/3.4v, and 272 MHz/3.8v.
Tested across a range of frequencies, specific TREF settings still seems to help attain stability, unless I'm not being thorough enough with my testing.
So, what's up with that?
Likewise, according to what I just read above, this should be dependant on clockspeed?Quote:
4672....best performance for BH5/BH6/UTT.
Quote:
But the bit that needs testing, if you overclock the modules should you try and maintain the default refresh interval?
So if the the spec for your modules said 7.8us and you run the memory at 300Mhz what tREF value should you use?
This is theoretical on his part, but it makes sense...
But is the default refresh interval neccessarily the best refresh time for heavily overclocked and overvolted memory? BH-5 for example, is typically run at extremely tight timings.... I'm wondering if the timings skew the required refresh time.
EDIT:
I think you're onto something really big here, I just tested out the theory quickly, and it seems to work for me as well (granted this was a quick test).
I'm trying to get my BH-5 memtest86+ completely stable at 272 MHz - been using a tRef value of 4708. Various tRef values seem to either increase or decrease the number of errors per pass of test #5, 4708 is one of these.
According to the theoretical formula:
Ideal tREF = SpecRefreshTime / (1/ClockFrequency)
Ideal tREF = 7.8 / (1/272)
Ideal tREF = 2120
The closest value to that in the DFI NF4 BIOS is 2064, which appears twice for some reason. Using the first of the two 2064 values in the list, my BH-5 is on loop 46 (of test #5) right now, 8 errors. It was error free for 20 loops at the beginning. I'm using a DS of 6, and a DDS of 1.
Before this tREF value, it would error once every 2 passes or so, consistantly.
No stability yet, but a signifigant improvement, as measured by the number of errors per pass.
Anyone else want to try this out with an unstable memory overclock?
Wow I'm gonna try this now!
Okay in simple terms:
Everest refresh rate*FSB = Tref cycles
i.e.
7.8*200 = 1560
7.8*300 = 2457
I'm gonna try it and report back tomorrow..... :banana:
Okay, let me see if I understood it correct. So, if my FSB/HTT is 250, it'll then be 250*7.8=1950, and the closet TREF values to that without going over is: 2064(133Mhz-15.6us&1.95us). That's it? I still don't get. Man, am I so dumb or what?!!! :slapass: I just don't get how these numbers/values work. :brick: :brick: :brick:
Bloody heck this formula has made all the difference, before i was only able to goto 250htt using 3072 without instant BSOD as soon as i began to stress test it, or over 2k errors on 1st pass of 5th test memtest, however switching to 2048 i am now at 260htt (priming), insidently 2048 gives exactly 7.8us. However I do find it odd how 3072 was not as stable considering it was a far more relaxed tRef??
So thats the formula we use? We find the refresh rate in Everest and then just multiply that by the FSB/HTT speed to get the TREF value we should use?Quote:
Originally Posted by Jomiy
noQuote:
Originally Posted by burningrave101
lookup your HTT/Mem speed in the table. (or take a value close)
take the value higher than what you calculate as almost none are accurate. my oc didnt prove to be stable after all however it was more stable than before when i was using the "favourite" 3072 value for my redlines.
I looked it up in the table and came up with the same TREF value i got calculating my refresh rate times HTT speed.Quote:
Originally Posted by Jaco
I'm running 280Mhz with OCZ PC3200 Platinum Rev2 and the refresh rate in Everest is 7.8 us so 7.8 x 280 = 2184 and the next highest TREF value from that is 2336.
I'll try it out later and see if it helps stability any. Right now i'm not stable running 1:1 at 280Mhz 1T with this stupid Venice core. My Venice will overclock to 2.8Ghz+ but its memory controller seems crappy.
So if you make the time between refreshes too far apart, you risk degradation / loss of data. OTOH if 2 close together, may interfere w/ timing. Then there is teh JUST RIGHT Tref. :hrhr:Quote:
Originally Posted by qui
I am adding another thread about 'wouldn't it be nice to allow us to enter our OWN tref value based on FSB?
Well I tested my OCZ Plat Rev 2 at Tref=2336 since 305*7.8 = 2379. Seemed a tiny bit less stable than 3072. Tested at 2560 and got past 5 passes Memtest #5.
Then again my RAM seems to be clocking better since 2 days ago it needed 2.93V to do 5 passes at 300 and yesterday it only needed 2.8V...
This morning I swapped in BH-5, Everest refresh said 7.8us, set Tref= 2048 for 250Mhz (7.8*250=1950) and comp wouldn't POST! :slap:
Had to clear CMOS and take battery out :stick:
Weird....I like the fact that (for now) there seems to be an actual way to figure out what Tref value you "should" be using....but there's still too many people having issues with it for me to have full confidence. :(Quote:
Originally Posted by Jomiy
I think your suppost to choose the next HIGHEST tREF value after you calculate instead of just the closest one which is lower then the number you calculated. Trying lowering your HTT/RAM speed to 280Mhz or so and try the 2336 tREF again or try the next higher tREF value.Quote:
Originally Posted by Jomiy
I did it! :woot:
This program will calculate the ideal tref values for 256mb and 512mb sticks. And then find the clostest value above the ideal one for you. :banana:
Download TrefCalc
Does it help after you try the value this program calcalates for your setting?Quote:
Originally Posted by blackjok3r
no you enter, the speed you want to run your stick at and choose the stick size. Then it will calculate the ideal tref and pick out the closet value above the ideal value.
I know, but don't you have to enter that value in the TREF field in the BIOS?Quote:
Originally Posted by blackjok3r
yes of course you do... whats the point of calculating it if you dont use it??
Just wondering, what speed do you write in the field? 200 or 400?
Nice.Quote:
Originally Posted by blackjok3r
I think you really need to add an extra option of memory refresh if you know it.
Almost all memory seems to be 7.8us. 256MB normal memory is 15.6us, but our stuff (ie faster clocking etc) tends to be the same as 512MB, ie 7.8us.
HTH
nice work :clap:
Sup ya'll
Here's the test i ran to check for new ideal tref values:
All components as shown in my sig.
I know 260Mhz 2-2-2-5 is stable at 3.45v, but in memtest i always find its much easier to work with errors than a clear screen when searching for what settings are more stable than others...this will explain that:
vDimm: 3.38v (to cause a few errors, hopefully between 5-20 per pass in test 5)
FSB: 260
Timings: All tests ran using these
Using this excel sheet the ideal tref comes out to be 2031.25, which makes the following trefs candidates:
2064 (133Mhz - ?.?us) and 2048 (133Mhz - 3.9us).
To test for higher and lower ends of the scale i picked:
1552 (100Mhz - ?.?us) and 2560 (166Mhz - 3.9us).
I ran 5 passes of memtest test 5 for each tref:
Tref values | Average Errors Per Pass
----------------------------------------------------------
1552 (100Mhz - ?.?us) = 6-8
2048 (133Mhz - 3.9us) = 27-32
2064 (133Mhz - ?.?us) = 22-25
2560 (166Mhz - 3.9us) = 4-5
Increasing the vDimm back 3.45 and running 5 passes, 2560 was stable 1552 was ok (it gave me the odd 2 errors in pass 3). 2048 & 2064 were still giving me errors.
The trefs i use with my GH are 3684, 3120 & 2560 - 2560 seems to work with almost any memory on my setup.
OK READ THIS
if the refresh rate is TO SLOW data is corrupted correct? and if it is to fast then theoreitccly the sticks heat up more correct?
and if a lower value means it is refreshed more often, and a higher value means it is refreshed less often. then WHY do you want the next highest value? YOU DONT, that means there is more chance of data loss, you want the next LOWEST value would you not?
makes sense to me,
There is one big assumption made here that must be questioned: the module's refresh time.
In the same way that, for instance, TCCD is rated with 2-2-2 timings @ 200, everyone knows that these timings won't work with say 280 fsb. The same thing may apply to the refresh rate.
Moreover, as previously stated, the optimal refresh rate may be affected in someway by the other timings.
Honestely, for me this is the theory that makes most sense when defining the Tref value. But I doubt that the optimal refresh period of a module running @ 280 will be the same when it was running at 200.
This leads us to the same starting point: try them all to find the optimum.
With my 2x512 TCCD @ 291 I've found that the best Tref is 780 or 908, far way from the value given by the formula (2270).
What TCCD are you running? Because I've been reading through the various tREF threads this morning and have found from multiple places that the general theory sticks true to higher FSB's. As soon as I get off work, I was going to go home and try mine out [closest value came out to 2336, from 7.8 / (1/280) ].
What are the other timings / voltages you have as well?
BTW, this thread rocks, it's nice to actually see a thread that has uber-intelligence in it, instead of "is this rig any good?"....bleh :D
You can see my timings here: http://www.xtremesystems.org/forums/...523#post905523
Its GSkill 4400 LE @ 2.8v (I haven't tried 2.7v yet)
Have you ran any tests to confirm?Quote:
Originally Posted by WeStSiDePLaYa
if you look at the table
++++++++++++++++++++++++++++++++++++
1552= 100mhz(?.?us)
2064= 133mhz(?.?us)
2592= 166mhz(?.?us)
3120= 200mhz(?.?us)(my sweat spot w/ Bh-6 at 250+mhz , your mileage may vary)
---------------------
3632= 100mhz(?.?us)
4128= 133mhz(?.?us)
4672= 166mhz(?.?us)
0064= 200mhz(?.?us)
---------------------
0776= 100mhz(?.?us)
1032= 133mhz(?.?us)
1296= 166mhz(?.?us)
1560= 200mhz(?.?us)
---------------------
1816= 100mhz(?.?us)
2064= 133mhz(?.?us)
2336= 166mhz(?.?us)
0032= 200mhz(?.?us)
---------------------
0388= 100mhz(15.6us)
0516= 133mhz(15.6us)
0648= 166mhz(15.6us)
0780= 200mhz(15.6us)
---------------------
0908= 100mhz(7.8us)
1032= 133mhz(7.8us)
1168= 166mhz(7.8us)
0016= 200mhz(7.8us)
---------------------
1536= 100mhz(3.9us)
2048= 133mhz(3.9us)
2560= 166mhz(3.9us)
3072= 200mhz(3.9us)
---------------------
3684= 100mhz(1.95us)
4196= 133mhz(1.95us)
4708= 166mhz(1.95us)
0128= 200mhz(1.95us)
++++++++++++++++++++++++++++++++++++
you see that the formula
uS x FSB does NOT always apply.
check the table for yourself.
3.9 x 100 = 390 - table says 1536
ALSO...the other BIG question.....yes indeed we dont even know if we NEED to change the TREF...if the TREF has to be increased if we go higher with the HTT/FSB
At this point i THINK all this theory here is pure speculation - the only definitive answer we could get from someone at Samsung or someone who really KNOWS what the values mean in the bios and what they're supposed to be.
Maybe even Oscar just follows specs without being able to tell what's the optimum for certain speeds etc.
THEN....of course the odd values (0016 etc.) which are totally non-logical..and AFAIK 0016 also does not work and you get freezes instantly. Wonder if those values are just plain wrong.
I think the table is wrong.
It has just been formulated based on what a piece of software interprets the refresh rate to be.
How do you define "best" ?Quote:
Originally Posted by amrgb
Like in best performance eg. more bandwidth ?
Or more stability ?
I am sitting for months already on the problem to get my sticks to do 2.5 3 3 7 at 291 (best i can do is 2.5 4 3 7)...and "best" would be (for me) more stability.
Someone else maybe means "best" because he says 50MB bandwisth increase but even more instability ?
Well, you just have to try values either side of the ideal. There will almost always be one value which is closer to the ideal, so just use that one.Quote:
Originally Posted by WeStSiDePLaYa
I would say too high and too low are both equally bad. They both cause errors.
Interesting point. I don't know enough about memory technology to state whether the ideal refresh period changes with speed.Quote:
Originally Posted by amrgb
Is there a chance you have 3.9us memory? That would mean the ideal Tref @ 291 is 1135, which is at least close to the 780 and 908 you use.
Also, as already mentioned, is that a stability or bandwidth 'best'?
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.Quote:
Originally Posted by flexy
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.
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.
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?).Quote:
Originally Posted by flexy
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?
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.
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
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.
Hey Sharp!
Good to see you!
Thanks for giving me the spark to investigate all this Tref stuff!
Thanks for those RMMA tests! Interesting...
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 ;)
http://xtremesystems.org/forums/atta...id=32377&stc=1
Peace :toast:
gah this stuff is so mind boggling lol
I just used the guys calculator, it worked too 4128 is best for ddr500-ddr490 :cheers:
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?
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
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:Quote:
Here's a little info from the CPU side of the Tref picture...
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? :confused:
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.
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.Quote:
Originally Posted by dexx
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).
:hehe: Why else would they have dif reg settings with the same MemClock count. There are distinct patterns in the reg settings too ;)Quote:
Originally Posted by astaris
Peace :toast:
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?Quote:
Originally Posted by EMC2
The refresh rate needed isn't based on the frequency you're running at :)Quote:
Originally Posted by dexx
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 :toast:
Well i see the patterns:Quote:
Originally Posted by EMC2
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.
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:
Quote:
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.
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?
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:Quote:
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?
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.
They label it wrongly cause they assumed 100 = 233 Mhz, but i'm pretty sure that 100 = 120 Mhz.Quote:
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.
Well i don't know why on the bios you have these odd settings, 16, 32, 64 and 128. But i'm sure that:Quote:
(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?
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.
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.Quote:
Originally Posted by astaris
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).
I think RMMA reads the Bits 4-3 of Tref register and then converts these bits in us:Quote:
Originally Posted by Agent-Sharp
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.
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.
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.
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.
i found so far that 7.8xMemory frequency, helps me most...
i havent really ventured outside that to aweful far
astaris, great research !!!
we should write to the coder of a64tweaker so he corrects how he reads the tref in a64tweaker..because this is obviously wrong !
Btw. any other way to read this register besides RMMA ? I mean the whole 5 bits so i can doublecheck whether everything is right.
Your table makes a lot of sense !
thanks !
Would 1024MB modules be 3.9us? Everest is reporting them as 7.8us but that doesn't make much sense if 256MB are 15.6us and 512MB are 7.8us.
And have we concluded an effective way of calculating a CORRECT tREF value yet? Is it MEMCLCK ratio x refresh rate (200Mhz 1:1 x 3.9us)?
256 MB single side memory modules can be either 7.8 us or 15.6 us, it depends on the number of rows in the chips: 4096 rows chips have a refresh rate of 15.6 us, 8192 rows chips a refresh rate of 7.8 us.
1 GB double side memory modules can be either 8192 rows (7.8 us) or 16384 rows. In this case often the chips refresh two rows in one refresh cycle, so the refresh rate is stil 7.8 us.
In the end the best way to know the refresh rate is to look at the spd of the module.
And after we find the refresh rate we just multiply that times the current MEMCLK divider such as (200Mhz 1:1) for the ideal tREF setting?
i tested all of the trefs and wrote down my results on a excel sheet if someone is interested.
i tested: 1 sp8m, 1 3dmark01, 10 passes test n5 memtest and 4 passes test n8 in memtest. (i wrote bandwith, socres on 3dmark01, time in super pi and sandra bandwith).
then the trefs that passed all of the above tests i runned 16m of pi, 3dmark01 and 3dmark03 and then the ones that passed 16m on super pi i tested them with sp32m, now finally with only 3 trefs that passed all of the tests above i'm priming.
So if it helps let me know and i'll upload it or email it, is with some g.skill le 2x512mb tccd431 at ddr600 2.5-4-4-8 i have all the other settings on the excel sheet.
metro oc....that would be awesome....PLEASE upload it!!
well here it is, sorry for the hosting only one i knew. im still testing prime95
http://rapidshare.de/files/3298036/tref.xls.html
if you need sreenshots i have some but not for every test
For other people...valor = value
pasadas = passes (I think...it literally means happenings, IIRC...took spanish for two years but never paid attention)
Quote:
Originally Posted by Vapor
thats right, is kinda easy :)
any question just ask, im still priming with tref 1032 more than 1 hour still no errors
The more I look at it, the more impressed I am with this table...WOW!
:toast:
A lot of effort has gone into this...tremendous to see that only 5 survived SPI 16M and only three of those survived 32M!
Say 1032 and 1168 both pass infinitely for P95...will you see which can clock higher or which can also take tighter timings to find which works best at ~300MHz? Not sure if you can tighten much up, maybe trc or read to write, but it may be worth a shot to see if either can take the added heat.
Quote:
Originally Posted by Vapor
i'll try more tweaking later, still no errors on tref 1032.
Thanks very much for your hard work. :toast:
It should have taken you a long time to fill such a large sheet.
I'll give a try with your best Trefs and my LE's. Let's see if I can get some improvement. At the moment I'm using 2336. I've reached this value with a similar process to yours. However since I my memories were not on the edge of stability, I've found several Trefs that passed the tests. Unfortunately I can't remember whose Trefs worked for me, since I'm not, by far, as organized as you.
I'll report my feedback as soon as possible.
Well.... actually there is a way to test/verify the Tref values ;) While I had my DIMMs instrumented anyway, I did :p: The values for the first 3 sets of TRef in the BIOS are fairly close, including the odd low settings.Quote:
Originally Posted by astaris
The BIOS values are the number of MemClocks between refresh cycles (+/-10%). Divider, multiplier, etc. do not matter... only the actual MemClock period... verified for all pre E-rev A64s.
So:: (1 / MemClock) * Bios_Tref = Refresh Period (+/-10%)
Measured actual TRef values(+/-1 clock) in thumbnail below, along with a table for 200Mhz to 300Mhz MemClock, refresh values in uS.
Peace :toast:
So it's best to stick as near as possible to e.g. 7.8uS ?
I noticed at 200mhz, with my 2x512, when tRef is set to auto, it defaults to 3072 3.9us. I am thinking that the Platinum kits TOGETHER (the 2x512) is 3.9us, not 7.8
Who knows though, I have no clue about all this tRef stuff.
:toast: :clap: :toast: :clap: Very nice and very helpful...thanks :)Quote:
Originally Posted by EMC2
If you really mean that... you can send the complimentary 1GBx2 kit to.... :rofl: :p:Quote:
Originally Posted by RyderOCZ
EMC2: Thanks for your chart :)
I did notice when I set Tref to high eg. Tref=4708 at 264MHz@3.4v it gives me error in memtest86+ #2. When I use Tref=2048 the error in #2 is gone.
One thing I've noticed in my limited play with tref values so far.
On my 2X1gig patriot, and my abit av8 board, the values in a64tweaker are done 200mhz/3.9us etc. In that style.
I've found that the 200mhz/1.95us setting for some reason scores roughly 2000 less than most other values in sandra memory bench. I haven't literally benched them all, but i tested a few values with the refresh at 7.8 and 15.6, as well as some other 1.95 and 3.9 values, and they all netted about 6100-6200 as a sandra score. Yet 200mhz/1.95us scored a mere 4000. It doesn't make much sense.
I've also found that 100mhz/3.9us seems the best on my patriot. Its one of two to successfully do 32M SP with my current settings, the other one being the above mentioned setup that has less bandwidth.
-Andrew
Look at the screenshot, which one you think is giving me the Real Tref :confused:
A64 tweaker is showing 133Mhz, 1.95us while RIghtmark util showing it at 7.80 us ? The refresh rate (tRef) was set to 1168 via bios
I'll share a few of my questions and thoughts on this.
First 1.95us, 3.9us, 7.8us, 15.6us is it that if these are lower the memory will run more stable?????????
Does memory size effect this setting???????
How does command rate affect tref??????
Also I believe once you figure out the refresh time you want to run at you complete this equation [refresh time in us]/[1/fsb] and then select what ever tref is closest to that number.
What do you think???? Is this right?
the trick isn't to set it too high or too low, it's to set it as close as possible to optimal so it's fast but u don't error, only way to do that is test it.
How do you suggest selecting the refresh period 1.5, 3.9, 7.8, 15.6? My bios setting are relative to cycles and frequency is involved in my calculation so I think it will get me close to optimal, but I'm not sure because I got it from other people's posts.