undervolting (e.g. skylake) in linux

Hi everyone,
I don't know the best location to post this, so I chose this Forum, as the throttlestop guide is here, too.

How much interest is there in undervolting (e.g. skylake) in linux ?
(Update: ) Seems there is much
For the tl;dr people: read the last paragraph of this post

I like the skylake processors and I'm satisfied with the performance.
Even though sometimes annoying with Intels Bugs (like HT) and no µCode updates from my manufacturer (Asus).
So I'd like to switch finally to Linux, but I also like the improved/lower temperatures through undervolting.

I'm quite annoyed that Intel didn't release the full documentation of the model-specific registers for voltage regulation. (I had a look at Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 4: Model-Specific Registers)

So, there is only Intel XTU or this throttlestop tool and the developer doesn't plan a linux version and doesn't want to share the needed information. (I don't blame him, that he doesn't want to make his program open source). http://forum.notebookreview.com/threads/the-throttlestop-guide.531329/page-608#post-10542530

Anyway, this leads to the following situation:

I informed myself about the current state and possible solutions. As I don't have that much time, my main goal is to find other people, who are intrested in this and we can discuss things and split the workload.

There are only old threads as I found.
http://forum.notebookreview.com/threads/undervolting-the-thinkpad-x120e-in-linux-rev-1.600939/

At least the second part of it is using the linux msrtool:
http://forum.notebookreview.com/threads/throttlestop-for-linux.539117/
So that should be done with some lines of python code, when we have the desired values and know the correct registers.


So my current ideas are:

* Method 1: Full brute force approach:
There are tools like rweverything, msr tool for windows which can read the msr registers (maybe there are some better tools)
https://rweverything.com/ (Interesting tool, but strange UI and don't know if cmd line working)
https://01.org/msr-tools (update: this is for linux, I thought of another tool, but can't find the link ...)
(maybe there are some other & better tools)

1. Make a full MSR dump.
2. Change a parameter/voltage with throttlestop/Intel XTU
3. look, what changed in the MSR dump


* Method 2: Sniff throttlestop/Intel XTU
That would mean place a hook on the dll with the read/write MSR function, and sniff all the commands the application sends to the processor. Then we get the values and registers.
http://forum.notebookreview.com/threads/the-throttlestop-guide.531329/page-278

1. hook dll
2. Change a parameter/voltage with throttlestop/Intel XTU
3. then look at the intercepted commands

Both approaches would create a database for our specific CPUs.


So what do you think ?


---------------------------
Update for the tl;dr people:
The first results start here
http://forum.notebookreview.com/thr...-skylake-in-linux.807953/page-4#post-10589204

 

No undervolting can be done in Linux w/o saving settings using XTU in windows. I found that temps in linux are far lower in Linux than Windows w/ undervolted settings.
Make sure your are on Ubuntu 16.04 or higher w/ kernel 4.10, then install tlp. Yours temps will be fine. As for microcode update just install the deb file from this link and use GDebi to install it and microcode is updated to latest.
The file will be intel-microcode_3.20170707.1~ubuntu17.04.0_amd64.deb (64bit) and i386 for x86.

 

Yeah, temps are "ok" most of the time.
But there is a difference under load: I undervolted -180mV, this makes 40W vs. 27W (says AIDA) and is the difference between thermal throttling and no throttling

And yeah, I know this HT bug is solved in the latest µCode update in Ubuntu. That's why I want to switch.

 

Even on Windows its fixed using VMWARE cpu ucode updater.

 

Ok, that's a valid point. But it is linked to additional work on my side (besides using OO shut-up and stuff) while Ubuntu does this out of the box.
The only real reason for windows is some casual gaming, if any.
So yeah, I have to invest the work somewhere else, but at least I have a not spying OS

 

Naah, ubuntu doesn't patch it by default because sometimes it ruins UEFI secure boot. However, you can install synaptic package Manager and install Intel CPU microcode, extended addons etc..

 

Here is the link http://forum.notebookreview.com/thr...-laptops-pc-fix-is-here.806451/#post-10575774
The archive containing the uCodes. See Post #109 Skylake / Kaby Lake Hyper-threading bug

 

I would also be interested in some way to undervolt and overclock in linux, but have no real experience with it.

The answer from the throttlestop author here

https://askubuntu.com/questions/337147/throttlestop-for-ubuntu

suggests doing the change in Windows, reading the values with MSR Tool and then writing the same values to the CPU-registers from within Linux.

 

Hi,
ok that's nice for a start. I didn't find that post ...
The problem is, this post is from 2013 and is about Intel Gen2/3.

That's basically my first approach, but he has named one of the registers.

I'm not that keen to run this msr exe from some mediafire link on my NB, especially because it will require admin rights.
I'll test, if the tools from the ms debugging sdk will work: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/rdmsr--read-msr-

My plan:
Step 1 would be to find the relevant registers. By making some 1, 2, 5, 20, 50, 100 mV change and then look what changed in the dump.

So I need to find 4 values:
CPU Core
CPU Cache

Intel GPU
System Agent

Afterwards, in step 2 I'd set directly to my desired undervolted values and store them. Later we could try to find the calculation formula for voltage->register, but that is totally optional.

I don't know if we need BD PROCHOT, maybe as an addon ...
I don't use all the other settings. (Turbo Time Limit maybe, too)

Also some debugging infos would be nice, like the current FID & VID, to check, if the change actually worked.
The problem with my dump method is, that these state infos always change, so there will be regions in the dump, which will always change, too.
Nothing too difficult, but that will cost time to identify them.


I think the second approch is way cooler, but I first need to find the correct tools, and other users probably wouldn't be able to repeat the steps ...


Implementation stuff / details:

The link also seems quite useful, if you want to make a complete tool like throttlestop.
I'd be happy even with a lite version / batch script, which will just set the values to the windows settings (because that's a lot less work )

I think, the linux part won't be that difficult.
Either using some basis like this,
https://github.com/01org/msr-tools
or the previousl mentioned repo package
or the sorche seems to hint, that we just need to the following file.

char msr_file_name[64];
sprintf(msr_file_name, "/dev/cpu/%d/msr", cpu);
fd = open(msr_file_name, O_WRONLY);

That's easy, as long the linux interface is there.

I can code in python, so that shouldn't be a problem either. (As there is nothing time critical in setting the registers)

Basically, I use two profiles:
* maximum undervolt (cpu is -180mV, which is totally fine, until I start a 3d application on my nvidia, then I get a bsod )
* stable uv (cpu is -145mV, works always)
(both graphics are always -125mV)

So storing these values in a profile file would be no problem.


And as I probably wrote somewhere, I've got Skylake (i7-6700hq to be precise). I don't know, how similar the other processors / generations will be.

So which processor do you have ?

 

Its skylake.

 

I wanted to insert a Mr Burns image, but I can't change the size, so just image him saying: "excellent"

Anyway, so I couldn't decide, how to proceed so I just started with method 1. Now I can generate a list of relevant registers. These can be now monitored/dumped.

I still need a tool to read the MSR registers in windows as command line, so I can automate with Python. (Maybe I'll test https://github.com/zoumi/PyWinRing0/blob/master/winring0.py as well)
(Woa, I like the post autosafe feature, just saved me here. I crashed my system while trying out rw-everything, and I don't like that tool )

So afterwards it's just a (diligent but) routine piece of work, to map the registers (by changing single values).
I'll probably continue in the next weeks or so, so if anyone finds a easy to use command line MSR read tool until then, that'd be great.

 

Just wanted to update/include my findings so far:

<temporarily removed, until I know if it's allowed here, but you can PM me, if you're interested, the other thread is here http://forum.notebookreview.com/threads/forms-of-reverse-engineering-discussion.808084/>

Maybe just dumping the "apply settings" part in windows, and writing in linux is enough,
but I would like to know a bit more about the contents before writing anything to MSR

 

What's SST.

 

That's SpeedShift. For more info you can read this thread (and all pages linked there).

I think the default settings should be ok in linux, but we can ofc monitor it as well.

 

I was confused when you used SST EPP.
So far, with SST turned by default in Linux kernel 4.10, the performance is good. I will be moving to linux kernel to 4.11 or 4.12 when its more revised with fixes. Maybe 4.11.30 or above. If you want your undervolt to stick permanently use XTU.
Before tracing TS API calls, ask @unclewebb 's permission.

 

Yeah, I'm currently also using 4.10 b/c I was to lazy to change anything in the current Ubuntu installation, and it works quite fine.

I'm currently have a task installed, that starts TS with every login. I don't like XTU, it's too fat.
But I also don't like having unnecessary processes running, so if this stuff works, I could even replace TS with a small script, which runs after every login / wakeup.

Hm, good point. I can't recall agreeing to an EULA in TS not to do this (and api tracing is not decompiling/disassemling ), but XTU has some EULA s*** somewhere -.-
I'll first check with the mods here and remove the current data for the moment. The thread is here http://forum.notebookreview.com/threads/forms-of-reverse-engineering-discussion.808084/

But many linux drivers are reverse engineered in some way, and at least when I release some form of windows copy tool and linux settings tool, the stuff will get out anyway.
If you have a better suggestion, where I can discuss such stuff with other interested people, please tell me

 

I have pinned TS to start menu and as always user scripts execute a little late, so I prefer running TS with a simple mouse click.

 

When properly setup, ThrottleStop is extremely efficient. Use the Stop Monitoring option. If you are using SST, you do not need to use Set Multiplier and you can leave TS in monitoring mode for further savings. You also do not need to use Clock Modulation since most modern laptops no longer use this throttling method. Once you have done that, ThrottleStop is about as efficient as a script. It will sit there and will not be burning many CPU cycles at all when minimized to the system tray.

ThrottleStop is freeware so you can do whatever you want with it. No need to ask for permission. Linux users deserve a similar tool or ways to control their CPU. I am all for a Linux voltage control program. I am just not allowed to tell you anything about the overclocking mailbox.

 

Hi, that's awesome, that you are so cool about this topic.

I'm just in general allergic to processes running in background.
For example, I disabled lots of Nvidia & Intel telemetry, also Intel has 2 stupid separate processes related to DRM (HDCP, HECI), which are always running, even if I never used this HDCP c*** (I don't have even a BD drive in my NB ...)
I'd say it's a really annoying trend, many drivers and applications create permanent background tasks, even if they aren't used 99% of the time. This only makes the OS slower without real reason.

But before I go off-topic, I can confirm, this applies in *no way* to TS.
TS is very well written & lightweight with it's only 500KB, while the fat XTU is over 130MB !!
I didn't like XTU from the beginning because XTU has this "fat application"-feeling (it's not as snappy, but ok, it's written in .net)

I used TS for months now, but I haven't found the monitoring disable function, until I traced the calls this week
Now I checked: Process explorer shows only 0.2 - 0.1 for TS while monitoring or 0.04 while minimized and nothing, if monitoring is off (really zero cycles).
Also it didn't work to put in in the tray (TS didn't react to taskbar off setting, which I found quite odd).
Anyway, now I've found the notification_area_cleaner_1 and TS is now in the tray.

So yes, TS is super AWESOME now and I have almost no reason to replace it.
I give respect where respect is due

 

Sometimes DRM content needs HECI and HDCP so I simply start those services. BTW, you can disable Connected User Experience and Telemetry service to get rid off telemetry.

 

Hello !

I discovered this interesting thread after some searches about undervolting skylake under linux... I run archlinux on a Dell XPS 9560 i7 7700HQ and it's really annoying not being able to undervolt it (fans etc...).

I installed msr-tools under linux and it works fine but... I didn't succeeded in finding informations to modify the right registers of MSR. The documentation of Intel is not full. Pfffffffff...

I can't play with TS because I don't have windows (so I can't make any reverse engineering). Of course, TS doesn't work under wine.

I found also this (dead) thread : https://software.intel.com/en-us/forums/software-tuning-performance-optimization-platform-monitoring/topic/405640

So, I'm blocked but if someone could make a tool to undervolt under linux or could give informations about MSR... that would be really great !!

 

Hi @alfazaz,
you sound motivated (and we'll need testers of course )
As you're running archlinux, I guess you're an advanced user ?

Basically my plan is as follows:

(1)
- check if the list of registers is correct
- find windows command line tool to read the MSRs
- write small python tool/script that captures this MSR subset in windows (ideally with support for several snapshots to show the differences/changes)
- check function of msr-tools under linux (if the parameters match exactly the ones in windows, etc, everything else will end badly ...)
-- write the win MSR dump to MSR in linux

(2)
- find a minion*, who runs my DoE in windows / makes small/single changes (e.g. +-1, +-2, +-5, +-20, +-50, -100 mV in all 4 parameters) and captures the MSRs again ^-^
(*disclaimer: minion is not meant in a negative way - I just find them funny in the films ... )
- data analysis stuff to get the correct formula from voltage->MSR data (probably the coolest part)

I think part (1) is the minimum and is probably enough for people who have dualboot / TS installed, as they can dump their applied profiles.
Part (2) would provide the more elegant solution, as you have the most freedom with the formula and no need for windows. But it will require more work.
If I wont find a minion, I'll have to play minion myself, so it'll take some time longer, but I'll post the traces here.

I'll probably have time at the end of the month to dive in again ...

 

Relatively (greater than in english... ;-) )
But not sufficiently to guess informations of the MSRs as I said before.

I will be a tester of course.

I think that it is rdmsr (and wrmsr to write). I use it under linux but it seems to be the same under windows.

It could be more sure to dump *all the MSRs* as text files before and after mods in TS... The analysis of these dumps is possible by any diff program (I use meld under linux to compare quickly files...).
I can help you for this analysis if necessary (but I can't generate dumps because I haven't windows ; it gives me headackes... ;-) ).

There should be no difference between MSRs functions under linux and windows but the linux kernel can play with MSRs so there can be different values for some registers (for example, SST is on in my archlinux system by default).

There is no need (and it can be dangerous) to write all the MSRs dump but only the necessary registers (if they are successfully identified before...).

Yes, this can be long... but it's interesting...

I will help you as possible... under linux... ;-)
I'm "impatient" to take a look at MSRs dumps (in parallel with snapshots of TS profiles...)

 

Yeah, my problem with plain dumping MSR is:
That I need a tool or lib, that I can call from python, or powershell, or whatever (crucial part is, that it is a cmd line tool) like you'd do with the msr-tools package in linux.

This one works only in kernel debugging mode
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/rdmsr--read-msr-

Probably I'll have to write my own cmd line tool using assembly and this will then take a while
https://msdn.microsoft.com/en-us/library/y55zyfdx.aspx

That's why I thought, tracing API will yield faster results (and it basically did )
The API calls contain every MSR, that TS touches with this ring0-API.
(I guess ...) This should contain all the info needed, and no need for complete brute force dump. But correct me if I'm wrong.

Also this brings me to an idea:
You could dump all MSRs in linux, and look out for MSRs changing all the time. (They will probably contain multi, temp, VID, etc). They should hopefully be the same with the ones I captured in the API traces.
Would you do that ?

Yes, this was my first idea, but for this I need the cmd line tool ...

Ok, got that.

The thing which I meant is: Will this and the wrmsr funciton be exatly the same as the TS API call, we need to be sure here.
This one seems to be for linux https://github.com/01org/msr-tools/blob/master/rdmsr.c
and it is reading/writing to "/dev/cpu/%d/msr".
But wrmsr: Usage: %s [options] regno value
There is only one value,
while TS API call and the intel ASM command wants two additional parameters (3 in total).
Also are these 32bit INTs ? The API call log shows 64 bit wide, but only the last 32bit seem to be used.

Yeah, I agree to that.
But understanding this will require to set single parameters/voltages at a time
and then dump the MSRs or trace the API calls.
-> that's the main part of the work (I need a minion, or it will take some time ...)
Or do you have other ideas ? Maybe I miss some easier solution to this identification problem.

Awesome,
I appreciate the feedback & discussion

And I sent you some stuff

 

Hi, I've recently moved almost totally to Linux (I still keep W10 to multiboot for games/legacy stuff), but I've already tried my luck a few times in past trying to find out what TS does to set the offset voltages, but I'm still too noob in RE, so of course I failed. But I'm open to testing though, I guess that's the best I can do.
I tried to "dump" MSR from Windows, but I only tried RWEverything and I couldn't find a way to dump reasonable amount of data at once (it seemed like it would only allow to see a small part of address space), so I gave up.

I think we should use some "decision system" (sorry I'm not sure how it's called, English isn't my native language), LEM2 sounds like a good idea.

 

It seems to be a good way (seeing your given tracing files in your stuff...).

For the moment, I look MSRs concerned in your tracing files and it seems to be coherent...

There is only one value under linux because it works with 64bit integer (no need to use edx, eax...).

In your tracing files :

* rdmsr has 3 arguments : the first one is the same as me (ecx) and I don't know what are the others (indication for bitfield ?).

* wrmsr has 3 arguments : the first one is the same as me (ecx) and I think that the 2 others are edx and eax (under linux, we give directly the value so there is only 2 args for wrmsr).

For the moment, API tracing can give informations (but I see that writing in the 150H MSR will be "fun" to decode...).

I'm still thinking of all these things (with your stuff).

 

WAHAHAHA, I had a epiphany today:
IT'S A MAILBOX


And I just searched for oc mailbox and found
https://github.com/torvalds/linux/blob/master/drivers/platform/x86/intel_turbo_max_3.c
That seems to be the "correct" way, to do it in kernel space.
And it confirms the 150h MSR

@unclewebb gave also lots of hints in the forums here and there, so basically we have to collect them all
And thank you for that

I don't know what you mean by that, and a short google search didn't yield what I expected, so could you explain LEM2 ?
I guess it's a method to make sense of some weird data and corellate it to a desired/expected output ... ?
Also, I think if we know the correct adress, it should be "straight" forward. It has to be somewhere a 10 bit INT + 1 bit sign.
unclewebb wrote somewhere, that it's in 1024 steps

I don't like RWEverything, too. Also I crashed my System when I tried to add another MSR adress.

But anyway, my current conclusion is:
MSR dump WON'T work, because it's a mailbox

That would explain my strange logs,
and this weird write-read procedure with the 150h MSR register I saw in the API trace.
The reading works like this (which you can see also in the kernel code):
Your write something to OC Mailbox MSR, sort of a "command" or adress
and with the next read you retrieve the content of the internal state.
Writing to it should work in a similar fashion ...

In other words / main findings:
This stuff is *not stored* in a "normal" MSR, but is instead behind the gate of this OC Mailbox MSR. Probably b/c Intel wants to make it harder to find this out, everything seems plausible now.

(Ah and btw, the kernel code is public, so we can discuss at least that part here without problems)

I was quite exited to find this so I wanted to share it with you NOW
and now is also a good time to reward myself with chocolate

I found some other posts, which have some details and I will later quote here as well.
Also, as the answer here ( http://forum.notebookreview.com/threads/forms-of-reverse-engineering-discussion.808084/) is pending and as we move towards the interesting / secret stuff,
we may have to think to find another forum, where we can share this stuff freely.
(I can understand that the NBR guys are reserved about such stuff, b/c they don't want to have any trouble with Intel ...)

 

I found things too... The same kernel reference and also this (which is close to what I see in your tracing files... Domain is ok etc...) :

Dufus message in https://forums.anandtech.com/threads/what-controls-turbo-core-in-xeons.2496647/page-40

There is still some work to understand cmd in 0x150h (and it can be for minion ;-) but not for me because I can't trace under windows... without windows...).

 

Ok, so as I see in the TS INI FIVR stuff, especially the FIVRVoltages seem to be the same what is recorded in the API call as well.
There are basically only 4 relevant wrmsr calls to 150h, this is really nice.

Maybe I just play the minion and need to only to set
+- 1 2 4 8 mV
to the 4 diffrent voltages, and we'll get all the results (and mappings) we need.
Any other suggestions ?
(Also if someone is interested, how to use this API trace tool, just say it, and I'll write a short tutorial. It's actually not that difficult ...)

My last concern is that there is probably some enable bit, or something like that,
And we'll need a FULL capture from starting the application to the end settings FIVRs.

Ah, ok, then I've got at least one concern less with the 64 bit INT.
And the 64 is only a simple concatenation of the edx and eax ? Or are they reversed somehow ... ?

Also I'd like to check, if this works like the kernel code, if it's possible to first write a query, and then read it, or do we need our own specialized method to write-read from OC Mailbox.

For rdmsr:
I'd say this reading stuff is a low prio task ...

Ah, this is really helpful yes. And it matches the traces.
Also really nice, what stuff google finds for you

 

Hi, I have successfully undervolted my skylake i7-6700hq under Linux (for a while now actually, but as others have pointed out I was also reluctant to reveal the information regarding the OC mailbox because of the NDA between Throttlestop creator unclewebb and Intel).

I replaced the ring0 library that throttlestop uses, so it logged all system calls. Then I searched in the log for the same hex as the voltage found in the throttlestop .ini (where it stores FIVR voltages).

So the result is that it only takes one wrmsr to set the voltage for each plane. Since wrmsr is
a simple cli tool on Linux it can easily be used in a startup script.

To read the voltage you first write and then read the same MSR to get the information out (as pointed out in this thread).

Since I don't have access to the laptop right now, I cannot write any specifics, but I was planning to write a guide for undervolting Linux anyway, but was hesitant (again NDA and stuff).
This thread and the post from unclewebb have convinced me that it is OK to do so.

Hopefully I will have a basic guide set up by tomorrow.

Also, thank you conker_ts, for messaging me about the existence of this thread.

 

Ahh, this sounds really awesome, so you're miles ahead of us
Are the 4 calls in/during the FIVR apply dialog sufficient, or is there some other activation bit ?

Also I'm really curious how you did it. You wrote your own dll, which created a log file with the calls ?

 

Fret not; there's no rule against researching something like this. It isn't piracy and neither is it hacking security measures. These register values are buttons that Intel itself, of all people, makes accessible to the end-user via XTU. Only problem being they didn't bother to make a version for Linux or MacOS.

There would be an issue if you had signed an NDA with Intel after having had access to their internal documentation and then proceeded to distribute that information. However, if you've found some of that information on your own (hopefully without killing your system), then by all means; share the knowledge.

Not sure how reverse-engineering @unclewebb 's work falls into that category though. That's up to him to decide and, if it isn't ok, to report on. That report would be acted upon, of course.

 

Ahh, awesome, so we have green light
unclewebb was really helpful with his hints and doesn't mind our tracing here.

 

I wrote a basic guide here https://github.com/mihic/linux-intel-undervolt
It assumes you already know the principles of undervolting and you just needed a way to do it in Linux.
If you have any questions you can ask them here or open an issue on GitHub.
Over time I will expand the guide to maybe open it up to a more general audience, but for now lets test how this works across different CPUs. Please post your results here and include the cpu model.

 

@conker_ts: Install Powertop and calibrate the skylake PC in both AC and battery mode. You will see decreased temps and better battery life.
@unclewebb Does 6700hq support c10 and other lower c-states?
The battery meter is inaccurate because it showed 5 hrs remaining upon disconnecting AC. Even after 4 hours of runtime, it shows 5 hrs est. battery life. I have TLP, powertop and Disk APM/power save mode enabled, WLAN power save mode is disabled due to FW bug.

 

Thanks. Can you fix a typo on your guide from never to newer.
Is there a reason to query 0x150 as regNo argument in rdmsr?
I used cpuid and it reported leaf nodes as EAX, EBX, ECX and EDX. So querying EAX, EBX reports a value of 0xFFF base 16 or 7777 in base 8.

 

Tried writing -50mV, it seems to have no effect. Querying using rdmsr return 0 offset value.

 

The reason for almost anything in there is "that's what Throttlestop does" + after testing it out it worked for me.
If you want to read an offset you first write to 0x150 with the write bit set to 0. After that the next read of 0x150 will have your result. The next read after that will show 0, because if you don't "request" with wrmsr first then the value of 0x150 appears to always be 0. Setting the voltages (with the write bit set to 1) does not count as a "request".

I don't understand what do you mean by leaf nodes. EAX, EBX, ECX, and EDX are registers. IIRC the values here are passed in registers EAX and EDX (combined to make 64 bits), but wrmsr and rdmsr handle that for you, so you can just enters number and it will set the registers appropriately.

 

Well yea, you were right, making rules based on data, starting from the most common atribute. I couldn't find much info online in English either, maybe its not popular or something. I had to write it for school so I could reuse the code, but it's irrelevant now

@tincmulc works here with i5-6440HQ, the voltage formula seems to work for my "-180mV" offset (0xE98).
rdmsr shows 0xE98 too.
"-180mV", because unclewebb wrote here: 6700hq all cores at 3.5ghz possible using throttlestop? ,that each step is 1/1024V, but it's close enough.

Also, at least for me, "i7z" shows CPU core voltage real-time, just for the core, but its better than nothing (I'm not sure how accurate it is, but i see major change in voltages before/after setting offset with wrmsr, so I guess it works somehow). In the end of course much lower temps tell me it worked for sure.

 

You can calibrate the cpu and other hardware for even better battery life and performance using Powertop.

 

Thank you for sharing your stuff.
Also cool, that there are people out there, who wont stop because of missing/incomplete information.

Now I'm really curious to understand the mV conversion. Doesn't seem that trivial.
(Haven't expected that ... Probably impossible to find this out through trial&error or you'd probably end with burned CPUs until you'll find this. )

And this is really interesting:

Seems the linux wrmsr command actually has them in reversed order

Spoiler: wrmsr

Code:

wrmsr 0x150 0x80000011ecc00000 
wrmsr 0x150 0x80000111f0000000 
wrmsr 0x150 0x80000211ecc00000 
wrmsr 0x150 0x80000311ecc00000

vs

Spoiler: my API trace (-179mV; -125mV)

Code:

Wrmsr(0x0000000000000150, 0x00000000E9000000, 0x0000000080000011)
Wrmsr(0x0000000000000150, 0x00000000F0000000, 0x0000000080000111)
Wrmsr(0x0000000000000150, 0x00000000E9000000, 0x0000000080000211)
Wrmsr(0x0000000000000150, 0x00000000F0000000, 0x0000000080000311)

Probably would have resulted in some invalid commands, until we'd figure out the correct order


And to this:

+

Like I wrote somewhere: Reading (or more precisely querying) the OC-Mailbox MSR is different from reading normal MSRs. The linux kernel code also seems to do this in a quick sequence/rapid sucession (writing query, reading result).
Did you do that (like in the tutorial)?

If yes, and it is still not working, we should analyze the wrmsr code:
It writes to "/dev/cpu/%d/msr". (pwrite(fd, &data, sizeof data, reg))
This means we have to analyze the CPU interface/implementation of the "/dev/cpu/%d/msr" structure.
(I haven't found it yet, but) I suspect that writing to this file though this interface has a bit of overhead. Maybe it reads the value again, to check if it's correct, and this would sabotage our following read query ...

The main difference (imho), why this may not be stable, is that the overhead between the write and read commands is probably huge:
You have the wrmsr process: writing & getting destroyed.
Then you have rdmsr process created & reading.
That's A LOT of CPU cycles in between,
while the kernel code executes it in only some µs oder so ...
I you want a 'rock solid' implementation, you'll probably have to copy the c-source from the kernel query mechanism.

I'll look into it later ...

 

Your trace doesn't print which registers those numbers correspond to. In my trace it look slike this:

Wrmsr( index = 150, eax = ecc00000, edx = 80000211) = 1

If you check the wrmsr instruction here http://x86.renejeschke.de/html/file_module_x86_id_326.html
you can see that MSRs are 64 bit registers, the high bits are sets from EDX and low bits from EAX.

So the final result is 0x80000211ecc00000, which wrmsr writes correctly.

 

Hello !

I just ended my analysis of @conker_ts stuff and what I discovered is analogous to @tincmulc infos that I've just discovered now for my Kaby Lake i7-7700HQ... Hum...

Fine ! I will look forward tomorrow !

 

So I looked at what my "-180.7mV" undervolt looks like in TS and it was: "0xE8E00000". I don't really know why, but this code seems to give -/+ accurate results.

Spoiler: code

float a = -180.7; // initial value to undervolt
int b;
a *= 2.048;
b = (int)a;
b <<= 20; //we want to move it by 5hex values, 4bits=1hex
printf("%x",b); //it will print e8e00000

This code might be error prone, so it's for testing purpose only.
For the -180.7 it gives correct result, but I haven't tested different ones (I'm on linux now and you need to exact number to check if it really works, -180.6 gives result 1bit lower). GitHub formula gave me like -175/-176 when i tried to get -180, so the differences are minor, but we want the most correct, right?

Also, I struggled with it a bit so you may find it useful. If you're setting startup script, where inside script you're using wrmsr from msr-tools from Intel, then you may want to delay it some time (for me works 10seconds, didn't test other values). I tried rc.local but I was getting error "wrmsr: open: No file or directory found" or something, since rc.local is mostly deprecated I thought it was it's fault. So I tried systemd just to find out it gives exactly same error, so then (ye im noob) I looked into wrmsr code to see "open:" is supposed to throw error if it cant' find /dev/cpu/%d/msr. If anyone is interested there's my systemd service to launch it on boot/wake (WARNING: if your voltages are not stable, you may not be able to boot without external help from linux): (I'm still a noob at linux, not sure if everything's correct and needed, but it works)

Spoiler: voltages.service

[Unit]
Description=MyScript
After=basic.target suspend.target hibernate.target

[Service]
ExecStartPre=/bin/sleep 10
ExecStart=/usr/local/bin/voltages.sh

[Install]
WantedBy=basic.target suspend.target hibernate.target

You should read about systemd before using it of couse.

Also my voltages.sh script
(I'm testing different voltages on cpu/cache, so the rest is commented.)

Spoiler: voltages.sh

#!/bin/bash -x
/usr/sbin/wrmsr 0x150 0x80000011e8800000 # cpu offset
/usr/sbin/wrmsr 0x150 0x80000211e8800000 # cache offset
# /usr/sbin/wrmsr 0x150 0x80000111f9c00000 # gpu
# /usr/sbin/wrmsr 0x150 0x80000311f9c00000 # system agent
# /usr/sbin/wrmsr 0x150 0x80000411f9c00000 # analog i/o
exit 0

 

This is really interesting...

I don't have windows (so no TS for me)... Can different persons (for different CPUs) put here mV offsets of ThrottleStop and corresponding hex code (look at FIVRvoltage* in .ini file of TS) ?

This could give us many informations (and ensure the good work of @tincmulc) :
* Is there only one formula (CPU independant) to do mV <-> hex code conversion ? I hope it's the case...
* With sufficient different values, it's easy to get a good formula and to be confident on it (it's possible using a linear regression to circumvent probable roundings in TS ; I suppose a linear evolution but it can be tested like this)...

 

Yes, I just noted in my early posts, that I was not sure, how the order was.
I planned to search for this winring0 API description, but yeah, could have guessed it, that the order was like the ASM command.
And I'm just happy you figured it out already

Ah, I actually have some different results while testing the formula (we have same cpu 6700 )

If I put values into TS, I get

Spoiler: ts values

-100.6 mv
0xF3200000

-49.8 mv
0xF9A00000

-50.8 mv
0xF9800000

The doubling (in step 1) is not that precise. I don't know if we'll drift off too much if we use the TS values. The difference will become bigger with higher UV numbers, but I guess, as we are multiplying with a lower number, we are always on the safe side.

Anyway, the precise value is ofc 2.048 for people who want a finer setting.
My current guess is this (In python, maybe needs more formatting for positive values.)

Spoiler: my formula tests

In [76]: mv=-50; hex( (round(mv*2.048)&0xFFF)<<20 )
Out[76]: '0xf9a00000'

In [77]: mv=-50.8; hex( (round(mv*2.048)&0xFFF)<<20 )
Out[77]: '0xf9800000'

In [78]: mv=-179.8; hex( (round(mv*2.048)&0xFFF)<<20 )
Out[78]: '0xe9000000'

In [79]: mv=-125;hex( (round(mv*2.048)&0xFFF)<<20 )
Out[79]: '0xf0000000'

Guess round(mv*2.048) is a bit more precise. Now I know again, that python is not always suitable for binary operations, maybe C style INTs are better for stuff like this
As I tested, my formula matches all of the items below. Ofc TS has actually 1000/1024 mV steps in the dialog, so they're almost 1mV, but even with one decimal place they're not exact, and the round command is needed.

UPDATE: WARNING: The formula may yield wrong output & lock up the system, see next page !

Here you go bro.
I didn't test positive values that much as it makes no sense for me
I guess @unclewebb wrote somewhere (probably linked there, too) that it's almost the same since Haswell / gen4.

Spoiler: values

cpu
(-1 mv)
FIVRVoltage00=0xFFE00000

(+1 mv)
FIVRVoltage00=0x00200000

cache
(-2)
FIVRVoltage20=0xFFC00000

gpu
(+3 mv)
FIVRVoltage10=0x00600000

SA
(-4 mv)
FIVRVoltage30=0xFF800000

------------- other

-49.8 mv
0xF9A00000

-50.8 mv
0xF9800000

-100.6 mv
0xF3200000

-179.8mv
0xe9000000

 

I updated the formula to multiply by 2.048.
The testing combined with the information about 1/1024 voltage steps from http://forum.notebookreview.com/thr...ible-using-throttlestop.802282/#post-10480064 confirms the 2.048 ratio.

Now there is still the question if this is the same across generations of CPUs for which we need more tests. We need people with non-Skylake cpus sharing FIVR voltages from Throttlestop.

 

Exactly ! For exemple, is there anybody with a Kaby Lake (7th generation) and ThrottleStop to give some values ? (After reading intel docs, I think there is numerous common things with 6th generation but we must be sure for voltages...).

 

@conker_ts If your results match with TS results, maybe in TS it's also done by some round() function. I just did plain cast float to int which makes the "floor". As I wrote, I tested it with just one value (so lazy). We can assume TS is probably based on Intel's documents, so round()-ing seems fine.

@tincmulc I'll check out some values on my old Haswell laptop.

 

I guess, the real steps are 0.5mV and nothing hinders us to put it with this resolution into the formula:

Spoiler: 0.5mv steps

mv=-0.5; hex( (round(mv*2.048)&0xFFF)<<20 )
'0xfff00000'

mv=0.5; hex( (round(mv*2.048)&0xFFF)<<20 )
'0x100000'

The round command will take care of it anyway.
(Also disclaimer: this is unverified/not tested yet & haven't seen it in TS!)

UPDATE: WARNING: The formula may yield wrong output & lock up the system, see next page !

I tested floor as well, but sometimes, depending on the first decimal, I got different results compared to TS (ok, obvious, some information is just cropped, and only in one direction)
I need the round command anyway, to convert to int.

This was an awesome & productive week !
Have a nice weekend everyone