M11x, i7 Max Multiplier 14, Multi-threaded?

This is pulled from the R2 and R3 benchmark thread. The background story is that DavyGT said this:

He also provided benchmarks using Intel Burn Test and showed max multiplier as 12 when using a 2 thread load. I thought this made sense because since there are 2 active cores, it lowered the turbo steps thus maxing at 12. Applying the same concept, the i7 maxes out at 14 on dual-core load. Greatly intrigued, I decided to do my own tests, using throttlestop. Here's what throttlestop showed while I played Starcraft 2. SC2 is known to utilize dual-cores.



It showed my multiplier going nearly 16 in real world tests, playing a 4v4 in SC2. Sometimes my multiplier would go pass 16. So I'm officially confused. So I ask you forum, why is this? It seems we don't know everything about turbo boosting as we thought.

 

Try with a more intensive load. I had to change from Prime95 to IntelBurnTest because it didn't use the entire 2 threads like your screenshot shows. Maybe the CPU is entering and exiting the multipliers so fast that Throttlestop counts them and averages them.

 

SC2 4v4 with insane comps is pretty much as intensive as it gets. In fact the more intensive the battles, the higher the multiplier would go.

 

That's not what your screenshot is showing. It shows 2 threads are at 40% utilization and the other 2 are idling. Not intensive compared to IntelBurnTest 2 threads.

 

It isn't max load, but I wanted to see real world tests and see how it would affect turbo boosting. I always had the impression that when utilizing two cores, the max multiplier is 14. Turbo boosting is still as confusing as ever. It would seem the load does indeed affect how much turbo there is.

I can also provide more screenshots of heavier SC2 loads. In addition, anyone else with an i7 and SC2 can do these tests for themselves and see as well. I'm still not 100% sure why this is the case.

 

Intel Core i processors have threads and cores that are constantly and rapidly entering and exiting the C3/C6 sleep state. As this is going on, the maximum multiplier is constantly changing too.

The Core i7-640UM has a maximum multiplier of 17 when a single core is active and the second core is asleep and has a maximum multiplier of 14 when both cores are active.

The game you are playing is not fully loading both cores of your CPU so each core is spending time asleep. When this happens the multiplier jumps up to 17 and when both cores are active it drops down to 14. This can happen a hundred times a second so it makes sense that the multiplier is averaging somewhere around 15.5 (17 + 14) / 2

If you run a single threaded benchmark and lock it to a single thread of your CPU with the Task Manager Set Affinity function then it will be much easier to see the maximum single core multiplier in ThrottleStop. There is nothing unusual about the results you've posted once you understand how these CPUs are designed to work.

Just for the record, the multiplier ThrottleStop reports is an extremely accurate average during each sample period. Intel includes two timers for each thread in their CPUs so it is easy for software that follows their method to determine the average multiplier.

 

Thanks for the insight unclewebb. So SC2 is not fully loading both cores. I suppose this makes sense since it's not always loaded with multiple threads and being processed by both cores at the same time. I do find it a bit odd SC2 isn't constantly loading both cores and in fact going to sleep though, especially during intensive battles where all 4 cpu threads jump over 15 multiplier. But I suppose it's happening so fast, it's difficult to understand this.

Does this also apply to your TS bench as well? I ran 2 threads loading on all 4 cpu threads. Once a thread is loaded onto a core, wouldn't it stay there? And why would cpu's go into a sleep state when processing a thread?



Is there a way in throttlestop so I can monitor how many times or percentage that they went into a C3/C6 state? EDIT: nevermind, I just noticed at the bottom of throttlestop where it says C3 C6%. This is purely from an academic curiosity. Thanks for any insight.

 

Not even close. Multi core and hyper threaded CPUs are way more computing power than many games are able to take advantage of. Your first screen shot with C0% at 27.7% means that SC2 is using about a quarter of what your CPU is capable of. That's why it has to enter the sleep states when it is not busy. If it didn't do that, it would waste power which creates a lot of unnecessary heat.

If you want to find out how a laptop would feel if it spent 100% of its time in the C0 state, run 4 threads of Prime95 Small FFTs. You can use the Task Manager to set prime95.exe to the lowest priority so Windows will still feel responsive. I wouldn't want that sitting on my lap all the time so a CPU constantly trying to put its unused threads and cores into a deeper C sleep state is a good thing.

That is a common misconception. Tasks get scheduled on a core, the task is processed for a maximum of about 15 milliseconds until its time slice is up and then the task gets kicked off the CPU and ends up back on the list of tasks that need to be processed. Intel CPUs are very smart and try to schedule tasks on the same core they were on before to minimize the amount tasks bounce around from core to core but no algorithm is perfect. Tasks do end up moving around depending on how much other background activity needs to be taken care of.

The only time the multiplier goes higher than 14 in your CPU is when one core is asleep. It might be an intense battle in your game but one thread of your CPU is able to handle this so during SC2, 3 of your 4 threads are sitting idle in the C1/C3 or C6 sleep state the majority of the time. SC2 might be multi-threaded but it looks like these threads mostly run concurrently and are being scheduled one after another. That's typical of many games. True multi-threaded games will have various tasks running independently on various cores, all at the same time. The ThrottleStop log will show a much higher C0% number during a true multi-threaded game.

High C0% shows that more of your CPU's power is being used, or at least you hope it's being used. It can also be a sign of a poorly programmed game if a thread in the game is hogging the processor and waisting its time slice. It might be sitting in a busy loop, mindlessly counting to a zillion over and over again, killing time while waiting for something to happen during the game before it can do some more processing.

When testing, use one or more threads of Prime95 and move it around from thread to thread with the Task Manager. If you try to do this type of testing while running TS Bench, it will screw up the rest of ThrottleStop since TS needs full access to all of your threads for it to operate correctly.

 

Hmm...that would kind of defeat the purpose of true parallel/distributed computing if they're being bounced on the same core, but I suppose it's possible to bounce on the same core since the OS sees 4 logical cores and not 2 actual cores, so it thinks it's assigning independently to 4 cpus. But I don't think that still explains why in the TS bench results, it shows C3/C6 states at 0.0. So if I'm understanding this right, none of the cores ever went to sleep. Yet, the multiplier is still going above 14.

DavyGT already did tests for max load on the threads, but I think the hypothesis was, if the load balance also has an affect on turboing pass 14.

 

In the Task Manager under the Performance tab, my laptop is showing that 589 threads are running on my CPU. Your CPU can only process 4 threads at a time so the only way it can run more than that is if the tasks are scheduled. A task gets the CPU for its time slice but has to release it when its time is up so other tasks can be scheduled. That's how modern operating systems and multi-threaded CPUs work. If 4 tasks got scheduled on a CPU and they never released the CPU, it would lock up solid and wouldn't be able to do anything else.

CPUs are extremely fast so most tasks are quickly processed without needing the full time slice. When the task is finished, it goes back to sleep and waits for its next time slice. The CPU is available to work on the next task so the previous time slice isn't wasted. If that thread of the CPU doesn't have anything to do because it has completed all of the scheduled tasks, it will enter the C1 sleep state. If it sees that nothing is scheduled for a while then it might choose to enter C3 or go into C6. Your CPU is running at over 2 billion cycles per second. It can get a lot done in a short amount of time so it spends a lot of time asleep, waiting to do some more work.

ThrottleStop shows the C3% and C6% of the entire CPU package. When it shows 0.0, individual threads can still be going into C3 or C6. There is also the C1 sleep state where the core is not working on anything but is immediately ready to get back to work.

During the TS Bench test, it is fully loading two threads so there is no time for the entire CPU package to enter the C3 or C6 sleep state.

During your gaming test, there was a tiny amount of time, 0.5%, where the entire CPU package entered the C6 sleep state and turned itself off. It can only do this when all 4 threads have nothing to do and simultaneously enter the C6 state. It also spent 2.3% of the time with the CPU package in the C3 sleep state so all 4 threads were in the C3 state at the same time.

How a load is distributed within the CPU can play a part in how much turbo boost you get. For an interesting test, why not run 2 threads of Prime95 and lock them to CPU0 and CPU1 in the Task Manager and compare that to 2 threads of Prime95 locked to CPU0 and CPU2. In the first example you would think that load would allow the second core to spend more time asleep so you should get higher turbo boost. In the second example, both cores should always be active so you probably won't see any turbo boost. How is reality vs this theory?