*** MSI 16L13 (Eurocom Tornado F5)/EVOC 16L-G-1080 15.6" Owner's Lounge ***

@VVoody They build them as they are ordered to spec AFAIK they don't just have units sitting around waiting to be sold. I think average time is a couple weeks to build and test and you can pay to have it expedited. Mine took a little longer as they had some shortage and issues with parts to go inside of it and they refunded me my expedited charge before I could bring it up to them and ask about it because of the delay. It's bad luck but stuff happens and I understand, and I feel more than comfortable that I am in good hands and will be taken care of. Just the service they have shown with @Donald@HIDevolution giving me calls every couple days after the laptop was already delayed and keeping me up to date and speed with what was going on with it, and now reaching out to me when I brought up the screen issue here is a level of customer service that until now, was unheard of from me. As much as it may suck it is what it is and I know everything will work out I'm not worried at all, just sad I won't have the time to spend on it that I wanted to! I definitly don't "blame" them or think this is that big of a deal by any means or hold it against them, HID has been more than great in my experience with them over the past few months between talking to Donald and figuring out what I wanted and pricing and then everything else going forward.

 

w00t!!!! I always wondered if I got the very first one, or just the first one with 4K screen.

 

Thanks everyone for the replies about undervolting. I didn't know about the voltage curve in afterburner before. I have my 1070 capped at 900 mV running at 1860 core, it is very stable and dropped my temps about 7-8 C. I'll fiddle around with it a bit more but I enjoy the fact my temps have dropped that much. Thanks again!

 

My shout-out for today goes to @bloodhawk for this advice. I uninstalled the driver (new over old), reinstalled the new directly from nothing, and it works a treat now. Thanks!

 

No worries, once they come in we will have plenty.

 

@Donald@HIDevolution is there actually any benefit for the Prema bios if i'm actually downclocking the CPU at all times to 7700T levels?

 

Yes. There are also benefits to your GPU, Memory, SSD, fan control and more.

Question though, why are you downclocking? If it is for cooler temps, why not undervolt, and use stock Intel® Core™ i7-7700K clocks for better performance?

 

It doesn't affect it much, I'm just gaming the 1080 is 90% of the performance there. I'd rather not send it off and be without a comp for a couple weeks if I won't gain any benefit since I'm not really tweaking anything. I just bought it for the 1080 and it's 6.5lb with a 4K screen. I'd have still bought it if the CPU was BGA.

 

No worries then...just let Zoltan know you won't be returning it.

 

Awesome, if it's not fixing any outright bugs I'm not concerned. I suppose I could hit you guys up in the future if I change my mind?

 

Sure, but if you do it later, you may have to pay shipping inbound.

 

That's acceptable, thanks for your help!

 

Fan control might just be a compelling argument for me to get Prema installed. I'd love to have tighter control over those.

 

@Donald@HIDevolution

Does the Prema update fix the screen dimming issue, with certain drivers? Also does it offer brightness controls?

How long should it take once you guys receive the unit?

Thanks in advance.

 

Oh wow, completely missed this one. It is unfortunate that I have to send it in, which will cause some issues with travel/work but I'm sure it is worth the trouble. Thanks Donald and look forward to your email on the shipping process!

EDIT: Haven't receive my email yet, so I'm not sure what type of shipping will be used. However I wouldn't mind paying extra for faster shipping, as I need mine for work asap. Please let me know if that's something we can work out.

 

@Donald@HIDevolution You guys are amazing. To all EVOC 16L-G-1080 users, your laptops are going to come alive now. I expect to see more 19K+ scores in Firestrike.

 

Please deal directly with [email protected], or call 888-666-3418 Ext. 200 if you are in the USA between 9 AM and 5 PM Pacific Time, or 02 033183302 Ext. 200 from the UK, or 02 80155048 Ext. 200 from Australia or New Zealand, or +011 562-485- 6541 Ext 200 from anywhere else in the world - between 5 PM - 2 AM GMT Monday through Friday to make inquiries and arrangements for your personal situation regarding the Prema BIOS.

Yes, it does fix the brightness control for the screen.

 

Hello everyone. I have a bit of an issue and I was hoping I could get some help. I am a new owner of a eurocom f5. I purchased the 1080 graphics card first from eurocom and later I purchased the barebones laptop itself. Ive managed to piece it all together but I am noticing that the 60hz panel I have does not have an option to enable gsync in the nvidia device manager. I bought the specific f5 for a 1080 and I have the heatsink and the graphics card itself but I am wondering if there may have been some mistake made by eurocom. I have checked my drivers and I have even replaced the vbios I had initially for another msi vbios that is I believe gsync enabled. I am not certain if I am missing something and I was hoping I could pick some brains.

My specs are:
Eurocom Tornado F5 with 1080 motherboard and heatsink
1080p 60hz gsync panel
I7 6700k
GTX 1080
16gb 2400 ram
512 nvme ssd
1tb m.2 ssd
2tb hdd
stock eurocom bios
this is the current vbios I have on my 1080 MSI 86.04.56.00.3C

any help would be greatly appreciated.

 

What's the SSD benefit? Is there something akin to a changelog with a list of improvements/fixes?

 

I believe the panel has to be whitelisted. Make sure you have the latest BIOS from Eurocom. The only problem I can see is that you changed the vBIOS and you may have to get the specific BIOS/vBIOS from Eurocom.

 

Well i still have the original bios. I made a backup. I was more trying it to see if it was a vbios problem. I think it may be a bios vbios issue as well. What do you mean by whitelisted?

 

Are you sure they sold you an nVIDIA GeForce GTX 1080 that supports G-Sync? Some do, some don't. Did you specify that you wanted an nVIDIA GeForce GTX 1080 w/ G-Sync?

Since you have the 60Hz panel, and they represented that it supports G-Sync, then it probably does. It is only the 120Hz panels that are not whitelisted (certified) by NVIDIA.

 

The 1080 i purchased is specific to the f5. There may very well be two different versions but i am not sure. I never specified gsync or not i figured it was implied seeing as how it only fit in one laptop but my reasoning may be flawed. I sent an email to them and itll probably be monday before i hear back. Im just hoping its as simple as a bios tweak. If anyone has the stock eurocom bios for the 1080 to compare against mine id really appreciate it.

 

Actually i just checked my invoice and it is the gsync 1080. It says so on the pdf. Hmm strange

 

Hello Donald. Zoltan contacted me and I arranged for the return of my laptop to HID. I'm now thinking of changing from my 4K screen to the 120Hz 1080p panel, but my question is, does it have G-Sync Enabled? Is it possible with the Prema Bios? My current 4K panel has G-Sync but it pushes my GPU SO HARD that the temps reach 94c....unless HID can offer me the bottom panel mode (Should be done and installed by HID once they receive my laptop for the Reflash).

 

Wow, Intel just can't win lately...

In short, disable hyperthreading in the BIOS until you can get a BIOS / microcode update to fix the errata.

Skylake / Kaby Lake Hyper-threading bug

 

That entire thread is false and clickbait.
NO kaby lake processors are affected.
Skylake microcode was fixed over a year ago.

 

In short... don't disable HT. If you've never noticed an issue for the nearly 2 years these processors have been out, and you've been completely stable thus far, then this extremely rare, niche set of circumstances will not be impacting you. Sure, if you care about mission critical stability, then get the microcode update, but this is a non-issue for the vast majority of consumers. I've been using my 6700k since it launched, running copious amounts of stress imaginable and have not had any issues with stability. This is with me pushing an overclocked CPU and extremely overclocked ram 24/7. I've had friends use it to compile various pieces of code, and have not had any issues. That article is simply taking this extremely minor issue, and blowing it out of proportion as a means to obtain clicks. Unless you can show a massive influx of people blaming this for their instability, it's likely not an issue.

 

The 120Hz panels do not support G-Sync, but at 120Hz G-Sync adds little value. The panel is not certified by NVIDIA for G-Sync, so the BIOS cannot change that.

Please handle questions about your personal situation like switching screens and the bottom panel mod by emailing Ted.

 

I'd have to disagree with the notion that G-Sync adds little value at 120hz. If anything, I'd say it adds more value. We have to remember, G-Sync was designed as a feature to keep the GPU and panel in sync, adaptively changing the refresh rate to match the constantly fluctuating framerate of your GPU. While it's true, that you are less likely to tear on a higher refresh rate panel (due to the fact that you are less likely to render beyond that higher refresh rate), a 120hz panel alone cannot match the perceived smoothness G-Sync offers, by removing the frame-jitters that comes with your framerate constantly changing.

I can't speak for certain about mobile G-Sync, as I have never owned a laptop with G-Sync, but the difference in jitter is night and day on my desktop panel. By having a larger G-Sync window (in this case, 30hz-120hz) one can have their framerate constantly change within that window, and never notice it. By having a much smaller window (30-60hz on those 1080p/4k panels) one must remain within that very small window, or risk tearing/input lag by falling outside of it/resorting to traditional v-sync. Fast Sync is an option at that point, but it's only truly beneficial if you can render nearly 2x your max refresh rate anyways, which defeats the purpose of using a small refresh rate in the first place.

I will say this though: I'd take 120hz no G-Sync over 60hz G-Sync any day of the week. At that point, you are trading terrible motion blur/ghosting for an extremely small window of no-jitters, when you could focus on keeping your framerate stable (CPU OCing, memory OCing, compromising on visual details, etc) and run at a consistent, higher speed. Those of you that have been bitten by the G-Sync bug need to remember that a trade-off exists no matter what you pick. In this unique situation, I just couldn't possibly think of settling for 60hz, even if G-Sync is on the line.

 

While I agree with everything you've stated, I would argue at higher frame rates tearing and jitter become less noticeable. In that regard, Gsync is more valuable when you can't sustain frame rates beneath 60 fps and less necessary at higher frame rates. Applications that can push insane frame rates can be limited to the panel's refresh rate to minimize those issues on the other end of the spectrum. While I would happily have Gsync on this panel, just as you've stated, I wouldn't trade it for a slower refresh panel that has it.

 

The problem with "limiting the panel's refresh rate with applications" is that you end up with tremendous amounts of input lag. Granted, if you can do so within your games engine, then great, you can avoid the Vsync input tax, but not all applications have an engine-level frame limiter. I also disagree with jitter being less noticeable at higher framerates, because it's harder to maintain a higher framerate due to the nature of programming. No matter how fast your GPU, no matter how many threads you throw at an application, you will inevitably hit a situation where you are bound by the speed of a single thread, which bottlenecks everything else in the system. These random dips is where that jitter comes from, and not having G-Sync to smooth it out, is where it hurts. They are far more noticeable dropping from 120 down to 50, than dropping from 60 down to 50.

Tearing is indeed less noticeable at higher refresh rates because it becomes difficult to obtain frame-rates higher than 120hz when you have details cranked, or are lacking the graphics horsepower to do so. By not going over your panel's refresh rate, you won't be seeing any tears. However, the trade-off of not tearing at high framerates, is that aforementioned issue with jittering, something G-Sync solves quite nicely. Again, you can mitigate how far your minimum frames drop by overclocking your CPU, memory, and by changing more CPU demanding settings in your titles. In MMO's, these settings would be model render limit/distance, shadows (if playing an older MMO like Silkroad Online or Perfect World), and even music (which tends to bog down a single thread more than others on certain MMO's). Luckily, most other gaming genre's handle threading quite well, and are less likely to be dramatically limited by a single thread (though Amdahl's law still applies to everything).

Still, I stand by my point that G-Sync does still benefit quite a bit from higher refresh rates due to the larger activation window and perceived smoothness by eliminating jitter when dropping large amounts of frames within that larger window. I also stand by my point that 120hz no G-Sync > 60hz G-Sync, because a 30hz adaptive-sync window is pointless, and the input lag/motion blur that is imposed by being limited to 60hz is simply not okay, especially on panels that are already slower than their traditional desktop counterparts. There is a great youtube channel that discusses this exact scenario:

 

Your YouTube video actually stands firmer by the points I'm making. First of all, limiting frame rates does not introduce input lag, it merely limits the input response to the rate of the current frame rate. Vsync does introduce input lag because it drops renders that aren't used when the screen couldn't refresh fast enough to use the current held render so it uses the next one or the next (triple buffering). Limiting frames may limit your response (not introduce lag), but above 60 fps very few people would actually notice.

Second, if you have a system where you are capable of hitting 120 fps, there aren't going to be as many scenarios where you are constantly dropping down into the 50s to cause jitter. The application would have to have extremely poor optimization. Rates above 60 fps aren't very susceptible to jitter. It is much easier to experience jitter with constant frame fluctuations beneath 60 fps.

How many applications have you run on a GTX 1080 where it can hit 120 fps, but constantly drops below 60? I haven't come across any yet. Even if that does happen, I could adjust the settings to stabilize the fps. Having a high powered gpu grants that.

On a 60 Hz screen jitter will be noticeable only when your gpu can't keep up with the refresh or sustain stable frame rates mainly impacting the experience when frame rates hover below 60 (unless micro stutter is introduced through bad code - in which case the 60 fps and lower crowd will still feel the sting more, but it will be present at higher fps). Even if you can manage at least a stable 30 fps, jitter shouldn't be intolerable for most. Screen tearing can be horrendous below 60 fps, so Gsync becomes critical if you can't maintain frame rates (4k screens at 60 Hz refresh trying to max out settings) and jitter can be felt not just seen. That's really where Gsync is a Godsend.

If you have an under powered gpu or a ultra resolution display Gsync becomes important. If you can pump out high frame rates even if they aren't absolutely stable (above 80% stable should be fine) then Gsync becomes less important.

To be clear, Gsync is better than no Gsync, but it is more critical in systems where maintaining frame rates greater than or equal to 60 is difficult or impossible especially when the refresh rate of the screen is low.

 

This was *NOT* debunked on OCN.

@Falkentyne DrFPS is a clueless person and/or trying to troll their thread. Read the responses. Did anyone else actually read his post and responses?

Spoiler: falkentynes link, post and responses

DrFPS - "Fake.
All the reviews and not one time has one person claimed this processor hangs up.

If it did it would be able to make it hang over and over. This is not the case.

Google search, all points back to the same source. Reason for that is it's fake."

CynicalUnicorn - "Yes. It sure is fake. That's why Intel found and isolated the bug and promptly patched it."

Particle - "I sure am glad some random person with Google is here to set the record straight. Operating system developers are always trying to pull one over on us with their incompetent fake assertions."

The discovery of the bug was over a year ago in 2016, the fix wasn't logged until April of 2017, by Intel.

It's just recently enough that most people won't have updated their BIOS to fix the problem.

It can take months for a vendor to build a BIOS with that errata fix, test it, distribute it, and for people to finally download and install it.

Here is the entire warning posting, read the entire warning. It says the bug goes back to 2016, but the fix wasn't included by Intel until April.

Spoiler: This warning advisory is relevant for users of systems with the Intel processors code-named "Skylake" and "Kaby Lake"

[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
This warning advisory is relevant for users of systems with the Intel
processors code-named "Skylake" and "Kaby Lake". These are: the 6th and
7th generation Intel Core processors (desktop, embedded, mobile and
HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
well as select Intel Pentium processor models.

TL;DR: unfixed Skylake and Kaby Lake processors could, in some
situations, dangerously misbehave when hyper-threading is enabled.
Disable hyper-threading immediately in BIOS/UEFI to work around the
problem. Read this advisory for instructions about an Intel-provided
fix.

SO, WHAT IS THIS ALL ABOUT?
---------------------------
This advisory is about a processor/microcode defect recently identified
on Intel Skylake and Intel Kaby Lake processors with hyper-threading
enabled. This defect can, when triggered, cause unpredictable system
behavior: it could cause spurious errors, such as application and system
misbehavior, data corruption, and data loss.

It was brought to the attention of the Debian project that this defect
is known to directly affect some Debian stable users (refer to the end
of this advisory for details), thus this advisory.

Please note that the defect can potentially affect any operating system
(it is not restricted to Debian, and it is not restricted to Linux-based
systems). It can be either avoided (by disabling hyper-threading), or
fixed (by updating the processor microcode).

Due to the difficult detection of potentially affected software, and the
unpredictable nature of the defect, all users of the affected Intel
processors are strongly urged to take action as recommended by this
advisory.

DO I HAVE AN INTEL SKYLAKE OR KABY LAKE PROCESSOR WITH HYPER-THREADING?
-----------------------------------------------------------------------
The earliest of these Intel processor models were launched in September
2015. If your processor is older than that, it will not be an Skylake
or Kaby Lake processor and you can just ignore this advisory.

If you don't know the model name of your processor(s), the command below
will tell you their model names. Run it in a command line shell (e.g.
xterm):

grep name /proc/cpuinfo | sort -u

Once you know your processor model name, you can check the two lists
below:

* List of Intel processors code-named "Skylake":
http://ark.intel.com/products/codename/37572/Skylake

* List of Intel processors code-named "Kaby Lake":
http://ark.intel.com/products/codename/82879/Kaby-Lake

Some of the processors in these two lists are not affected because they
lack hyper-threading support. Run the command below in a command line
shell (e.g. xterm), and it will output a message if hyper-threading is
supported/enabled:

grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && \
echo "Hyper-threading is supported"

Alternatively, use the processor lists above to go to that processor's
information page, and the information on hyper-threading will be there.

If your processor does not support hyper-threading, you can ignore this
advisory.

WHAT SHOULD I DO IF I DO HAVE SUCH PROCESSORS?
----------------------------------------------
Kaby Lake:

Users of systems with Intel Kaby Lake processors should immediately
*disable* hyper-threading in the BIOS/UEFI configuration. Please
consult your computer/motherboard's manual for instructions, or maybe
contact your system vendor's support line.

The Kaby Lake microcode updates that fix this issue are currently only
available to system vendors, so you will need a BIOS/UEFI update to get
it. Contact your system vendor: if you are lucky, such a BIOS/UEFI
update might already be available, or undergoing beta testing.

You want your system vendor to provide a BIOS/UEFI update that fixes
"Intel processor errata KBL095, KBW095 or the similar one for my Kaby
Lake processor".

We strongly recommend that you should not re-enable hyper-threading
until you install a BIOS/UEFI update with this fix.

Skylake:
Users of systems with Intel Skylake processors may have two choices:

1. If your processor model (listed in /proc/cpuinfo) is 78 or 94, and
the stepping is 3, install the non-free "intel-microcode" package
with base version 3.20170511.1, and reboot the system. THIS IS
THE RECOMMENDED SOLUTION FOR THESE SYSTEMS, AS IT FIXES OTHER
PROCESSOR ISSUES AS WELL.

Run this command in a command line shell (e.g. xterm) to know the
model numbers and steppings of your processor. All processors must
be either model 78 or 94, and stepping 3, for the intel-microcode fix
to work:

grep -E 'model|stepping' /proc/cpuinfo | sort -u

If you get any lines with a model number that is neither 78 or 94, or
the stepping is not 3, you will have to disable hyper-threading as
described on choice 2, below.

Refer to the section "INSTALLING THE MICROCODE UPDATES FROM NON-FREE"
for instructions on how to install the intel-microcode package.

2. For other processor models, disable hyper-threading in BIOS/UEFI
configuration. Please consult your computer/motherboard's manual for
instructions on how to do this. Contact your system vendor for a
BIOS/UEFI update that fixes "Intel erratum SKW144, SKL150, SKX150,
SKZ7, or the similar one for my Skylake processor".

NOTE: If you did not have the intel-microcode package installed on your
Skylake system before, it is best if you check for (and install) any
BIOS/UEFI updates *first*. Read the wiki page mentioned below.

INSTALLING THE MICROCODE UPDATES FROM NON-FREE:
-----------------------------------------------
Instructions are available at:

https://wiki.debian.org/Microcode

Updated intel-microcode packages are already available in non-free for:
unstable, testing, Debian 9 "stretch" (stable), and Debian 8 *backports*
(jessie-backports).

THE MICROCODE PACKAGES FROM THE RECENT STABLE RELEASE (June 17th, 2017)
ALREADY HAVE THE SKYLAKE FIX, BUT YOU MAY HAVE TO INSTALL THEM.

Updated intel-microcode packages in non-free for Debian 8 "jessie"
(oldstable) are waiting for approval and will likely be released in the
next non-free oldstable point release. They are the same as the
packages in non-free jessie-backports, with a change to the version
number.

The wiki page above has instructions on how to enable "contrib" and
"non-free", so as to be possible to install the intel-microcode package.

Users of "jessie" (oldstable) might want to enable jessie-backports to
get *this* intel-microcode update faster. This is also explained in the
wiki page above.

MORE DETAILS ABOUT THE PROCESSOR DEFECT:
----------------------------------------
On 2017-05-29, Mark Shinwell, a core OCaml toolchain developer,
contacted the Debian developer responsible for the intel-microcode
package with key information about a Intel processor issue that could be
easily triggered by the OCaml compiler.

The issue was being investigated by the OCaml community since
2017-01-06, with reports of malfunctions going at least as far back as
Q2 2016. It was narrowed down to Skylake with hyper-threading, which is
a strong indicative of a processor defect. Intel was contacted about
it, but did not provide further feedback as far as we know.

Fast-forward a few months, and Mark Shinwell noticed the mention of a
possible fix for a microcode defect with unknown hit-ratio in the
intel-microcode package changelog. He matched it to the issues the
OCaml community were observing, verified that the microcode fix indeed
solved the OCaml issue, and contacted the Debian maintainer about it.

Apparently, Intel had indeed found the issue, *documented it* (see
below) and *fixed it*. There was no direct feedback to the OCaml
people, so they only found about it later. (not a year later, weeks later)

The defect is described by the SKZ7/SKW144/SKL150/SKX150/KBL095/KBW095
Intel processor errata. As described in official public Intel
documentation (processor specification updates):

Errata: SKZ7/SKW144/SKL150/SKX150/SKZ7/KBL095/KBW095
Short Loops Which Use AH/BH/CH/DH Registers May Cause
Unpredictable System Behavior.

Problem: Under complex micro-architectural conditions, short loops
of less than 64 instructions that use AH, BH, CH or DH
registers as well as their corresponding wider register
(e.g. RAX, EAX or AX for AH) may cause unpredictable
system behavior. This can only happen when both logical
processors on the same physical processor are active.

Implication: Due to this erratum, the system may experience
unpredictable system behavior.

We do not have enough information at this time to know how much software
out there will trigger this specific defect.

One important point is that the code pattern that triggered the issue in
OCaml was present on gcc-generated code. There were extra constraints
being placed on gcc by OCaml, which would explain why gcc apparently
rarely generates this pattern.

The reported effects of the processor defect were: compiler and
application crashes, incorrect program behavior, including incorrect
program output.

What we know about the microcode updates issued by Intel related to
these specific errata:

Fixes for processors with signatures[1] 0x406E3 and 0x506E3 are
available in the Intel public Linux microcode release 20170511. This
will fix only Skylake processors with model 78 stepping 3, and model 94
stepping 3. The fixed microcode for these two processor models reports
revision 0xb9/0xba, or higher.

Apparently, these errata were fixed by microcode updates issued in early
April/2017. Based on this date range, microcode revision 0x5d/0x5e (and
higher) for Kaby Lake processors with signatures 0x806e9 and 0x906e9
*might* fix the issue. We do not have confirmation about which
microcode revision fixes Kaby Lake at this time.

Related processor signatures and microcode revisions:
Skylake : 0x406e3, 0x506e3 (fixed in revision 0xb9/0xba and later,
public fix in linux microcode 20170511)
Skylake : 0x50654 (no information, erratum listed)
Kaby Lake : 0x806e9, 0x906e9 (defect still exists in revision 0x48,
fix available as a BIOS/UEFI update)


References:
https://caml.inria.fr/mantis/view.php?id=7452
http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog
https://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v6-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v5-spec-update.html
https://www.intel.com/content/www/us/en/products/processors/core/6th-gen-x-series-spec-update.html

[1] iucode_tool -S will output your processor signature. This tool is
available in the *contrib* repository, package "iucode-tool".

--
Henrique Holschuh

We need to keep getting the word out so people know to look for updated BIOS's and firmware for their laptops.

You can follow the mailing list conversation where that warning was posted here:

Date Index:
https://lists.debian.org/debian-devel/2017/06/maillist.html#00322

Thread Index:
https://lists.debian.org/debian-devel/2017/06/threads.html#00322

The discussion may jump subject names, so it's best watch both indexes...

Let's not clog up this thread with this discussion, that's why I posted a link back to the thread:

Skylake / Kaby Lake Hyper-threading bug

 

An easy example of a title that constantly dips from 120+ FPS, down to 60, is Guild Wars 2. We also see it in titles like Watch Dogs (1 and 2) and Fallout 4 in specific towns. It is a thing that happens, and it's primarily caused by being IO-Bound by the CPU. Having an extremely power GPU will not change that. Minimum framerates are not dictated by the GPU at all, unless the GPU itself is the bottleneck. This is why 1% and 0.1% frametime analysis exists. Also, limiting frames with an external program (Nvidia Inspector for example) can introduce input lag. I don't know why that is, or why it's not an issue when implemented at an engine-level, but for some reason, it happens. Here is another test from Battle(non)sense showing their results when testing between the two:


While I agree that the amount of input lag won't be noticed in casual games, it will certainly be felt in competitive twitchy shooters.

 

Debian developers aren't looking for clicks

If the reporting media are looking for clicks there are a lot more salacious things to report on than CPU Errata.

The problem can show up as data corruption and not just OS hangs or crashes.

If you are thinking about the year old Skylake bug that was causing hangs and crashes, this isn't it. This errata affects a wider range of CPU's including Xeon's, Pentium, Kabylake, and Skylake.

Before you dismiss something out of hand, read the source and find out about it first.

It's not what you think it is, it's a new fix from Intel as of April 2017.

 

I did read the source. I read it when it was first posted on an entirely different forum, but it changes nothing. This issue has been around for quite some time, and most of us have not suffered random crashes because of it. Even the debian group admits it's a very niche situation, where running specific code from specific instruction sets causes the issue. I also read your post of it, where you included an article from The Register, in which they stated: " Debian devs noticed errata to deep docs and now the fit's hitting the shan" .

It's really not that big of a deal. The debian group even said "affected users" should disable hyperthreading. This implies those who were not affected by it, shouldn't disable their HT. As I've said before, I've owned several Skylake/Kaby CPU's. The Pentium G4400, the i3 6100, i5 6600T, 6700k and now a 7700k. None of these CPU's had instability outside of my normal OC stress tests that required a little more vcore/lower clocks. None of it was related to HT. I've ran VM's, copious amounts of stress tests (Prime95, Linpack MKL, etc), and plenty of gaming sessions that never caused my stability to suffer as a result of HT being active. I've reached out on 2 different forums, to see if others had been impacted by this little HT issue, and nobody seems to believe they were impacted by it in the slightest. My entire point is: don't freak out and disable things just because someone found a specific way to "break" something. If you people saw half of what was listed on Intel's errata list, you'd be afraid of booting into Windows without spontaneous combustion, lol. I mean, they've been trying to make TSX work for years now, and it still causes memory corruption since Haswell, lol.

 

Having been through Hyper-threading bugs from the beginning of Intel's HT CPU's, I feel it's reasonable to take a problem like this seriously and disable Hyperthreading until you have a BIOS patch to fix it, especially if you are experiencing any instability.

You can dismiss it if you like for yourself, but don't belittle an actual bug by expressing hyperbole at the futility of avoiding running PC's with bugs or without bugs.

Your comment is as bad as the troll that claimed essentially the same in the OCN post, and that's too bad. At least he was more concise.

 

You are going around spreading mis-information, as anyone that has tried to OC an iGPU has found, the CPU is now without OC headroom.

The iGPU takes away power budget and thermal budget from the CPU.

When Asus introduced Optimus in their G750 line, the only difference was the new GPU's, the CPU's were the same except this time their iGPU's were enabled.

The CPU temps went up 10c at load due to the additional iGPU power and heat load added to the CPU package.

Owners that had upgraded to the new GPU's found they could no longer run their batch jobs because the same CPU load was causing temps 10c higher which forced them to detune their CPU's - reduce the multipliers to stop the thermal throttling.

If you have a fantasy in your head, a theory about how hardware works, then before spreading that imagining publicly, test it out - prove it out - on real hardware.

Because forcefully spreading false information isn't helping anyone.

 

Yes, I am as bad as some random troll for using basic reasoning. I've said several times already, that if you run your PC in a mission critical environment, to err on the side of caution, but it seems you are getting overly emotional over something that isn't as important as you are trying to paint it out to be. How hard is it to understand that if you didn't crash from this issue in the 2+ years Skylake has been out, that you might just be fine without it? That's all I am saying. If you are suffering issues with HT, by all means, disable it. If you wish to dismiss me as another "troll" for making these claims, by all means, you have the freedom to do so, but it won't make what I say any less meaningful. For any others that wish to glance over my previous words to push a doomsday rhetoric, here is what I said:

 

Your basic reasoning also falsely thought that the iGPU doesn't interfere with CPU OC, when it does. I thought I'd do some background on you as you seem to have a Modus Operandi to your posts.

Anyone that has done these things in real life with real hardware, for many many years can spot the "reasoning" or "dream think" that you espouse.

Maybe lean away from posting things you've "reasoned" and actual do them in real life to get the true experience we want to hear, we don't need your musing's as they are clearly not based on fact.

 

You have a serious problem with reading. Let me assist you with that.

I understand you wish to twist my words, and add "overclocking iGPU's" to change the context, but it won't change the fact that you are wrong. Simply having an iGPU enabled does NOT impede your overclocking in situations where you are not being limited by a package power limit. For something so simple to test, I am surprised you are even going to try to contest this. In fact, we even have the Kaby Lake-X (7740X) chips to further prove my point, as their overclocking headroom has not improved AT ALL over the 7700k, and performance is identical. You've yet to find a single post by me on this forum where I go around "spreading misinformation". You are simply annoyed that I don't agree with your random "THE WORLD IS ENDING, DISABLE HT NOW!" nonsense.

 

I have. In fact, i've built quite a reputation on several forums with the knowledge i've earned. If you'd be less of a child, and present me a methodology to test, I'll gladly disprove your theory. If you are trying to say having the iGPU enabled will hinder CPU overclocking (in a situation where a package power limit is not imposed) then you are certainly going to eat some crow. I can test that for you right now if you'd like.

 

If the iGPU exists but isn't powered on or used - the dGPU is only used - then there is no difference. That's the state of the G750 dGPU only models the season before iGPU was enabled with Optimus.

If the wording wasn't clear, that's what I was saying.

What you were saying was clearly alluding to the iGPU being enabled - switched on:

Which clearly set's up the situation I described where the iGPU being enabled steals power budget and thermal budget from your CPU and will in fact impact your CPU's functional capabilities.

For the Asus G750 at stock settings - no OC - the temps at full load doing work went up 10c, and the only change was the iGPU enabled.

There is no way to disable the iGPU, it's wired on and wired directly to the display, so you are stuck with it.

The only solution is to under clock, no OC, your CPU - which I described as reducing the core multiplier(s).

Is that clear enough? My response to your mis-information was valid and needed to be said to stop you from passing on that mis-information.

 

Sorry, man, spent years helping people with that very problem. So you aren't going to prove it doesn't exist.

Take a powder and try me a different subject.

 

You need not explain the context of my words, for they speak for themselves. Yes, I said that the iGPU being enabled, doesn't impact CPU overclocking in any way, as long as a package power limit is not being imposed. I went on to say this point was moot with Prema bios being installed, as it circumvents the power limits. I don't know what you are reading, or what you think my words mean, but they are not wrong, nor were they presented in a way that "spreads misinformation". With your iGPU being enabled, lets say in an Optimus setup, it will not impact CPU overclocking headroom unless your CPU has a package power limit. Even then, it wouldn't be to a noticeable degree due to the quadratic scaling of voltage in regards to power consumption/thermals.

Then from those many years, present a single case for me to study. If I find what you say to be true, i'll admit to it. You may believe to have "years of experience" over me, but understand I've been doing this for a very long time too. I've even gone as far to test this recently (albeit, in a desktop environment) and the results are exactly as I expected. I do have laptops that suffer from a package power limit, and undervolting the iGPU does indeed improve CPU clock speeds when such a limit exists, but that is completely outside of the context in which I spoke. If you can provide a single case where no package power limit was imposed, and yet the iGPU being enabled (and active) caused the CPU to achieve lower clock speeds, then I'll believe you. If you cannot provide that source, then we are going to remain in this loop of "no, I'm right!" until one of us is proven wrong.

 

http://hwbot.org/hardware/processor/core_i7_7700k/ vs. http://hwbot.org/hardware/processor/core_i7_7740x/

 

What's with this "package power limit" fixation you have? It's irrelevent, or to be more precise it enters in to every situation - up to a power you are always going to be power limited, either by the CPU design limits, or the physical limits of the power system.

Anyway, here is what I was talking about with the Asus G750 enabling iGPU, that messed people up from the previous generation.

I have over 5k posts there, it took a while to find what I was looking for, my work with dblkk, he was technical enough to work with and got the problem when I described it along with potential solutions.

After working with dblkk and dozens of others over several years, it's clear that iGPU is a real detriment to CPU performance, and gets in the way in the form of Optimus when trying to use your dGPU in all things (you can't on Optimus).

THINGS TO TRY ~CPU OVERHEATING JM/JS/JZ MODELS
https://rog.asus.com/forum/showthre...M-JS-JZ-models&p=412319&viewfull=1#post412319

There are thousands of other posts about Optimus and people trying to tune their G750 to avoid the iGPU tax, look around during that time and long after that thread.

The iGPU power and thermal drag on the CPU made them reduce the CPU core multipliers to get through heavy work they were previously able to do just fine on their last year's model that didn't have iGPU enabled or Optimus, proving that the enabled / powered / in use iGPU is a drag on the CPU.

Have fun

 

A 2% difference in clock speeds on LN2? Jesus, that was less than I thought, lol. Could have sworn I saw articles claiming he hit 7.6, though I suppose 7.56 is "close enough". Any who, back to real life results: http://www.gamersnexus.net/hwreviews/2965-intel-i7-7740x-cpu-review-vs-7700k-not-worth-it/page-3 (5.1ghz no-delid, 100C under a 280mm AIO at 1.37v), https://www.forbes.com/sites/antony...-really-an-overclocking-monster/#6758ad3145b6 (5.2ghz no-delid, 1.41v, thermal results not included), (5.3ghz delidded, 56C under load due to delid/CLU on die)

Either way, I have not seen a sample go beyond 5.3ghz, something we've seen quite commonly on the Kaby owners thread over at OCN. My chip can do 5.3 as well, but the obscene voltage required makes it questionable, given 1.37v (1.39v after LLC level 2 kicks in) makes 5.2 stable, and 5.3 requires over 1.44v (1.46 at same LLC settings). We are also talking a 16C difference in thermals under this EVGA 280 CLC. Either way, this might change once these CPU's launch, and we have a larger sample size to base some real statistics off of it, but for now, I just don't see the difference. Some blame the mildly higher clock speeds on the extra grounding contacts, others on the process refinement (and some here believe it to be the lack of an iGPU), but we can't really know until we get that larger sample size, and some actual delids.

It can't be irrelevant if you yourself brought it up as well, lol.

Package power limits are relevant because they dictate how long your CPU can maintain it's clocks before a throttle is imposed. With an iGPU being part of that package, it's power consumption will impact your CPU clocks in that regard. There is also the issue with the thermals imposed by using the iGPU, but it's actually not that big of a deal (at least, when comparing against dGPU's using a shared-heatsink design, as it's still easier to dissipate the heat in that situation). Either way, I honestly appreciate you taking the time to give me something to read over. I'll give it a look, and test (to the best of my abilities) what I find in that thread to see if the conclusion you came to was the right one.

 

Now you're being silly, I answered you, I didn't bring it up.

The *CPU* "power limit timeout" is irrelevant to the primary impact of the iGPU power draw and thermal budget stealing from the CPU.

The level of hit varying due to CPU power limit isn't the main problem, the problem is that the iGPU is always on and always drawing power because the iGPU is handling all the display traffic.

That's the main problem - even if the dGPU is being accessed for rendering the iGPU is drawing power and adding heat to the CPU while handing the display.

That's why rendering jobs running against the dGPU were heating up the CPU and causing thermal throttling - unless the multipliers were tweaked to drop the CPU power/thermal load.

Read the thread, search for Optimus discussions around that time, along with many other threads I helped people debug those thermal problems in games, not just heavy rendering tasks.

Here's a reply post where I described the iGPU / Optimus issue at length:

WHY I FEEL BETRAYED BY MY G750JZ. AND WHY I HATE OPTIMUS.
https://rog.asus.com/forum/showthre...i-hate-optimus&p=447310&viewfull=1#post447310