I've played with this for a bit... In the hardware, there are two mechanisms that you can use, one or the other or both at the same time for maximum effect - in Intel CPU's of a certain era:
1) EIST aka P-states This allows you to configure the CPU clock multiplier. Multiplier * reference clock = CPU core clock. The range for a 1.6 GHz ATOM might be something like 800 to 1600 MHz, multiplier 8 to 16 times a basic refclock of 100 MHz. https://support.fccps.cz/industry/pwr/p-states.htm#pstate 2) throttling aka T-states Say you have tuned down the P-state to 800 MHz, and you could still do with less horsepower / save some more energy. In that case, you may give up "continuous clock" and subject the clock to PWM. The CPU can skip up to about 5 clocks out of every 8. Actually "somewhat newer" Intel CPU's can PWM-throttle (clock-modulate) in 1/16 granularity, rather than the early 1/8. You probably won't be able to reach 1/8 or 1/16. You can try, but the CPU will just ignore requests below some bedrock threshold. https://support.fccps.cz/industry/pwr/p-states.htm#tstate Both these mechanisms get tweaked by Model-Specific Registers, using two instructions: wrmsr (write) and rdmsr (read). Particular "pokes" into the classic MSR's may work or fail in a particular case, depending on CPU model and BIOS SETUP settings. A tweak to either EIST or throttling takes just a single MSR write. Plus initially some MSR reads, while finding your way around. In the past, I've written some snippets of source code in C that manipulate MSR's related to the PROCHOT status and thermal throttling. I think EIST was not quite a part of that... Unfortunately at that stage I built the whole thing for Windows, using some generic library for HW access... The toolset contains generic programs to read or write a particular MSR. It should not be difficult to port the "project" to DOS, only I don't have the time to do it myselfs :-) https://support.fccps.cz/industry/pwr/bdprochot.htm I recall poking and peeking some MSR's such as IA32_PERF_CTL , IA32_PERF_STATUS and IA32_CLOCK_MODULATION, in DOS, using a program called CPUID by my friend Rayer: https://rayer.g6.cz/programm/programe.htm#CPUID Mind the reference to "wrmsr" in the release notes, on 26.12.2012. Oh I've found this old BAT file: REM permit EIST cpuid wrmsr:1A0:1:1:16 REM underclock the C2D CPU using EIST cpuid wrmsr:199:0800:FF00 Apparently, the multiplier is the second byte from the bottom inside the MSR 0x199 aka IA32_PERF_CTL . Hey I've found one other tool that does wrmsr / rdmsr in DOS : https://www.vogons.org/viewtopic.php?t=96262 If you need more help, ask me. It would take some fumbling in the Intel Architecture programmer's manual (a PDF of a couple thousand pages, but well searchable.) https://www.intel.com/content/www/us/en/developer/articles/technical/i ntel-sdm.html Actually Google can find some past debates about those registers approx. here: https://community.intel.com/t5/Software-Tuning-Performance/How-to-dete rmine-cause-of-processor-frequency-scale-down-to-200/m-p/1137067 https://community.intel.com/t5/Intel-ISA-Extensions/Cannnot-change-IA3 2-PERF-CTL-value-it-gets-overwritten-by-the/td-p/1008971 But it's kinda long and the relevance to your request is low, relevant information is somewhat sparse in that text. I'm aware that there are visually challenged people in this mailing list. If you're one of them, I can help you drill down for a more specific recipe. Frank P.S.: If memory serves, quite a bit of power can be saved nowadays using C-states, irrespective of undeclocking and throttling. But, the C-states mechanism cannot easily be used in DOS, because to enter a C-state, the software must explicitly execute a HALT or MWAIT instruction. (And expect to get woken up again by an interrupt.) Modern operating systems do that / their process scheduler does it (per CPU core) when the system is idle. DOS does not have a preemptive scheduler = your foreground app would have to do this on its own. Maybe the periodic timer IRQ would be enough to wake up the CPU again... I don't know. _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
