RAM Timings

[congo]

A question.

Why is it that I can easily get  280mhz memspeed stable with a 1:1 divider and everything is hunky dory, but as soon as I change that ratio, I run into trouble immediately. For example, if I use a 9x cpu multi here, I get instant failure in Orthos.

I thought the memory controller wasn't supposed to be fussy about sync with a64?

[Nick N]

[quote]A question.

Why is it that I can easily get

[congo]

My Pics show clockgen just so you can see the numbers NickN, I do set it up in bios for the most part. I might swap settings in clockgen just to quickly try something, but I always verify it with bios settings before commenting or making any conclusions.

I won't use 4x, under 1000 on everything so far.

I'll check it out a bit later and verify this, must go now. The mighty VF19 need their server up and other duties await

[congo]

I had a minute, here is the 9x test, failed immediately, I'll post the 10x repeat test later.



That was set in bios.

Edited:
Just for kicks, did you know that the cpu speed in the orthos display area always shows the boot speeds set in bios, even if you make a change on the fly and restart the program?

[Nick N]

I had a minute, here is the 9x test, failed immediately, I'll post the 10x repeat test later.



That was set in bios.

Edited:
Just for kicks, did you know that the cpu speed in the orthos display area always shows the boot speeds set in bios, even if you make a change on the fly and restart the program?

Thats what I am trying to say..

[Nick N]

Your temps look fine, raise the Vcore to 1.50v and see if it still bugs out

The only thing I can think of that would cause what you are seeing, assuming all the CPUz numbers and ratio are correct, is something in the CPU table is telling the system to run a colder Vcore when the multiplier is reduced. That is part of the AMD CPU driver function and the Vcore table IS in fact based on the multiplier. When the driver reduces the multiplier it reduces Vcore automatically.

Something could be going on behind the scenes we cant see. I have seen Vcore vary with AMD using different software when CPUz showed the BIOS setting constant and not changing. I can't remember what program I used right now. When cool and quiet is enabled it will vary in CPUz but when not enabled, it wont but there are still some changes taking place, although not large.

I'll bet thats what it is. The 9x multiplier is somehow enabling a Vcore reduction. As I said, try raising Vcore to 1.47 or 1.50 and see if it still wigs out on the stability test. If it doesnt, I am sure that is what is happening. If it still blows the test, I'm stumped on this one. Other than some type of incompatability with Orthos using the 9x multiplier..  you got me on this one.

[congo]

The memory tab is important because it will show the ratio and confirm it

Clockgen shows it, but I know, you get familiar with something and trust it.

I've got no problem with this old version of Clockgen, pity they changed it.





Ok, nothing is changed but the CPU multi in BIOS.

Here we see a happily priming machine with Large FFT memory test in Orthos (Prime95 re-incarnate)











Here we see a very upset machine, not happy AT ALL!

Note Vcore, not max temps, as the temps haven't had a chance to rise, the failure was almost immediate, this was actually the second test, I was trying to capture the temps at fail. The first test failed at 7 seconds and I didn't get the cpu temp in time, but it doesn't really matter, we have Vcore in Everest to verify Vcore is not being twiddled with. Everest will show Vcore changes readily with it's steady probing.





You can clearly see that Vcore is constant and I use no software like cool and quiet and my power options in windows is "Always On". This machine is always left on at max stable clocks with no throttling of any sort.





9x multi doesn't offend Orthos, just decrease HTT and it primes fine.....




Many overclockers who first set the guidelines for clocking A64's on socket 939 believed that half multi's were a cause of instability, I always refuted this myself, but now I wonder if they were seeing the effects of something else as well.

Note the text area in Orthos in this last pic, confirming that Orthos still sees the original boot speed even though the app is re-started, thus giving away the fact that HTT was adjusted in Windows (Clockgen) for this final test. (Test terminated early, point made).

I can't figure it out, seems my system at least likes things in sync.......... errata ?

[Nick N]

The memory tab is important because it will show the ratio and confirm it

Clockgen shows it, but I know, you get familiar with something and trust it. I've got no problem with this old version of Clockgen, pity they changed it.

Ok, nothing is changed but the CPU multi in BIOS.

Here we see a happily priming machine with Large FFT memory test in Orthos (Prime95 re-incarnate)




Here we see a very upset machine, not happy AT ALL!

Note Vcore, not max temps, as the temps haven't had a chance to rise, the failure was almost immediate, this was actually the second test, I was trying to capture the temps at fail. The first test failed at 7 seconds and I didn't get the cpu temp in time, but it doesn't really matter, we have Vcore in Everest to verify Vcore is not being twiddled with. Everest will show Vcore changes readily with it's steady probing.



You can clearly see that Vcore is constant and I use no software like cool and quiet and my power options in windows is "Always On". This machine is always left on at max stable clocks with no throttling of any sort.

9x multi doesn't offend Orthos, just decrease HTT and it primes fine.....




Many overclockers who first set the guidelines for clocking A64's on socket 939 believed that half multi's were a cause of instability, I always refuted this myself, but now I wonder if they were seeing the effects of something else as well.

Note the text area in Orthos in this last pic, confirming that Orthos still sees the original boot speed even though the app is re-started, thus giving away the fact that HTT was adjusted in Windows (Clockgen) for this final test. (Test terminated early, point made).

I can't figure it out, seems my system at least likes things in sync.......... errata ?

Something is rotten in Denmark

I love the fact that a setting of 280, DDR560 in the BIOS nets a reading of 280.9 or DDR562


I still can not rule out some type of Vcore drop being enabled by the multiplier.. AND the FSB you may not be overcoming with the limits you have on your system.

The table that works all that is not locked to just the multiplier. It can be lockled to a multiplier -and- a scale in FSB.

(9x)= var1

[congo]

I always thought that the clocks were ramped up slightly by manufacturers so the boards would show a slight advantage in the THG Reviews etc. (which is just stupid)

However, I just assumed the slight skew was due to a single tweak that applied the skew to any speed chosen, almost as if they somehow got the crystal occillator buzzing a bit quicker. (though I realise this is improbable if not impossible) From what you are saying this is not the case and the clocks are tampered with on a much broader scale

[Nick N]

[quote]I always thought that the clocks were ramped up slightly by manufacturers so the boards would show a slight advantage in the THG Reviews etc. (which is just stupid)

However, I just assumed the slight skew was due to a single tweak that applied the skew to any speed chosen, almost as if they somehow got the crystal occillator buzzing a bit quicker. (though I realise this is improbable if not impossible) From what you are saying this is not the case and the clocks are tampered with on a much broader scale

[congo]

In answer to the last question, it was my notion, (from reading the supplied information on "prime95" some time ago) that Orthos and it's predecesors simply calculated mercienne prime numbers and looked for errors in the math, the purity of the calculation and the stress imposed on the system made this an ideal stress test for

[Nick N]

[quote]In answer to the last question, it was my notion, (from reading the supplied information on "prime95" some time ago) that Orthos and it's predecesors simply calculated mercienne prime numbers and looked for errors in the math, the purity of the calculation and the stress imposed on the system made this an ideal stress test for

[congo]

Am I to assume you never installed the AMD processor driver for the Sandy from this page?

Yes, that is correct unless I did it by accident using some other software package.

I'm trying to find out how to see if

[Nick N]

Am I to assume you never installed the AMD processor driver for the Sandy from this page?

Yes, that is correct unless I did it by accident using some other software package.

I'm trying to find out how to see if

[congo]

Doh! I checked system devices before, dunno why I didn't open up the processor driver

1/04/2004 is the date so I guess not.

Update: With the 9x multi at 280mhz....

FS9 gave me a system freeze before the menu appeared.

FAr Cry crashed about two minutes into the game, total lockup.

IL2FB failed to load, no lockup until I shutdown to reboot , then the system bluescreened.



I set 10x cpu multi and repeated the tests, all the software functioned normally and I am still here typing.


Ok, Next I installed the processor driver you linked above, cool and quiet is disabled, I still get the same results.
____________________________


In this next test we see a 9.5x cpu multi set in bios with 295HTT giving us our 280mhz memspeed. This primed stable for 10mins and the test was terminated. So it looks like the ratios have nothing to do with this and it is a problem with the 9x cpu multiplier.

Note that Vcore is reduced. Everest and CPUz both poll the Vcore regularly and they are not in sync, so different values are displayed here during the phase where their display is out of sync. The Vcore variation every several seconds is typical on this system.