HYDRA 1.0D PRO - BIG CHANGES (Patreon)

I have analyzed most of your posts and decided to change my approach to frequency management. Since we get CO values during super-heavy loads, it would be partly a mistake to use these values for lighter loads. In the past to get higher in the light load we were forced to increase the CO, thus making AVX2 and FMA3 unstable. Some of you had no problems with this action because you did not use heavy tests and loads. In order to get the cherry on the cake, I add new frequency controls: AVX1 CO offset for MT and AVX1 CO offset for LT. This means that you can adjust the frequency for light loads separately and it will not affect the stability in super heavy loads. The offset for the left and right table is individual, this will allow more flexibility.

Next I would like to tell you about cores activity triggers. The low threaded load and the multithreaded load now have different triggers. For multithreaded load C0, for example, the state is only 30%, and for low-threaded load it is 85%. The point of this idea is to "catch" the moment when Windows wakes up all cores for multi-threading in advance, and the faster will be turn on the right profile, the higher is the stability of the system. For low-threaded load trigger has a very high value - this is done to enable profile only when the system is sure that a certain number of cores are required for the task.

The profile holding system against false profile switching has also changed. The probability of switching from low-threaded profile to multithreaded one is now 2 times higher. In other words, if there is a "surge" of more serious load in the system, a small-threaded profile will be switched off faster. Of course if there is already a heavy load in the system, but there are CPU dips, HYDRA will keep the multi-threaded profile active for a while to make sure the system does not need the current profile.

You might think that this would have a negative effect on perfomance - it doesn't. The profile holding time is only a few tens of milliseconds. This is quite enough to smooth out load spikes and switch profiles that match the load.

Another rule is that if the profile is held in a light load state, but a heavier load occurs, the holding will also disconnect twice as fast, regardless of the number of threads used.

A significant change will also be the work in a low-thread load. Now cores with low activity are blocked at -1000 MHz in order to reduce Vdroop in case of serious load and to be independent from other cores which have lower operating frequency. Something similar was implemented in CTR 2.1 RC5 ver.24.

The frequency ramp function is now deprived of the ability to "jump" to the maximum frequency on each cycle after receiving data from the processor. The reason is simple - we change the frequency only after receiving the monitoring data, so "jumping" is too dangerous, because during the maximum frequency ramp up the load level can increase and the system will crash. The step-by-step algorithm proved to be preferable and more stable, while the performance is not lost, since the frequency ramp up even in this way is done in a few tens of milliseconds.

I also noticed that the FMA3 profile is turned on too often and where it is not always needed. This has also been corrected.

The third-party library LibreHardwareMonitorLib.dll (is used for monitoring the GPU), which was constantly slowing down the execution of SMU commands and regularly waking up the cores, was substantially improved.

The last significant improvement was diagnostics. Now you can do CORE CO and CCD CO searches for your custom VIDs. This will create profiles more unique to your system.

About the timing of the release. At this point, I have finished making changes and have begun testing. Tentatively the release will be at the weekend.

________________________

What else awaits us this month.

An active process masking system is in development to fix the use of bad CPPC cores. The user will independently specify the numbers of the priority cores to perform a low-priority load.

The second important new feature is a pre and post optimization comparison mode. Comparison of PPT, VID and performance. The test package will be CB23.