When CPU load decreases dramatically, RMClock v.2 will, regardless of setting, drop FID/VID dramatically for a moment. If, for example, you're browsing the internet using the "on demand" setting and as you scroll quickly, IE requires 1.2 GHz. When you stop scrolling, RMClock v.2 throttles back FID/VID because the demand is less. Say, however, you had locked in your FID/VID because you were using another profile, say, max. performance. Say you had locked in your max performance at 1.2GHz. The same thing would happen, even though your FID/VID is supposed to be locked.
What does this mean? It is possible that when using "on demand" and doing tasks that cause CPU load to change dramatically moment to moment, RMClock2 is accidentally dropping FID/VID below safe levels causing our computers to crash.
I tested this by locking RMClock2 at various speeds ranging from 1.2GHz to 2.0GHz and then quickly start/stopping Prime95 torture test. I noticed that as I quickly stopped the test, FID/VID would sometimes drop dramatically all the way down to 800MHz before going back to whatever speed I had locked it at. Now, if in real conditions you were at "on demand" it's possible that RMClock2 would allow FID/VID to dip below 800MHz and cause the system to crash OR that the dramatic jumps in FID/VID caused by RMClock2 made the system unsable. The CPU clock speed would change because both FID/VID changed together.
RMClock 1.8 was in my testing stable because regardless of task (testing in Prime95 start/stop), the FID/VID remained at the levels I selected.
RMClock 1.8 avoids the problems of 2.0 because it drops FID before dropping VID under similar conditions. Therefore, it's possible to be have [email protected] the moment before [email protected], but the clock speed will not change. This also means that it's less likely to cause your CPU to become power-starved as it transitions to a lower p-state.
Cliff notes: There is a bug in RMClock 2.0
-
hm interesting suggestion, I will look at it when I get home. Did you try RMclock 2.05, the latest version?
-
So, that answer to that question should be yes -
I just started playing with RMclock last night with my new V2000Z (ML-37) and I noticed a similar thing. When looking at the monitor screen of RMclock where it shows the time history graph of voltage and multiplier, it seemed like there were wierd spikes even when I had it set to performance on demand but only one state defined (for testing). The FID/VID shouldn't ever change in this case, but there were spikes occasionally.
This is with 2.05. I thought that I had read somewhere (maybe from chinna in the other thread) that v2 was better than v1.8 because of less crashing during transitions... now it is possible that actually the opposite is true? -
Glad you've noticed this too. -
I have been using 2.05 for a while with my ML-37, ( I used 1.8 as well). I never even once had any instability issues with either of the versions.
In 2.05, they have stabilization voltage, that is it applies more than we specify in VIDs( like for ex for 0.95v it gives 1.00, then drops to 0.95v volts when things stabilized).
I like 2.05 for it's multiple Profiles and settings, eps having ability to define different P-States for AC and battery,as well as Power Saving/performance profiles.
As per the aborted transitions, yes, it is the same case even with 1.8. If you monitor graph. Some are about the transition, but are aborted because load dropped instantly.
If just observed graphs with some dynamic loading, and see it is appropriately changes VID and FID and both are properly synched. Infact VID dropping is little( very little) later than FID dropping.
So, I have not see any issue as such. May be, May be, 1.8 applies voltage much prior to FID, I am not sure. But anyways, if you go to the advanced Tab in 2.05, in the P-State Transition settings, you have all those options, including stabilization timings.
Also, another note, may be you are at border for your CPU voltages. Add 0.025v for stable Prime voltage for stability during transition for any version as recommended. -
So far, I didn't see any runtime unstable happen for my v2.05 RMClock.
Occationally, machine freezed on standby, but nothing wrong with runtime. I stopped using IE after download Firefox. For me, IE is just one time tool to download Firefox. Is this the reason? I don't know. -
RM clock 2.0 was not stable on my ML-30. Went back to 1.8
-
2.05 have been 100% stable on my ML32.
-
Looks like 2.0 has some issues and that is the reason author quickly released 2.05 with fixes. So use 2.05, not 2.0.
I've figured out why RMClock v. 2 is less stable than v. 1.8
Discussion in 'HP' started by hegemon, Mar 30, 2006.