Prime z370-a bios 0607

[katlani]

Hi,

PRIME Z370-A BIOS 0607
Improve system stability.

Does it also include the micro code update most of us decided to stay away from which was introduced on 0606 version?

[Retired]

pokuly wrote:
Did you try the violent way? https://rog.asus.com/forum/showthread.php?99490-Flash-any-most-Asus-motherboard-Bios-in-DOS-with-USB...
You may reenter your MAC address afterwards with eeupdate.exe so i advice to write it down before. https://rog.asus.com/forum/showthread.php?100441-Update-microcode-for-Spectre/page2#post709330

Hi Gents. We cannot down grade our BIOS 0805. This is due to the included Intel ME security code.

[janos666]

This topic sums up my overall experiences with the firmware updates pretty well. But I guess it won't hurt if I summarize them on my own.

pokuly wrote:
0607 and 0606 still use microcode 7C for my 8700k.

pokuly wrote:
I tried the beta 5605 one day and write performance was good. They use microcode 6E in this version.

Yeah, that's what I gathered. As much as I know,

• 7C was the first spectre-related CoffeLake microcode we (the public) encountered (in forms of motherboard firmware packages)
  
• ASUS Z370-A motherboard firmware versions starting from 0606 have 7C or higher Intel CPU microcode versions (and all >=7C versions have the spectre fixes)
  
• many consider the 7x CL microcodes faulty (or at least pre-production/~beta, since Intel removed that bundle package from their site after some people experienced some problems with some CPUs, although it later turned out that not all spectre-related microcodes were faulty) but 8x versions are considered production-ready/~stable (since everyone --- Intel, manufacturer partners and users --- had some time to figure things out and new microcode revisions popped up)
  
• there is yet another fix for a new spectre variant in the latest 90-something microcodes (I am not sure about the exact number but 96 should have it and this 96 is also considered production-ready/~stable whereas earlier 9x version are probably ~beta)
  

pokuly wrote:
It is a shame a new 8700k coffee lake running 3200 CL14 RAM feels sometimes slower and more hiccuped compared to an old z77 3570k DDR3 1866.

Well, yeah, but we should compare all these platforms after updating them all to their respective (spectre-fix related) firmwares while running the same version of an OS with all these spectre fixes enabled.

pokuly wrote:
I did build my system the day BIOS 0606 came out. If i had known what a performance disaster the Intel spectre bug was i had surely decided against a new Intel system. Intel internally did long know about it and fooled us. More as 30% performance hit for a RAMdisk alone for the Spectre fix.

That's not so clear in my opinion. As much as I know,

• old Intel CPUs suffer more (relatively to their own pre-spectrefix states), so new CPUs are still somewhat faster (at least in-house, with their matching spectre-fix states)
  
• I am still yet to see convincing benchmarks if the competition (AMD Zen) with their respective fixes in place (don't forget they are also vulnerable to some variants and they also have some fixes out on their own) are now ahead in performance (or just got even, or still behind...).
  

Of course, the problem is that not everything is easy to benchmark. I also felt like the machine was simply unable to multi-task (like it was a single core CPU with a not too smart OS scheduler) with the 7x (or even early 8x?) microcodes. The entire Windows desktop could just freeze from a simple background task (like scheduled backups which were previously seamless but now felt like they are running at high priority and are much more demanding than ever imaginable). But later (>80?) microcodes were usable again. Yet I think my games are running more "stuterry" with >90 versions and the new Win10 updates (which have the fixes for the latest v4 spectre variants).

So, it is pretty much still a mess right now but it's hard to remember how the old (in my case an i5-2500K) felt and I don't have an AMD Zen platform to compare in these subjective empirical experiences like the perceived "smoothness" of a game (and even then the Win10 and nVidia driver updates also change other things, so everything is pretty much in a constant flux, spectre or not... making these things hard to pinpoint...).

It's also hard to tell if overclock capabilities have anything to do with CPU microcodes (or were subject to other motherboard firmware changes), and if so then have anything to do with spectre fixes, and then if they are really "detrimental" or not (a minimal change in max clocks or required voltages were pretty normal in the past, often depending on microcode updates before spectre, in older generations as well). But yeah, I also noticed I lost a little bit of OC headroom during the updates (just 1 tick on the multiplier but still).

pokuly wrote:
btw. the PRIME Z370-A for overclocking isn't the very best choice. VR thermal throttling in a good ventilated case for Prime95 with AVX@6x4.6GHz 1.168V is not exactly a masterpiece. 60% minimum for a DC fan...

It's not bad either if you wish to use a custom water cooler (like the EK monoblock) for the VRM anyway. Although I think I can max out my VRM capacity with my 8600K and a slow passive water cooling around 4800/4600 MHz (core/cache) and 1.31V (nominal Vcore with minimal Vdrop with the load-line compensation). So, it's not for extreme OC but should cover the "honest" (actually 24/7/365 stress-test stable) and sane (when you can settle for anything "nice enough" rather than "I must have XY clocks no matter what") overclocks.

[pokuly]

You did a nice writeup.
The obvious hiccups indeed are gone. On some tasks i have small pauses i didn't experience before still.
Over time the windows and µC updates did fix some behaviour but some of the speed simply is gone forever because of the Intel security hole fixes.
From day 1 without Spectre to today with all Spectre fixes enabled and µC 96 i saw the CUEtools flac encoder slowing down from ~150x speed to now ~130x speed for example.
The overclock is 100% solid with this board since i added a tiny bit of more voltage after µC 84.

[janos666]

pokuly wrote:
You did a nice writeup.

Yet I cut it short before asking a few questions, like:

• Did anybody ever test if the microcodes alone change anything to the worse (in terms of multitasking capability or videogame "smoothness")? Is it really enough to flip the "Disable/Enable Mitigation" switches in the OS (FeatureSettingsOverride and it's mask set to 3 in regedit) to test the entire range and extent of them?
  

I updated the nVidia driver and tried to disable all mitigations today and the stuttering persists. Although I only see it in a relatively old game (which I don't play with anymore, I just keep it around for testing). During this, I realized the Spectre V4 mitigation was never enabled on my PC because I load the v96 microcode too late (I use the VMWare driver instead of customizing my motherboard firmware).

pokuly wrote:
The overclock is 100% solid with this board since i added a tiny bit of more voltage after µC 84.

On the OC front, I noticed two things:

• Long running stress-tests (Prime95 or LinX) tend to be stable only when I set the Vcore and V-Standby to an equal value.
  
• The machine tends to shut down after some heavy stress-testing (manly LinX 9.x after 20+ minutes) when I set the V-Standby to anything above 1.31V
  

(SVID Disabled, fix manual voltage mode, all cores at the same fixed multiplier, cache at fixed multiplier, all kinds of configurable power limiters set to maximum possible values, every configurable power-save features disabled.)

I guess something (probably some protection, may be over-heath) causes the Vcore to fall back to the Standby Voltage (effectively trying to reduce the voltage to fixed 1.0V in a standard case where Stadby Voltage is unaltered) and when this happens (the voltage drops for a split second) the stress-test fails with an error.
On the other hand, it remains stable (no error) if the voltage remains stable (that one specific protection is effectively mitigated with no ill side-effect).
However, if the voltage remains stable but too high, another protection (shutdown) kicks in.
It's hard to tell since monitoring is imperfect (software like HWInfo won't poll every sensors as fast as the firmware can and even then the display and my human eye have limited frame rate, so I won't see short lived peak temps and things like that at millisecond levels...).


Did anybody have similar experience?
I wonder is it's related to the sheer voltage (may be some self-protection mechanism doesn't like high Standby Voltage settings) or some temperature(s).

[pokuly]

Since the VRM thermal throttling kicks in for AVX even @4.6 i didn't overrclock much so i am of no help, sorry.
For 4.8 AVX 2 i only need to set an offset +0.050 Vcore with low LLC 2, SVID default. For normal AVX apps VRM doesn't throttle under these settings but Prime95 after a while. I have not found any stress test that fails.
The Macho cooler gets the CPU itself easily cooled with silent Qfan defaults this way.

Edit: Two things i want to add.
I found LinX 0.9.1 an this is a real heater within AVX usage. XTU shows even a few watts more TDP as the most heavy Prime95 load 🙂
About Microsoft enabling the Spectre 4 patch by default i had the same theory as you because the last big update saw a system with old µC.
I am not so sure. It may be they let it disabled due to the additional performance hit and because intel claims this vulnerability is hard to use.

[janos666]

pokuly wrote:
About Microsoft enabling the Spectre 4 patch by default i had the same theory as you because the last big update saw a system with old µC.
I am not so sure. It may be they let it disabled due to the additional performance hit and because intel claims this vulnerability is hard to use.

ASUS Z370-A firmware 0809 is just out for our boards and comes with CF microcode 96.
And it looks like the Spectre-V4 mitigation is NOT enabled by default on Win10 (1803 with CU-2018/06):

PS C:\WINDOWS\system32> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]
For more information about the output below, please refer to https://support.microsoft.com/en-in/help/4074629

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass mitigation is present: True
Windows OS support for speculative store bypass mitigation is present: True
Windows OS support for speculative store bypass mitigation is enabled system-wide: False


BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : False

I guess Microsoft decided to ship the patch asap but leave the new mitigation disabled by default for some time (probably due to the various issues from last time around). This article also indicates S-V4 mitigation is disabled by default: https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-..., although I remember a similar thing being said about S-V2 back in the days (it was similarly cited as op-in but turned out to be enabled by default in practice, at least by the time I started reading...).

I tried enabling it manually (by setting FeatureSettingsOverride to 8 and it's mask to 3, as per the article above) and it works (according to the Get-SpeculationControlSettings script, SSBDWindowsSupportEnabledSystemWide is now True).

[pokuly]

I sound that here https://news.softpedia.com/news/microsoft-releases-windows-10-patches-for-spectre-variant-4-521540.s...
"In order to enable the new mitigations, registry modifications are also required"
I leave it enabled because i don't feel additional hits here. Flac encoding, Crystal Disk Mark and Cinebench measure the same. It may be ok to use on coffee lake and z370.
I still didn't find a way to check for Spectre 3a.

[janos666]

Looks like ASUS removed the 0809 version and replaced it with 1002. The CL microcode remains the same: 96
I wonder if they found some relatively serious bug because they still list a bunch of old releases (bet the new change log won't tell).

Sidenote: It looks like they stopped updating the SkyLake microcode. Not like I cared to try if the board boots with one of those but the C3 version is still there (that was the spectre-v2 update, so they maintained it for some time since the initial release but C6 is already out for spectre-v4).

[pokuly]

I flashed 1002 and all speed numbers seem to be unchanged. The Intel VGA GOP 1080 driver is newer if i remember right. It may fix problems with the new 144Hz monitors Nvidia lately also fixed in GOP ROM!?

[janos666]

pokuly wrote:
The Intel VGA GOP 1080 driver is newer if i remember right. It may fix problems with the new 144Hz monitors Nvidia lately also fixed in GOP ROM!?

Possible. Although I think that was some nVidia specific thing (*) since DisplayPort should normally be both back- and forward-compatible between v1.1 and v1.4 without firmware updates (v1.0 could potentially cause damage but zero consumer product uses v1.0). And it concerned displays with v1.3 and v1.4 while CoffeeLake is limited to v1.2 but Pascal cards were sold as "probably v1.4 compatible" (* they were not validated with final compliance tests at the time -> and looks like they were not lucky enough...).