I think this though is the final solution to Eileen-II's temperature issues.
First, let me put up the final numbers, then I will do the explanation:
All that work meant that the peak temperature of Eileen-II's CPU never exceeded 85°C.
That is all well and good, but as I continued to use Eileen-II, I realised that I was losing some performance from the lack of hyperthreading. Specifically, the benchmarking from WinRAR under multi-threaded computation was giving me a rough throughput of 7 MB/s. It is definitely faster than the 4 MB/s processing speed of Edythe-III, but is actually quite bad, especially since I seem to be operating on RAR files pretty often (in the form of archiving e-books, and compiling comic book archives from web comics).
I remembered that with hyperthreading on, I was getting more than 10 MB/s of processing, or something like 14 MB/s, if memory serves me well---this is anything from 42% to 100% improvement over no-hyperthreading (I'm not much of a speed demon and am not really going for something super rigorous, and so a rough ballpark is good enough for me).
With the system relatively stable, and me getting rather bored(!) at 0000hrs in the morning, it is back to more recalibration to squeeze more output.
I turned on hyperthreading from the BIOS, and proceeded with the same methodology as before. Since I was about to load my processor with about 100% more load, it seemed prudent to undervolt as much as I can to reduce the initial pre-stress thermal load as possible. I started at −90.8 mV as it was, and gradually lowered it by 1 mV for both CPU Core and CPU Cache, waiting each time for a lowered idle CPU use to drop the voltage enough to test for stability---remember that when undervolting the CPU, we are finding the lowest effective voltage that does not stall the CPU.
I managed to lower it as low as −98.8 mV, however, the results were unstable, with the screen flickering when the voltage dipped low enough to ``stun'' the CPU into cranking its voltage higher up. Getting low-enough idle CPU use with hyper-threading on was very finicky and hard, and it was at −99.8 mV when I hit my first blue screen of death. It was funny, because the main display was showing the blue screen, while the side display [that I use for reading PDFs---see this earlier entry for details of that display] was still showing the desktop background.
When I finally rebooted Eileen-II, I noped out and just cranked the offset voltage to −92.8 mV, a number that I was confident that would not allow the lowest voltage of the CPU to drop below 0.5 V---I noticed that when the voltage dropped lower than 0.5 V was when the screen flickering would start and things would Get Weird.
Armed with that new offset voltage, I started up the stress tester and ran the same protocol. With the original turbo ratio limits, I was (as expected) getting very high spike temperatures in the 90+°C range. And so, I used the same protocol as before to fine tune the ratios for the n hottest physical cores, for n in 6 to 1.
Due to hyperthreading being turned on, I needed to alter the protocol a little, and adjust the affinities by the pairs of logical CPUs that would run on a physical Core. Thankfully, the formula relating them is straightforward enough. Each time after tuning, I would just take away the two logical CPUs for the coolest physical Core in the affinity, and rinse/repeat.
The final turbo ratio limits were [37×,34×,32×,31×,29×,28×]. On average, I would be taking away anything between 1× to 3× from the original no-hyperthreading tuned ratios.
It sounds like I have reduced my CPU's capabilities through all these lowered ratios, but really I haven't, since hyperthreading meant that I was getting double the number of processing cycles per active physical Core. Take 6 active cores for example. Without hyper-threading, the total work done in ratio of base clock speed is 6 by 30×, which is 180×. With hyper-threading, the total work done in ratio of base clock speed is now 12 by 28× which is 336×, which is about 87% more available raw clock cycles in comparison to being without hyper-threading, with similar thermal loads (≤85°C). Of course, hyper-threading doesn't quite work that way since there is an actual overlap from synchronisation issues of hyper-threaded CPUs that share the same physical Core, but the point remains that I am increasing the total available capacity for the given generated thermal load despite having lowered turbo ratios.
Oh, and all these led to WinRAR benchmarking at about 13 MB/s compared to 7 MB/s, an overall 86% increase in throughput between no-hyperthreading and with hyperthreading. So, it is more performance overall, in the multi-threaded case.
Definitely a win in my book. By the time I was done, it was already 0145hrs...
------
In other news, I had finally updated my LilyPond installation from v2.20.0 to v2.22.0. The reason for the delay was waiting for Cygwin version to be updated first before updating the tooling for my Windows version that I use with Frescobaldi for music writing. The reason for that is due to my auto-building scripts being designed to run under Cygwin or Linux.
Well, v2.22.0 broke all my sources for v2.20.0/v2.18.0. Reading the changelog revealed that a couple of features that I used, namely \compressFullBarRests and \partcombine, had been renamed to \compressEmptyMeasures and \partCombine respectively, with no real backward compatibility despite the existence of the \version statement.
It was a straightforward enough fix, and I completed it using my favourite combination of
find -type f -iname '*.ly' -print0 | \ xargs -0 sed -e 's/\\partcombine/\\partCombine/g' -iNo biggie, but it was something that needed to be done.
Alright, that's about all that I have to write for now. Till the next update.
No comments:
Post a Comment