• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Official AM2 Thread!

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
hitechjb1 said:
I tend to agree with your statement. If all the timing parameters (in number of cycles) for case A are exactly N times that of case B, and frequency of case A is also N times that of case B, then the latency (in seconds) for both cases would be the same.
Once again this is only true if ALL timing parameters vary by a certain factor. Even the standard four I listed are only a partial set. There are far more latency parameters than what users are normally able to control...just look at the extended timings in A64 tweaker, DFI BIOSes, etc.

So yeah 5-2-2-2 has half the delay of 10-4-4-4...but can you say that e.g. 12-5-2-2-2 has half the delay of 14-10-4-4-4, supposing an extra dummy parameter was thrown in the mix? Not a chance. In reality there are hundreds more of such parameters. It just can't be simplified this way.
 
hitechjb1 said:
Can you do two more runs and compare the latency numbers:
1. 150 MHz 1.5-2-2-6
2. 300 MHz 3-4-4-12 (or 3-4-4-x if you cannot set tRAS to 12)

Ok. I ran two tests at 150MHz. One with 1T and the other with 2T.

Here is 150MHz 1T @ 63ns. Yet again adding about 20MHz.
63ns150MHz1T.jpg

Here is 150MHz 2T @ 69ns
69ns150MHz2T.jpg

Here is 300MHz 2T @ 51ns. 2T is all the ram will do at 300MHz, and tRAS of 12 is possible but forgot when I ran the test.
51ns.jpg
 
avalanche83 said:
Ok. I ran two tests at 150MHz. One with 1T and the other with 2T.

Here is 150MHz 1T @ 63ns. Yet again adding about 20MHz.
63ns150MHz1T.jpg

Here is 150MHz 2T @ 69ns
69ns150MHz2T.jpg

Here is 300MHz 2T @ 51ns. 2T is all the ram will do at 300MHz, and tRAS of 12 is possible but forgot when I ran the test.
51ns.jpg

This doesn't do it much justice as you are doing this on a fairly outdated memory controller.

Check out this thread as it contains lot of comparisons and mostly on s939.
 
Most people on there bench using Sandra and of course higher bandidth is going to show impressive numbers using DDR2. If they added some latencies it would give a better comparison.

And yes the memory controller is outdated but does give a good comparison in bandwidth making up for loose timings.
 
hitechjb1 said:
Can you do two more runs and compare the latency numbers:
1. 150 MHz 1.5-2-2-6
2. 300 MHz 3-4-4-12 (or 3-4-4-x if you cannot set tRAS to 12)
Oh yeah, CAS 1.5 actually doesn't exist. This has been verified repeatedly by AMD, OCZ, Mushkin, and DFI to name a few. Setting "CAS 1.5" really just sets CAS at 2ns along with some other internal parameters changed. It DOES NOT set the CAS latency to 1.5ns.
 
Gautam said:
Oh yeah, CAS 1.5 actually doesn't exist. This has been verified repeatedly by AMD, OCZ, Mushkin, and DFI to name a few. Setting "CAS 1.5" really just sets CAS at 2ns along with some other internal parameters changed. It DOES NOT set the CAS latency to 1.5ns.
clock cycles. not nanoseconds.
 
avalanche83 said:
Here is 150MHz 2T @ 69ns
69ns150MHz2T.jpg

Here is 300MHz 2T @ 51ns. 2T is all the ram will do at 300MHz, and tRAS of 12 is possible but forgot when I ran the test.
51ns.jpg
I think this illustrates it fairly well...now if we want to keep it even simpler, see how latencies effect delay time at a single given memory frequency. But I think the point stands...

Btw where have you been hitech? Good to see you back.
 
avalanche83:

Since CAS 1.5 may be the same as CAS 2 (for DDR in A64 setting),
and you have been doing the latency vs timing parameter runs using Everest, could you do another test.

Can you do two runs and compare the latency numbers:
1. 200 MHz 2-2-2-6
2. 300 MHz 3-3-3-9

"If all the timing parameters (in number of cycles) for case A are exactly N times that of case B, and frequency of case A is also N times that of case B, then the latency (in seconds) for both cases would be the same."

latency = (k1 t1 + k2 t2 + k3 t3 + ...) / freq
where
t1, t2, t3, ... are the timing settings,
and k1, k2, k3, ... are the corresponding constants to calculate latency.
E.g.
read_latency ~ (tRCD + 8 tCAS) / freq .... for burst-8 page mode
read_cycle_time ~ (tRCD + tCAS + tRP) / freq

If all the timing settings t1, t2, t3, ... for cases A and B are in the same ratio as freq_A to freq_B,
then latency_A = latency_B

E.g.
200 MHz 2-2-2-6 vs 300 MHz 3-3-3-9, the ratio is 2:3.

Memory frequency and latency tradeoff (post 195)



Gautam said:
...
Btw where have you been hitech? Good to see you back.
I have been around, mostly updating the various posts in the stickies rather than new posting. Like in the past, from TbredB to Barton to various A64 cores, ..., if there are new things/questions that I have to learn, understand and solve (curiosity), I probably will post more, ...
 
Last edited:
_damien_ said:
No, tRAS is not the interval at which instructions can be sent to each row. tRAS isn't really a delay, it is merely a counter that starts with the activation, and then triggers the precharge command at the end of the transfer. I.e. it sets the minimum row active time before the precharging (tRP) of the row. The tRCD and CAS timings, as well as the burst length determines how long a given row must remain active, so the row is always active within the tRAS interval...
Ok, that does make much better sense than the way I interpreted it. So it should ideally be set to tRCD+CAS, but what's burst length?

_damien_ said:
"Inescapable" is an exaggeration, as this depends greatly on the organization of the requested data, and the number of internal banks combined with interleaving-techniques.
Ok, fair enough. Still, at least from what I can gather, it appears to be about the most critcal parameter. Conceptually as well.


Seems like you're extremely well informed on this subject. Could you explain why CAS seems to make such a small difference in performance on the A64?

Is the performance (probably not relatively that large as you said) gained from that extra bandwidth worth it or not? Depends on who you talk to. ;)
 
More & more sites report sources claiming
Athlon 64 X2 5000+ will be a 2.6 GHz part and
Athlon 64 FX-62 will be a 2.8 GHz part.


The only way this can be is if they both use DDR II 800 and AM2 ends up using .5 multipliers, nothing else fits since they certainly will not be running off of DDR II 400.


Can they all be wrong? How do you get 2600 MHz without using DDR II 800 and .5 multiplier?
 
^^^rounding.

Interesting stuff on this socket thankfully I have my Crucial ballistix 2x512mb with Micron d9 bt-3 chips so I can either stay Intel with what should be even better 9x0 series or go AM2 if it really looks that good.
 
c627627 said:
More & more sites report sources claiming
Athlon 64 X2 5000+ will be a 2.6 GHz part and
Athlon 64 FX-62 will be a 2.8 GHz part.


The only way this can be is if they both use DDR II 800 and AM2 ends up using .5 multipliers, nothing else fits since they certainly will not be running off of DDR II 400.


Can they all be wrong? How do you get 2600 MHz without using DDR II 800 and .5 multiplier?

Maybe they are rounding up the numbers :shrug:

This doesn't make sense to me either.
 
So if everyone is rounding, they would be rounding from
8 x 333.33 = 2667 MHz (rounding error there, isn't it? Rounds off to 2.7 GHz)
and
8.5 x 333.33 = 2833 MHz.


If Gautam is right and no DDR II 400 is used for the FX, which makes sense now but the reason AMD was asking for it, if not for 90nm AM2s, then for 65nm Brisbane, that's how they're going to scale Brisbane, off of DDR II 400 then. Makes sense?
 
Guys its very simple and Ive spelled it out for ya pretty well. The HTT I know for a fact is 333. They support DDR2-800 asynch only. .5 multipliers might be working on these chips but as far as I have been informed there is no 2.8ghz chip planned, not yet atleast.

The highest AM2 chip that I know of is a 2.66ghz FX with 2x1MB of cache (333x8) the current ESs out right now are at this speed.

Again, AMD cant use DDR2-800 because when they made the controller it hadnt been JEDEC approved. In order to give any DDR2-800 1;1 support they'd ahve to overhaul and totally redesign the controller again. (ie its not going to happen till K10)
 
....but in the old days AMD did not "advise its partners to get some DDR 433 PC3500 memory (or higher) and to include it in DVT testing."

Overclockers make a fraction of the market, DDR 400 PC3200 memory was supposed to be tested for Socket 754/939, that's it, right?


So now when "AMD advises its partners to get some DDR 2 800 memory and to include it in DVT testing," what's that for? For async? To make sure overclockers use compatible modules?


If AMD "advised" their partners, then it's kind of like 'yeah, PC2700 is what we're going to be using initially but later on we plan PC3200 Bartons so make sure PC3200 is compatible. Otherwise, what would be the explanation for official request like that (AMD doesn't support overclocking officially...)

That is, 'make sure DDR II 800 is compatible'... for 65nm Brisbane CPUs... perhaps?
 
Last edited:
Back