Brisbane and CrystalCPUID: Attaining stability
Moderators: NeilBlanchard, Ralf Hutter, sthayashi, Lawrence Lee
-
- Friend of SPCR
- Posts: 118
- Joined: Wed Jul 04, 2007 3:29 pm
- Location: Lost and Found Bin, Cypress, CA, USA
- Contact:
Brisbane and CrystalCPUID: Attaining stability
This is long overdue, but I finally have a long enough break in my school/work schedule to post this. I've been searching for stability since the day I built what has become my current primary computer. It started out with a Brisbane core Athlon 64 X2 3600+ last June (Model ADO3600IAA5DL), which had been troublesome from the beginning. At first, it seemed it just wanted more voltage than other G1 stepping 3600+ users have reported (1.075V @ 1.9GHz). I was finally to the point where it was stable for 8+ days between reboots (self-initiated and planned, as I just like to refresh Windows every once in a while), when suddenly everything went downhill. I was lucky to get an hour between random freezing and reboots. Then it began corrupting Windows files. Exhaustive runs of Orthos, Memtest86, swapping out components, etc. yielded nothing.
I finally broke down and bought a new G2 stepping 2.8 GHz Brisbane Athlon X2 5400+. First of all, as one would expect, it is a darned good undervolter. It will run at 1.2 GHz at the lowest available VID, 0.775V, which is so low that it isn't even an option in Crystal's drop-down voltage menus! So I've been playing with Crystal's options, trying to find stable settings for everyday use, and it seems we have a winner. I've hit the 8 day mark with these current settings, though I didn't push further. The last settings hit a wall just past the 7 day mark, so there's a chance that this may still not be stable for people who expect their computers to run for weeks on end without rebooting. Anyway, on with the show...
(click on the thumbnail for full size)
As you'll notice, the selection for the minimum voltage is blank, as I'm using a value outside of the defined GUI menu. the VID for 1.550V is V1, and goes down in 0.025V increments to V30=0.800V and V31=0.775V. It seems to ignore anything lower. From what I have seen, the 45W BE-2XXX and 4X50e processors will have different VID tables, so your values will vary. I don't think the Dual Wait Time has any effect, but it ended up set to 100ms, so I think it's fine to leave it. My processor still throttles very quickly, though it must be said, not as quickly as my laptop's Turion MT-40. RMClock runs that from 800MHz to 2200MHz in 100MHz steps without missing a beat. *sigh*
If I forgot anything, let me know. I'd probably post more often, but I tend to turn these things into novels. It's a blessing and a curse. Mostly the latter.
I finally broke down and bought a new G2 stepping 2.8 GHz Brisbane Athlon X2 5400+. First of all, as one would expect, it is a darned good undervolter. It will run at 1.2 GHz at the lowest available VID, 0.775V, which is so low that it isn't even an option in Crystal's drop-down voltage menus! So I've been playing with Crystal's options, trying to find stable settings for everyday use, and it seems we have a winner. I've hit the 8 day mark with these current settings, though I didn't push further. The last settings hit a wall just past the 7 day mark, so there's a chance that this may still not be stable for people who expect their computers to run for weeks on end without rebooting. Anyway, on with the show...
(click on the thumbnail for full size)
As you'll notice, the selection for the minimum voltage is blank, as I'm using a value outside of the defined GUI menu. the VID for 1.550V is V1, and goes down in 0.025V increments to V30=0.800V and V31=0.775V. It seems to ignore anything lower. From what I have seen, the 45W BE-2XXX and 4X50e processors will have different VID tables, so your values will vary. I don't think the Dual Wait Time has any effect, but it ended up set to 100ms, so I think it's fine to leave it. My processor still throttles very quickly, though it must be said, not as quickly as my laptop's Turion MT-40. RMClock runs that from 800MHz to 2200MHz in 100MHz steps without missing a beat. *sigh*
If I forgot anything, let me know. I'd probably post more often, but I tend to turn these things into novels. It's a blessing and a curse. Mostly the latter.
i guess cpus really are just luck of the draw, my 3600+ brisbane is set to 1.0ghz @0.8V and 1.9ghz @0.975v (dual prime stable).
i've never had trouble with it, i think the most i've ever left it on was maybe 3 odd weeks?
you never mentioned whether or not you tested for stability- if you have, it's rather strange that you'd have problems with leaving it on for large amounts of time.....hmmmm.
well, good luck anyways
i've never had trouble with it, i think the most i've ever left it on was maybe 3 odd weeks?
you never mentioned whether or not you tested for stability- if you have, it's rather strange that you'd have problems with leaving it on for large amounts of time.....hmmmm.
well, good luck anyways
-
- Friend of SPCR
- Posts: 118
- Joined: Wed Jul 04, 2007 3:29 pm
- Location: Lost and Found Bin, Cypress, CA, USA
- Contact:
Yes, I did test for 48 hours on Orthos (AKA dual prime) for all the voltages I'm currently using. The strange part is that I would sometimes get errors after 8+ hours with the 3600+. With this G2 5400+, if it didn't get an error within the first 10 minutes, it ran 48 hours every time.
One thing that makes me wonder is that my 3600+ had an OPN ending in DL, while most of the ones I've come across since have been DD like the rest of the G1 Brisbanes. Does anyone else want to chime in with what their 3600+ is? I know it won't really change anything, but I'm still curious about it.
One thing that makes me wonder is that my 3600+ had an OPN ending in DL, while most of the ones I've come across since have been DD like the rest of the G1 Brisbanes. Does anyone else want to chime in with what their 3600+ is? I know it won't really change anything, but I'm still curious about it.
Re: Brisbane and CrystalCPUID: Attaining stability
Thanks for the post! I'm putting my vote in for the novel.RedAE102 wrote:If I forgot anything, let me know. I'd probably post more often, but I tend to turn these things into novels. It's a blessing and a curse. Mostly the latter.
Can you explain the reasons for the changes you made from default?
For example, did the default CrystalCPUID settings cause problems for you, or did you make the changes for optimization reasons?
-
- Friend of SPCR
- Posts: 118
- Joined: Wed Jul 04, 2007 3:29 pm
- Location: Lost and Found Bin, Cypress, CA, USA
- Contact:
Re: Brisbane and CrystalCPUID: Attaining stability
In a word: instability. Freezing immediately followed by a drab diagonal pattern of grays seems to be the most common method of death. Before, it also included random reboots and BSODs, but those usually came after much less downtime. I just kept playing with settings until I find something that works. So far, so good.davidh44 wrote:Thanks for the post! I'm putting my vote in for the novel.
Can you explain the reasons for the changes you made from default?
For example, did the default CrystalCPUID settings cause problems for you, or did you make the changes for optimization reasons?
And it's good to know I'm not wasting words by typing a bunch of mumbo jumbo that no one will read.
Re: Brisbane and CrystalCPUID: Attaining stability
I definitely appreciate your insights . Especially after spending a week going nuts trying to get RMClock to run stable (don't know why it never occurred to me during that time to try CrystalCPUID instead).RedAE102 wrote:In a word: instability. Freezing immediately followed by a drab diagonal pattern of grays seems to be the most common method of death. Before, it also included random reboots and BSODs, but those usually came after much less downtime. I just kept playing with settings until I find something that works. So far, so good.davidh44 wrote:Thanks for the post! I'm putting my vote in for the novel.
Can you explain the reasons for the changes you made from default?
For example, did the default CrystalCPUID settings cause problems for you, or did you make the changes for optimization reasons?
And it's good to know I'm not wasting words by typing a bunch of mumbo jumbo that no one will read.
Were all of your changes mandatory to get it to run stable? Or were some of them personal preference? Like increasing the thresholds...was that for power savings or stability? Or lowering the interval times to 400ms...as I would think increasing them would actually increase stability?
Seems like a later revision of the G1 stepping?RedAE102 wrote:One thing that makes me wonder is that my 3600+ had an OPN ending in DL, while most of the ones I've come across since have been DD like the rest of the G1 Brisbanes. Does anyone else want to chime in with what their 3600+ is? I know it won't really change anything, but I'm still curious about it.
I have a couple BE-2300's which are basically 3600+ binned for lower voltage. And with those, DD = G1 stepping & DO = G2 stepping.
By the way, what's the difference between "interval time" and "wait time" in CrystalCPUID?
-
- Friend of SPCR
- Posts: 118
- Joined: Wed Jul 04, 2007 3:29 pm
- Location: Lost and Found Bin, Cypress, CA, USA
- Contact:
Re: Brisbane and CrystalCPUID: Attaining stability
Well for me, I "default" to the lower, faster settings and work up from there. I started out with 100ms interval times and 0ms wait times since that's what I used on my laptop when I was still running CrystalCPUID on there. Since there's some unpredictability as far as how a single threaded process will stress a dual core, I selected the switch trigger as the maximum to minimise the possibility that it would switch to a lower speed when one of the cores' loads was still too high to make the transition stably. I could select lower thresholds, but I try to strike a balance between throttling up for every little thing and staying stuck on low for all but the most demanding tasks. So basically, if you count the minimum settings as default, yes, everything but the thresholds were mandatory for stability in my case. And unfortunately, I don't really understand the difference between interval time and wait time in CrystalCPUID. I only know what worked for me.davidh44 wrote:Were all of your changes mandatory to get it to run stable? Or were some of them personal preference? Like increasing the thresholds...was that for power savings or stability? Or lowering the interval times to 400ms...as I would think increasing them would actually increase stability?
On this same note, as I mentioned in another thread, I cannot get RMClock stable on my friend's laptop either. It runs the Brisbane's mobile sister, a 65nm Tyler core Turion X2 TL-56 1.8 GHz. Another friend's 90nm Taylor Turion X2 TL-52 notebook suffers no instability running RMClock, nor does yet another's Windsor Athlon 64 FX-62 desktop. So it stands to reason that whatever changes that made the Brisbane unstable in transitions are shared with the 65nm Tyler Turions.
And regarding OPNs, my 3600+ ending in DL seems to be one of the earliest ones, with the 3600+ DD arriving later with the rest of the G1s.
It's the motherboard. When I encountered this problem I assumed motherboard. The chipset is a major culprit. We've got to start making notes on the chipset that a Brisbane is stable with. (It's the only way to explain why the 690G on the M2A-VM becomes horrendously unstable when you add proper ATI drivers.)porkchop wrote:i guess cpus really are just luck of the draw, my 3600+ brisbane is set to 1.0ghz @0.8V and 1.9ghz @0.975v (dual prime stable).
i've never had trouble with it, i think the most i've ever left it on was maybe 3 odd weeks?
I have to buy some stuff in the next day, or I'll never buy it, so I'll try an Abit or Asrock with the 630A. See if I can get the first computer below 20W! It will be hard, because I'll be using WDC Greenpower, and a real ammeter, not this Kill-a-watt rubbish
*Tinks* I wonder if it's an integrated chipset problem. We're all using them and thinking that's normal. The GPU is competing with the CPU, and management is done by the CPU.
Re: Brisbane and CrystalCPUID: Attaining stability
I've been running on the default CrystalCPUID settings (except for voltage and multiplier of course) for 1 week now with two different Brisbane BE-2300's, and they have both been stable. The same multiplier/voltage settings with RMClock would cause a selection of reboots/freezes/BSODs.RedAE102 wrote:Well for me, I "default" to the lower, faster settings and work up from there. I started out with 100ms interval times and 0ms wait times since that's what I used on my laptop when I was still running CrystalCPUID on there. Since there's some unpredictability as far as how a single threaded process will stress a dual core, I selected the switch trigger as the maximum to minimise the possibility that it would switch to a lower speed when one of the cores' loads was still too high to make the transition stably. I could select lower thresholds, but I try to strike a balance between throttling up for every little thing and staying stuck on low for all but the most demanding tasks. So basically, if you count the minimum settings as default, yes, everything but the thresholds were mandatory for stability in my case. And unfortunately, I don't really understand the difference between interval time and wait time in CrystalCPUID. I only know what worked for me.davidh44 wrote:Were all of your changes mandatory to get it to run stable? Or were some of them personal preference? Like increasing the thresholds...was that for power savings or stability? Or lowering the interval times to 400ms...as I would think increasing them would actually increase stability?
On this same note, as I mentioned in another thread, I cannot get RMClock stable on my friend's laptop either. It runs the Brisbane's mobile sister, a 65nm Tyler core Turion X2 TL-56 1.8 GHz. Another friend's 90nm Taylor Turion X2 TL-52 notebook suffers no instability running RMClock, nor does yet another's Windsor Athlon 64 FX-62 desktop. So it stands to reason that whatever changes that made the Brisbane unstable in transitions are shared with the 65nm Tyler Turions.
And regarding OPNs, my 3600+ ending in DL seems to be one of the earliest ones, with the 3600+ DD arriving later with the rest of the G1s.
I just purchased a couple laptops with Tyler X2 TK-57 chips (Turion with half the cache), and think I'll just go straight to CrystalCPUID for those. Any reason you prefer RMClock if it's stable?
Re: Brisbane and CrystalCPUID: Attaining stability
I tried RMClock on my 65nm Tyler core Turion X2 TK-57 1.9Ghz, and can confirm it is unstable when using dynamic P-states. And CrystalCPUID only goes down to 0.775v like you mentioned in your first post. Kind of a bummer, as I can go down to 0.6875v 4x with this chip.RedAE102 wrote:On this same note, as I mentioned in another thread, I cannot get RMClock stable on my friend's laptop either. It runs the Brisbane's mobile sister, a 65nm Tyler core Turion X2 TL-56 1.8 GHz. Another friend's 90nm Taylor Turion X2 TL-52 notebook suffers no instability running RMClock, nor does yet another's Windsor Athlon 64 FX-62 desktop. So it stands to reason that whatever changes that made the Brisbane unstable in transitions are shared with the 65nm Tyler Turions.
I've been having stability issues trying to use RMClock on my 780G-based board. This is with a Windsor-based core though, not Brisbane. What's weird is that it worked fine for two or three weeks, happily watching multi-hour movies, etc., throttling up and down to it's little hearts content (bless).
Then a couple of weeks ago... blammo the silly thing wouldn't last for more than a minute or two after RMClock started. Hadn't fiddled with the settings, no nuffink guv. Weird. I'm running CrystalCPUID at the moment but I miss the configurability and monitoring of RMClock. Grrr.
Then a couple of weeks ago... blammo the silly thing wouldn't last for more than a minute or two after RMClock started. Hadn't fiddled with the settings, no nuffink guv. Weird. I'm running CrystalCPUID at the moment but I miss the configurability and monitoring of RMClock. Grrr.
It could also be the voltage regulators of the motherboard that are not stable enough to cope with fast phase transitions.
Read my experience at the bottom.
viewtopic.php?t=47659
I hope this will help.
Regards.
Edwin.
Read my experience at the bottom.
viewtopic.php?t=47659
I hope this will help.
Regards.
Edwin.
I've been testing my new system a few days for stability with rmclock (m2a-vm hdmi + 4850e + picoPSU, good undervolting but crashes ). The issue seemed to be switching states.
Then this topic came up.
I tried crystalcpuid and I confirm that seems to solve the issue (I want to test more throughly, though). This tool can make it jump from top (2.5GHz @1.250V) to bottom (1.0GHz @0.800V) and back again in a single step and at full load without problem. I tested almost every "edge state" I found before without a crash.
Well, I had a crash... trying to use 4.0x multiplier
Thanks again.
Then this topic came up.
I tried crystalcpuid and I confirm that seems to solve the issue (I want to test more throughly, though). This tool can make it jump from top (2.5GHz @1.250V) to bottom (1.0GHz @0.800V) and back again in a single step and at full load without problem. I tested almost every "edge state" I found before without a crash.
Well, I had a crash... trying to use 4.0x multiplier
Thanks again.
I was getting instability to with my GA-MA78GM-S2H (rev 1) and x2 4050e. What i noticed in the Bios settings was that under the multiplier settings, it only went up to 10. But the 4050e's max multiplier was 10.5. So, in RMclock, i just set my max pstate at 10x instead of the 10.5x. By doing this, my computer has been rock solid and undervolted .95v at all pstates.
I guess i could go lower, but i haven't had the time to test out anything lower than .95v
I guess i could go lower, but i haven't had the time to test out anything lower than .95v
Brisbane G1 steppings had the 4x multiplier, but they made the minimum 5x with the G2 stepping.kickaha wrote:I've been testing my new system a few days for stability with rmclock (m2a-vm hdmi + 4850e + picoPSU, good undervolting but crashes ). The issue seemed to be switching states.
Then this topic came up.
I tried crystalcpuid and I confirm that seems to solve the issue (I want to test more throughly, though). This tool can make it jump from top (2.5GHz @1.250V) to bottom (1.0GHz @0.800V) and back again in a single step and at full load without problem. I tested almost every "edge state" I found before without a crash.
Well, I had a crash... trying to use 4.0x multiplier
Thanks again.
It's definitely the p-state transitions that cause instability with RMClock. If you're using voltages that are compatible with all p-state transitions, then you'll be OK. Otherwise, you'll experience random crashes.
CrystalCPUID, on the other hand, handles p-state transitions much better with these Brisbane CPUs, and is definitely the way to go.
No, sorry, it was just my fault. I left HyperTransport set to 1GHz.davidh44 wrote:Brisbane G1 steppings had the 4x multiplier, but they made the minimum 5x with the G2 stepping.
With HT set to 800MHz I can use 4x multiplier. Too bad this motherboard can't go below 0.800V...
Anyway, I had not a single failure since I use Crystal.
CrystalCPUID can set only voltages, allowed by AMD. Does ADO5400IAA5DO support such a low voltage, 0.775V? For my ADO4600IAA5CU the lowest is 1.1V.
Wait time is time between multiplier and voltage changes. Perhaps not. Do not know what the dual wait time is.
DD and DL are probably the same, just the voltages differ a little:
ADO3600IAA5DD 1.2V 1.250V 1.3V
ADO3600IAA5DL 1.2V 1.3V 1.35V
Min P-State is 1.1V, again, could you set 1.075V ? Usually AMD does not want us to go lower than min P-State (Voltage in motherboard's BIOS is another thing).
Wait time is time between multiplier and voltage changes. Perhaps not. Do not know what the dual wait time is.
DD and DL are probably the same, just the voltages differ a little:
ADO3600IAA5DD 1.2V 1.250V 1.3V
ADO3600IAA5DL 1.2V 1.3V 1.35V
Min P-State is 1.1V, again, could you set 1.075V ? Usually AMD does not want us to go lower than min P-State (Voltage in motherboard's BIOS is another thing).
I changed the motherboard. I can set 0.8V now (but not lower). I use two states, 0.8V 5x and 1.2V 12x. Computer hangs with three states (did not hang with the first MB).
One more MB, goes down to 0.775V (not lower), no hangs.
One more MB, goes down to 0.775V (not lower), no hangs.
Last edited by Klusu on Mon Jul 13, 2009 9:38 pm, edited 1 time in total.
-
- SPCR Reviewer
- Posts: 1115
- Joined: Fri Mar 04, 2005 9:07 pm
- Location: Vancouver
Just a note to everyone that changing your multiplier can also change your memory speed. Even multipliers should result in the fastest RAM speeds, but most of the 65nm chips run at odd or fractional multipliers by default. So you may end up making your memory unstable with your settings. Just checking for CPU stability with Orthos is not enough.b0yoo511 wrote:What i noticed in the Bios settings was that under the multiplier settings, it only went up to 10. But the 4050e's max multiplier was 10.5. So, in RMclock, i just set my max pstate at 10x instead of the 10.5x. By doing this, my computer has been rock solid and undervolted .95v at all pstates.
-
- Posts: 42
- Joined: Mon Apr 10, 2006 6:04 pm
- Location: Montreal, Canada
Actually, RMClock will cause my system (Brisbane G2 +780G) to hang, especially when standing by, even if I use a fixed Vcore in the BIOS corresponding to my highest multiplier. So it might be the p-state transitions causing issues, but it is not related to voltage.davidh44 wrote:Brisbane G1 steppings had the 4x multiplier, but they made the minimum 5x with the G2 stepping.kickaha wrote:I've been testing my new system a few days for stability with rmclock (m2a-vm hdmi + 4850e + picoPSU, good undervolting but crashes ). The issue seemed to be switching states.
Then this topic came up.
I tried crystalcpuid and I confirm that seems to solve the issue (I want to test more throughly, though). This tool can make it jump from top (2.5GHz @1.250V) to bottom (1.0GHz @0.800V) and back again in a single step and at full load without problem. I tested almost every "edge state" I found before without a crash.
Well, I had a crash... trying to use 4.0x multiplier
Thanks again.
It's definitely the p-state transitions that cause instability with RMClock. If you're using voltages that are compatible with all p-state transitions, then you'll be OK. Otherwise, you'll experience random crashes.
CrystalCPUID, on the other hand, handles p-state transitions much better with these Brisbane CPUs, and is definitely the way to go.