This Should Be Impossible, Right?

Gigabyte 965 board.
all voltage max.
Corsair 5400 UL V1.2.

cas 3-1-1-9.

I have bandwidth shots from all latencies down from 3339 to 3119 to make sure each latency was actually doing something, and while the differnce isn't drastic in any case, every setting did effect the bandwidth...

TRP 1 I can see as possible.
but Ras to Cas 1... thats some huge thing to expect from ram, so I find it almost crazy to think this might be possible.

I can test this in any way anyone wants to...
right now I am running Super Pi 1.5XS on it, at 3.5 ghz, with a old prescott 560.

in case anyone wants to say its reporting the wrong cas... heres how to fix that.

Bios F3. use the red slots. set your ram to the 2.66 multiplier.
thats the best way I found for the bios to report the correct latency.
still cannot set ras to cas 2 or TRP 2 within bios and have it stick, it just defaults to ras to cas 3 and TRP3.

settings were changed with Memset965.

bandwidth is low, cause I was still using version 2006 which reports about 1000 mbs lower then version 2007.

super PI 32M, appears to be half done, and stable cas 3-1-1-9.

will do cas 3-3-3-9 next to make sure, somethings actually different.

CPUZ.

cannot run tras at 1, with these settings, it just gets too tight, and reboots.

have not tested anything at lower then 9 tras yet.
just want to test this ras to cas 1 stuff for now.

Does it say anywhere that trp and ras to cas cant be 1?? I know that cas 2 is a definite no go, dont remember anything about the other settings though.

well, heres 32M at cas 3-1-1-9...

I dont know if I should be doing this :banana: or this :slap:

Now try Super pi with "other" tight latencies from bios (like 3-2-2) and see if it afects :)

Quote:

---

Originally Posted by ZeroX

Now try Super pi with "other" tight latencies from bios (like 3-2-2) and see if it afects :)

---

lets hope it does :toast:

nice find kunaak, i have to try this as well, once i get this msi k9n out of my bench rig :p:

Depending on the clock frequency, it's certainly possible for the row signal to stabilize within one single clock cycle, because all that matters to that parameter is *time*. However, as the memory controller's setup time is locked at 2T command rate, the row signal will actually get 2 cycles to stabilize before the read address is asserted. Obviously, as the commands are qualified on the second cycle, the memory cannot respond to the read-request just one cycle after the assertion of the activate command. As a result, tRCD = 2.

I don't know, man, 9-1-1-3.0 ??? I swear, those Gigabyte mobos need a BIOS fix or somethihng. First CAS latency wierdness, now this :D Or it's that Memset that lets you pick-n-choose whatever you want and even apply it :shrug:

try everest.

see what, if any, those timings have an effect on latency.

Quote:

---

Originally Posted by bachus_anonym

I don't know, man, 9-1-1-3.0 ??? I swear, those Gigabyte mobos need a BIOS fix or somethihng. First CAS latency wierdness, now this :D Or it's that Memset that lets you pick-n-choose whatever you want and even apply it :shrug:

---

actually might be right about that one - only thing is Memset changes concur with CPUz :confused:

could this be similiar to when people were running 1.5cas on utt/bh-x, and everything reported it as so, but in reality it was still 2.0cas?

cpu-z memory timings always come out weird when I use memset on my DS3

Quote:

---

Originally Posted by bachus_anonym

I don't know, man, 9-1-1-3.0 ??? I swear, those Gigabyte mobos need a BIOS fix or somethihng. First CAS latency wierdness, now this :D

---

Sorry for the offtopicness, but do you know of any DDR2-chips that support CAS 2? (I just learned to my surprise that AM2 actually supports CAS 2)

Quote:

---

Originally Posted by WeStSiDePLaYa

could this be similiar to when people were running 1.5cas on utt/bh-x, and everything reported it as so, but in reality it was still 2.0cas?

---

That's certainly a possibility, but interestingly I don't see how selecting tRCD 1 would lead to instability in this case. Not that I think the row sensing actually completes in one single cycle, but on a rig where the command rate is locked at 2T, we'll never be able to find out for sure because the tRCD-delay is 2 clocks in reality. As I said earlier, the row signal will get a 2-cycle "rest period" before the memory starts responding to the read command. There'll be no data corruption unless the CAS operation is triggered too early, which is impossible (assuming the row signal always stabilizes in 2 clocks).

heres what I can say about it so far.

cas 3-1-1-9 is definatly faster then cas 3-2-2 por 3-3-3, but not by much.
about 5 seconds faster in 32M, and about 4 FPS more in Lobby of 3dmark2001se.

kinda gave up testing it, cause this prescott is just too damn slow to show any real differences CAS can make.
I have a new "Faster" CPU coming soon, and will redo my testing with that, something that shows more clearly if there is or isnt any real benifit to this.

Quote:

---

Originally Posted by _damien_

Not that I think the row sensing actually completes in one single cycle, but on a rig where the command rate is locked at 2T, we'll never be able to find out for sure because the tRCD-delay is 2 clocks in reality. As I said earlier, the row signal will get a 2-cycle "rest period" before the memory starts responding to the read command. There'll be no data corruption unless the CAS operation is triggered too early, which is impossible (assuming the row signal always stabilizes in 2 clocks).

---

i thought having command rate at 2T meant two clocks from the last command :toast:

Quote:

---

Originally Posted by ozzimark

i thought having command rate at 2T meant two clocks from the last command :toast:

---

At 2T the minimum command-to-command spacing will be two address bus timeslots, so the way I see it you thought right. At 2T, each address is held valid for two cycles, and qualified by the chip select signal on the crossing of the second clock. So there'd be a rest period on the bus, but each command/signal would still occupy two clocks on the controller, which naturally causes a delay, and hightens the risk of command collisions.

Quote:

---

Originally Posted by Kunaak

heres what I can say about it so far.

cas 3-1-1-9 is definatly faster then cas 3-2-2 por 3-3-3, but not by much.
about 5 seconds faster in 32M, and about 4 FPS more in Lobby of 3dmark2001se.

---

If there's a difference between 3-1-1 and 3-2-2 I suspect even more strongly that the numbers are simply wrong, for the reason I've already explained.

Quote:

---

Originally Posted by Kunaak

kinda gave up testing it, cause this prescott is just too damn slow to show any real differences CAS can make.
I have a new "Faster" CPU coming soon, and will redo my testing with that, something that shows more clearly if there is or isnt any real benifit to this.

---

Yeah, the netbursts are poorly suited for such an experiment, because they don't respond well to timings. However, a 1:1 ratio would be better suited for a timing comparison, because the async-buffering tends to even out the gap between different internal latencies.