In regard to your inquiry, will try to run the same benchmarking test on the NUC, in order to find out if there is a known issue or a bug as you mentioned with the BIOS or with Windows.
Now, remember that 3rd party tools like GPU-Z sometimes could show misreading, in order to verify if the NUC is working properly, we recommend to use the IPDT, that is the tool we rely on, it does an overall test on the processor and the rest of the components on the NUC and if it passed the test it means it should be working fine.
On the following link you will be able to downloaded, second option to the left to install it:
Also, some of the pees viewing this thread might be able to provide further information on this matter.
As soon as I get any results from the lab, I will post all the details on this thread.
Any questions, please let me know.
Thanks for the reply. I have some additional information:
A) Running the IntelProcessorDiagnosticTool indicates that the Skull Canyon unit I have passes both BEFORE, and AFTER I see a failure condition.
B) I believe I can now reproduce the problem more reliably as follows:
* My Diagnostic was Modified to add a looping feature - so as to continuously run the diagnostic benchmark.
* If the diagnostic runs continuously - WITHOUT ANY DELAY BETWEEN ITERATIONS then the system seems to run reliably showing now failure in over 24 hours of run time.
* If instead a 4 second delay is added between diagnostic loops then it seems (statistically) possible to reproduce the problem within 1/2 hour. Since the diagnostic
computation requires about 4 seconds to complete this amounts to about a 50% duty cycle of intense computation and idle time.
* Once in a failure state the computation results still appear to be correct, only the computation rate is slowed down - from about 4 seconds to 11 seconds per loop. Running the Intel Extreme Tuning Utility (with all default values - no changes in configuration), the utility reports the Processor Graphics Frequency as APPROXIMATELY 950 MHZ when running properly. When in its failure mode the "Processor Graphics Frequency" reports as 349 MHz consistently (whereas when running properly it reports a changing value somewhere between 850 and 95h MHz).
C) I can furnish the diagnostic in .exe or source code format (its a Visual Studio project) I you wish.
D) Running the same benchmark on an I3-6100 (Skylake processor) showed no degradation in performance running for 12 hours.
E) While I do not have access to the Intel BIOS source code or Microsoft Implementation, an internet search indicated that Windows 10 Added special support for Skylake CPUs for Speed Shift late last year. This problem appears to be a defect in either the Microsoft speed shift drive code or the Intel Skull Canyon BIOS relating to speed shift. I would guess that the combined dirvers / BIOS stop controlling the GPU clock. The problem is reproducible by cycling the GPU load between computation periods and no-computation periods which exercises the speed step BIOS algorithms.
Most of the testing I have been doing is with Remote Desktop with on attached monitor. If I
* attach an HDMI monitor to the computer,
* set the "Power Options" "Turn off the display" time to 1 minute in the windows 10 control panel power area
* log in
* wait 1 minute for the display to blank
* then run my diagnostic
Then the first time the diagnostic runs it is slow, and all subsequent times it is slow, and the only way to get the GPU to run faster is to reboot or cycle power.
I had been testing with display timeout set to never (and never sleep as well), but with the short display timeout it seems to fail every time on the first try. This also seem to aply to the default of 10 minutes. All I need to do is wait for the display to turn off, jiggle the mouse to wake up the display and then run the diagnostic - the GPU is permanently (until reboot) in slow 350 MHZ mode.
The problem or some variant of it can be demonstrated with a standard benchmark. I used SI Sandra rather than my own application. Procedure is as follows:
* On an up to date win10 system on the Skull Canyon (I am running professional version) Install SI Sandra
* Attach an HDMI monitor.
* Run SI Sandra
* Under the General Purpose Computing (GP) eare double click on GP (GPU/CPU/APU) Processing to open the benchmark
* Refresh / run the benchmark.
* Write down some of the static results of the benchmark (takes about 2 minutes to run).
* Wait 10 minutes or more (until the HDMI display turns off) - I am assuming you are using the default options for power management which
turns off the display after 10 minutes.
* Jiggle mouse to wake up the screen.
* Re run the same SI Sandra benchmark
What you should find is that the benchmark times are 3X worse (about 1/3 the performance) after the screen blank occurred. In addition if you run the Intel XTU tool you will see that when exercising the GPU (like running the benchmark) the GPU clock remains at or below 350 MHz whereas during the original benchmark (before the screen blanking) the clock reports as close to 950 MHz.
I just wanted to let you know that we tried to replicate the case using the NUC6i7KYK, the XTU tool, with Windows® 10 and graphics driver 4542.
Attached to this thread you will see the results of the lab.
The NUC did not reach 950MHz because that is the Graphics Max Dynamic Frequency that is different from the Graphics Base Frequency which is 350MHz so it is expected to shows that value as max.
While doing the benchmarking the NUC did not crashed, it worked just fine, so that issue was not replicated.
The GPU-Z is a 3rd party tool so it could have misreadings, but even though that might happen, still is showing 349 MHz which is expected.
Any questions, please let me know.
XTU Tool.docx 214.3 K
Thanks for your help. I reviewed you results. THE RESULTS SEEM TO ACTUALLY DEMONSTRATE THE PROBLEM EXISTS ON YOUR SYSTEM AS WELL. THIS IS A SERIOUS PROBLEM, probably on all Skull Canyon systems that reduces the performance of the Iris Pro Graphics 850 to 1/2 that of a standard Skylake I3. I dont know if this is BIOS or driver but suspect the fix is easy. PLEASE TAKE THIS MESSAGE SERIOUSLY.
Here are more details of what your benchmark shows and why there is a problem even though the benchmark "reported" as passed.
1) The XTU benchmark you sent DOES NOT BENCHMARK THE GPU, only the 4 cores of the CPU.
2) Therefore the benchmark score is not relevant and does not even attempt to test this problem. The fact that the benchmark reported as passed
also is not relevant because the benchmark does not test the right part of the processor.
3) However please look carefully at the screen capture in the .doc you attached. In the capture the "Processor Graphics Frequency" shows as 349 MHz. If you casually look at this value, you might think it is just a rounding error off of the nominal/minimum 350 MHz frequency of the GPU, BUT IT IS NOT. The 349 is an INVALID VALUE, and is a key signature of the problem state existing.
The XTU does not have a GPU benchmark, but it does have GPU stress test. If you were to run a true GPU benchmark you would see a performance reduction of nearly 3 TIMES when in this failure state as opposed to expected performance. You can, however, run the GPU stress test built into the XTU to see a symptom of the problem. Here is a procedure which seems to reproduce the problem reliably every time I have tried it (over 10 times in a row):
* Make sure Windows 10 is installed in the Skull Canyon computer.
* In the windows Control Panel / Power Options, change the plan settings to: NEVER turn of the display AND NEVER put the computer to sleep.
* Restart or power on the computer - you must do a new boot or restart to ensure the computer is not in a failed state.
* Log in and run the Intel XTU
* Select the Stress Test, then check the "Graphics Stress Test" box only. Set the run time to 1 minute.
* Press the "Start Testing" button
* While the test is active write down the values for the "Processor Graphics Frequency" value. You should see a value of about 950 MHz. The value will jump around, but will be above 900 MHz and not even close to 350 MHz.
* Exit the Intel XTU
* In the windows Control Panel / Power Options, change the plan settings to: "5 Minutes" turn of the display and NEVER put the computer to sleep.
* Wait AT LEAST 5 minutes for the screen to blank. I am assuming a HDMI monitor is attached. After the screen blanks, jiggle the mouse to wake up the screen and repeat the above procedure with the Intel XTU stress test.
* During the Graphics Stress Test, you will see the "Processor Graphics Frequency" value reports as 349 MHz. This is an erroneous value, and indicates that the GPU clocking has failed. The stress test will report as "Passed" but the stress test does not check computation rates and does not measure properly diagnose the nature of the problem.
Similarly if you run any GPU benchmark diagnostic like SI Sandra, after the monitor blanks and then wakes up, you will find the GPU benchmark statistic is severely degraded in performance. See my posting in this thread for SI Sandra results.
Thank you very much for providing all those details.
We will do further research on this matter.
As soon as I get the results of our investigation, I will post all the details on this thread.
Any questions, please let me know.
I just wanted to let you know that I tried to replicate the issue in our lab following the steps that you provided previously, and you were right on the part that it will reach a range of 900MHz to 950MHz on the “Processor Graphics Frequency” field.
But, I tried to replicate also the second part of your instructions, I set the option to turn off the display to “5 minutes” and I choose “never” for the option to go to sleep, wait for display to go off, then repeat the steps above and actually the “Processor Graphics Frequency” field showed the same behavior as before, it will reach a range of 900MHz to 950MHz, so I was not able to replicate the second part of the scenario.
Based on that we got a suggestion for you, to uninstall the XTU following the procedure on the link below to make sure we are removing all the registry on it:
And then please re-install the tool again:
NOTE: These links are being offered for your convenience and should not be viewed as an endorsement by Intel of the content, products, or services offered there.
Please let me know if after trying the steps above the problem remains or it gets fixed.
Any questions, please let me know.
Ignore my advice about disabling "Extended Battery Life". I updated my post with a real solution. Downgrade to graphics driver 45.01. The newer drivers appear to gimp performance when the monitor shuts off. You can restore performance with a reboot or by disabling/enabling Extended Battery Life. But those are temp fixes because you will lose performance again when the monitor shuts off.
Follow this guide to stop windows from auto-updating your driver: How to Prevent Windows from Automatically Updating Specific Drivers
I tried downgrading to Graphics Driver Version with the following results:
In initial testing I have not seen a performance degradation with the September 4501 version (win64_154028.4501.zip).
HOWEVER the results are BETTER THAN EXPECTED. For my benchmark, comparing the latest release win64_154510.4542.zip (before it degrades after a screen blanking) with 4501 I have the following numbers:
Downgraded 4501: 2700 ms
Latest 4542: 3900 ms
The ratio between these values is approximately 3 : 2. I would guess that the latest release is treating the Iris Pro 850 graphics (72 computation elements) as if it was an Iris Pro 540 (48 computation elements) and ONLY USING 2 / 3 of the available computation units!
This testing was done under Windows 10. HOWEVER, I also tested with Windows 7 with similar results - except that I did not see a slowdown after the screen was blanked.
Note that the Skull Canyon Driver Download Site lists yet a different (and older than 4542 driver) as the latest, namely 4534. Benchmark testing with 4534 was disappointing.
Suggest that the problem with the latest driver be submitted to Intel. The intel driver qualification should include performance as well as functional testing to detect this problem, and I hope that they will introduce a new version that is as good as their 4501 Sept 2016 version.