Printable View
One other point I want to make. I'm not saying timings don't matter because they do. 3-3-3 will definitely be faster in 32M than 4-4-4.
When it comes to benching Pi, the Japanese are the absolute masters of timings and ratios on the Intel platform. Most people don't bother to look at the primary and secondary timings they're using. I always notice.
Things to keep in mind:Quote:
Originally Posted by sierra_bound
* Any DDR2-module supports Additive Latency
* The entire memory subsystem shares the same command bus
* Only one command can be sent at a time (and at 2T they occupy 2 timeslots)
* The controller must wait for the row-signal to stabilize before issuing a corresponding read command (when AL = disabled)
If you're not using additive latency, 4-3-3 would usually be better than 3-4-3, as I've already stated. (i.e. tRCD would be more important)
In my first post I explained how certain other settings could reduce the influence of CAS latency, and stated what would be an unideal example. Not in the sense that it would yield "the worst performance possible", but in that CAS 4 - tRCD 3 would result in smaller bubbles than CAS 3 - tRCD 4, even though CAS is generally more important. You see, if AL = 0, increasing tRCD from 3 to 4 would inevitably delay the assertion of the following read -and activate-commands. Naturally, the memory cannot respond to a read-request before tRCD completes. And in interleaved mode (the best option in most cases), where the memory is switching between internal banks instead of reading rows in longer sequences, the activation of the next bank should ideally begin at the very same time as the read request to the "first" bank. But it doesn't do much good to activate a row if it's not going to be read from, so the read request to the first bank would get first priority, and the next activation would be delayed. Hence, a data bubble would result. If the timings were the other way around (CAS 4 - tRCD 3), the bubble would only be of half the length. Since tRCD completes one cycle earlier, both the "first" read-request and the following activation can be sent earlier. So the critical word latency would be the same for both scenarios, but the throughput would be better when tRCD = 3.
The "blame" for this lies not with CAS latency itself, as these problems are possible to avoid. The most significant feature is additive latency, because it helps to avoid command collisions. This feature allows the memory to capture read-commands internally before the row-signal stabilizes, and trigger them according to the timer value. But with AL disabled, there would've been several unused idle-cycles between the commands.
There are many factors that increase the probability of command collisions. The most important ones are low burst length, no use of AL, tight timings and 2T command rate (not much to do about CPC on Intel-rigs tho).
Summing up: Barring "disturbing elements" (which is fully possible), CAS is the most important setting because it's involved in every read operation.
ya know ive noticed odd things about my DS3 when it comes to tight cas timings.
i have uber generic Samsung DDr667 SPD is 5-5-5@667 but she does 800 5-5-5 just fine with 2.1v (anything higher than 2.1 is an instant memtest error bomb lol)
anyways. i get slower results also with tighter timings.
i think the Gigabyte line, and possible the 965 line is goofy with the tighter cas timings.
a clock for clock comparison between my cpu/ram and my DS3 compared to OPB's P5B shows i am around 0.30sec slower on my DS3 ... he was running 4-4-4 800 i was running 5-5-5-15 @ 800.
i really dont think the 965's react all that well to tight ram... infact just to opposite, possibly worse.
i was getting slower speeds at 667 4-4-4- compared to 5-5-5
maybe its just me though :\
_damien_, are you going to live in a scientific ivory tower and deny the results shown earlier in this thread by two different users? A long time ago, there was a well-respected scientist named Ptolemy who said the sun revolved around Earth. Guess what, he was wrong. Believe whatever you want. The reality is that there is very little difference between CL3 and CL4 on the Intel platform. I'm sorry you can't accept that fact.Quote:
Originally Posted by _damien_
Make that 2 of us :) DDR2-1040 @ CAS3.0 is definetely NOT happening for 32M, regardless, if it's with TRP=3 or TRP=4. Maaaybe with 2.8-2.9vdimm, but most likely still not. That Gigabyte mobo MUST have some sort of a problem with CAS and few others have been talking about it before - on DS3 or DQ6...Quote:
Originally Posted by Gautam
-----------
Since this is not in Intel section, I thought I'll chime in with my 32M runs at various latencies on Socket AM2. I hope you guys don't mind as this an interesting comparison for us, SPi benchers :) No matter, whether it's Conroe rig or AM2... So here we go:
Socket AM2, 3200+ "Orleans", 2x1GB Corsair 6400C3
First, here is the set of 32M runs @ 267x10=2670MHz, DDR2-890
8-3-3-3.0 ---> 27:00.047
8-3-4-3.0 ---> 27:03.093
8-3-4-4.0 ---> 27:14.454
8-4-4-4.0 ---> 27:14:656
8-4-5-5.0 ---> 27:29.094
8-5-5-5.0 ---> 27:28.859
Then ramped up memory speed @ 267x10=2670MHz, DDR2-1068
8-3-4-4.0 ---> 26:48.812
8-4-4-4.0 ---> 26:48.485
8-5-5-5.0 ---> 27:00.360
So, there you go... This is how it looks on Socket AM2, at least in my testing :) There are couple conclusion that can be drawn:
1. Between 8-3-4-3.0 and 8-3-4-4.0 there is 11s difference, showing that CAS latency was responsible for that.
2. Set of 8-3-3-3.0 and 8-3-4-3.0 shows only a slight change in calculation time, leading to believe that TRP=4 makes little impact. Further sets (CAS4 and CAS5) show that this impact is almost none. Interesting... But keep in mind, that TRP=4 definetely WILL improve memory clocking. In my earlier testing, a whole 25-30MHz ---> DDR2-900 vs DDR2-950 and DDR2-1080 vs DDR2-1140 :)
3. Both runs, DDR2-890 8-3-3-3.0 and DDR2-1068 8-5-5-5.0 yield EXACTLY the same calculation time :) That shows, where low latency performance meets sheer power of high frequency clocking. Also, good info for those affraid of pumping high voltage thru DIMMs - 2.1vdimm vs 2.5vdimm :D
:peace: :toast:
How many times do I have to explain?Quote:
Originally Posted by sierra_bound
You're the one who's dodging the facts. I don't even know what to highlight, you're so lost. As I've said throughout this thread, in order to prove me wrong you have to follow my specific examples. I can't be held responsible for your failure to do so. Gautam actually said that most people actually use my "unideal settings". That's true, but it doesn't remotely prove me wrong - however it does invalidate your benchmark results in this context.
If anything I say is unclear, I'm usually willing to elaborate. But since you don't wanna listen, fine.
It's obvious that you don't understand much of what I've been explaining. Why did you even bother to say that I was right about the theory, when you obviously don't have the knowledge it would take to verify 20% of it?
Thanks for the comparison, bacchus.:) If you take my 8M results at CL3/CL4, it would probably work out to about 5-6 second difference in 32M. Not much of a difference. Perhaps CL makes a bigger difference on the AMD platform because of the on-die controller. It may be that the chipset latencies come into play on the Intel platform.
When a person resorts to insults, it usually means they've run out of intellectual ammunition.Quote:
Originally Posted by _damien_
If you want to flame me, go right ahead. It's just that I'm one of those people who relies on what my own results tell me, and not on what others say. Maybe I'm deluding myself, but hey, that's the way I am. You need to chill out.
I'm not looking to flame anybody.Quote:
Originally Posted by sierra_bound
You see, I took post # 29 as an insult. Especially since the root of our disagreement was the fact that you were not following me. And I didn't run out of intellectual ammunition, but responded that way because I didn't like your tone, and because I got the impression you were ignoring crucial parts of my example.
Same for me - I think that's very wise. But I stand by my words: The benches posted here do not prove me wrong. My statement depends on criteria that were not evidently met by those benches. I honestly think those criteria were made clear to you, yet you kept on discussing as if you didn't hear them. That annoyed me quite a bit.Quote:
Originally Posted by sierra_bound
I even said in my first post that you were right from a certain point of view, but that the tables would turn in a different scenario (in which, for that matter, the overall performance too would be better). That's not about denying facts, but providing new ones ;)
Thanks both Sierra_Bound and Damien for your input - it's actually enlightening to learn from theknowledge and experience from both of you - please keep it up ( please please please without getting personal - too much to learn out of this )
Bachus - actually very interesting to see your comparos!
RE: 530 cas 3 - I agree with you fully that it seems impossible, the only thing that completely threw me off was that after I ran the same test today with a set of Corsair 6400C3 - and those couldn't keep up with the ST set I used above. - I would have expected those to do much better but they ended up in the same max MHZ vicinity as they had on Asus boards ( not Badaxe - had the 6400C3 at over 500mhz there too at Cas 3 - lol ) .
Glad you found it interesting. Btw, I just updated post # 27 ;)Quote:
Originally Posted by mikeguava
I just read that post and instantly got a headache :lol: Once in a while we get to see some VERY knowledgeable people here and you are definetely one of them! All your posts are a bit hard to chew on but are very insightful! Last time it was EMC2 that was giving us great lectures but he disappeared last year... :( I hope you'll stick around, man! :toast:Quote:
Originally Posted by _damien_
Thanks a lot, lad! :p:Quote:
Originally Posted by bachus_anonym
If people think my posts are hard to chew on, I hope they'll ask me to elaborate!
@_damien_
No hard feelings on my part.:) But as I said earlier, I can only go by my results. If my results were somehow inconsistent with what others are getting, then I would have to conclude my computer is borked. But from what I've seen so far, my results seem to be consistent with the findings of others.
With the Intel platform, the chipset has its own internal latency which changes depending on which strap is used. In order to run high FSB, that latency generally has to be relaxed. This might explain, in part, why changing certain timing parameters does not yield the expected result. That's just a theory on my part.
Trust me, I can understand your arguments. I spent many years in graduate school and wrote term papers on much more complex subjects. All I'm trying to say is that research involves testing. If the tests do not verify the premise, then the premise needs to be re-examined.
Yes, but once again the settings that most people use are probably inconsistent with my criteria. I think that's been the root of our disagreement, and as far as I can see, my point of view still hasn't been shaken. Under the most common scenario (i.e. the settings that most people use), I've been pointing out to you that tRCD would in fact be more influential than CAS. So it remains a mystery to me why you had to argue on that one, and to even accuse me of denying facts.Quote:
Originally Posted by sierra_bound
My "ideal scenario" was neither impossible nor irrelevant, and when looking to challenge it, you'd have to stick with the settings I listed. Regarding the more common scenario, there really was nothing for you to challenge, because we were (believe it or not) in total agreement all the time.
But alright, no beef. I think I learned one thing from this:
If I get mad it's probably a good idea to wait some 30 minutes before posting a reply ;)
:D
In which board did you compare 4-3-2-1 vs 3-3-3-1 ???Quote:
Originally Posted by VictorWang
I have different results as 3-3-3 is better from 4-3-2 in my tests .