• Please review our updated Terms and Rules here

The New Z170 Motherboards

Oh my heavens...32 gigs of RAM. I had an XPS 720 with 8 gigs max, although I do have two Precision 390's here each with 48 gigs.

I've been thinking about bumping the RAM up to 32 GB 3200, but it's hard to justify. I don't know how much of performance boost I would gain, if any. However, prudent reasoning hasn't stopped me so far. My justification would be a nephew wants me to lend a hand on a new AMD gaming rig sometime next year.
 
It's been a little over a year since I started the Z170 build and now it's finally finished. The project was indeed an adventure, and while cost was not my primary concern, performance was. It always seemed like I was playing "catch up" when it came to putting a gamer together. I realize that the Z270 and Kaby Lake have arrived, but any perceived performance gains from that pair should be considered minimal according to recent technical reviews. The following is a list of components:



  • Case - Corsair Vengeance Series C70 Military

  • Motherboard - Asus Z170-Deluxe

  • CPU - Intel Core I7-6700K

  • RAM - G.Skill Ripjaws 4 Series 16 GB (4 x 4) DDR4 3000

  • System Hard Card - Samsung 950 M.2 500 GB

  • Hard Drive - WD Velociraptor 600 x 2 (10000 RPM)

  • Optical Drive - LG CH22NS50

  • Graphics - Asus GTX 1080 Turbo x 2 (SLI)

  • Cooling - Corsair H100i Liquid

  • Monitor - Asus PD27AQ 4K IPS G-Sync

  • PSU - Seasonic Prime Titanium 850

  • Keyboard - Corsair Vengeance K70 (Red)

  • Mouse - Logitech G900 Chaos Spectrum Pro

  • Audio - Edifier R1700BT Stereo Sound System

  • OS - Window 10 Pro

If you have built a similar system, or intend to in the future, I would appreciate your comments and suggestions concerning my choice of components.
 
The RAM is a bit of a waste, the i7-6700k only officially supports up to 2133, getting it to run at 3000 requires bus overclocking which usually results in system instability in my experience.

Not a fan of ASUS motherboards either, warranty issues are a nightmare and I still remember all of the horrific problems their Athlon XP/64/AM2 boards had.
 
The RAM is a bit of a waste, the i7-6700k only officially supports up to 2133, getting it to run at 3000 requires bus overclocking which usually results in system instability in my experience.

Not a fan of ASUS motherboards either, warranty issues are a nightmare and I still remember all of the horrific problems their Athlon XP/64/AM2 boards had.

I sort of disagree with your assessment of the I7-6700K maximum RAM speed. While the recommend speed is as you state, if your system is setup with the XMP option, then the DDR4 max is 3866. My RAM was selected from the Asus QVL and is well within their specs. As far as Asus tech support goes, I replaced the original mobo via a cross shipment within 72 hours. I've never experienced and problems with Asus myself.

2133 MHz, 2800 MHz (O.C.), 2666 MHz (O.C.), 2400 MHz (O.C.), 3
000 MHz (O.C.), 3200 MHz (O.C.), 3300 MHz (O.C.), 3400 MHz (O.C.),
3333 MHz (O.C.), 3466 MHz (O.C.), 3733 MHz (O.C.)

Thanks for your input, most appreciated.
 
I will say upgrading your RAM speed is a fairly depressing upgrade. I don't even bother anymore.

As for Z270, the main reason I'd want a 7700K is because they seem to overclock to near 4.9-5Ghz - even on air coolers - but at stock speeds, a 6700K will perform about the same.

Overall sounds fantastic, I can't even justify/afford one 1080 in our local economy.

Should be fun doing an AMD build with your nephew, I'm much happier with their Ryzen offerings than the previous FX series. Plus I'm sure he'll love that RGB cooler :)
 
I will say upgrading your RAM speed is a fairly depressing upgrade. I don't even bother anymore.

As for Z270, the main reason I'd want a 7700K is because they seem to overclock to near 4.9-5Ghz - even on air coolers - but at stock speeds, a 6700K will perform about the same.

Overall sounds fantastic, I can't even justify/afford one 1080 in our local economy.

Should be fun doing an AMD build with your nephew, I'm much happier with their Ryzen offerings than the previous FX series. Plus I'm sure he'll love that RGB cooler :)

Thanks for your input right off. I'm beginning to wonder about the importance of overclocking on these new builds. When I put this thing together, I had a heck of time with the OC. I couldn't get the Asus AI Suite 3 to install, which is a must for a system like this. It turned out that I needed to get into the W10 selective boot feature, which allows you to boot without loading virus protection, and all of that sort. Once properly installed, the OC function works like a dream, virtually automatic. The 6700K is based at 4 GHz and easily OC's to 4.7 Ghz, the 'sweet spot' for my rig (the boot screen tells you that you're 15% OC'd). I can take it higher and still be stable at just a little south of 5 GHz, but then you have a heat factor to consider, and not much of a real performance gain. With the two 1080's in SLI and G-Sync, FPS and the screen tear factor worries are a thing of the past. I can honestly says that this has been as close to a trouble free experience as one could expect. One item, however gave me a few anxious moments a few weeks back. I temporally lost my mind again and bought that Logitech G900 mouse. The software install caused lockups and multiple reboots. I was just about ready to go the restore point route when it rebooted one more and time and suddenly, all was well. I don't know and didn't ask. As far as OC'ing the RAM, it is what it is. I use the XMP function and the BIOS more or less takes care of it. Looking back, this type of build may not be everyone. You have the individuals who like or must always be tinkering with the system's CPU, GPU. and RAM settings. There's not a whole lot you can do, however, if don't want to use AI Suite 3, you can always jump into the BIOS and tweak to heart's content.

I'm looking forward to the AMD build with the nephew as he's going to spring for the chip, and I'll get the mobo.
 
I'm looking forward to the AMD build with the nephew as he's going to spring for the chip, and I'll get the mobo.

I'd hold off on a Ryzen build for the moment as there are still numerous issues with the platform, from multiple firmware issues to problems with SMT under Windows 10 to name just two areas of concern. Possibly hardware issues too as I've just seen this http://forum.hwbot.org/showthread.php?t=167605 which is worrying. Wait for Naples, AMD's implementation of Zen intended for servers, which is due sometime in the second quarter. That will need to be flawless at launch so I'd expect all of the issues with their desktop platform to have been ironed out by then.
 
I'd hold off on a Ryzen build for the moment as there are still numerous issues with the platform, from multiple firmware issues to problems with SMT under Windows 10 to name just two areas of concern. Possibly hardware issues too as I've just seen this http://forum.hwbot.org/showthread.php?t=167605 which is worrying. Wait for Naples, AMD's implementation of Zen intended for servers, which is due sometime in the second quarter. That will need to be flawless at launch so I'd expect all of the issues with their desktop platform to have been ironed out by then.

Thanks for that. It'll be summer before I get into that AMD build. Looks like that one particular benchmark doesn't like Ryzen. Probably a BIOS or chipset driver issue. When I started my Z170-Deluxe build, the BIOS was so primitive that it wouldn't see the 6700K. Sent it back for that issue and it turned out to be that it just needed a BIOS upgrade. Chicken and the egg problem; how are you going to know what you've got if you can't see it?
 
Last edited:
Thanks for that. It'll be summer before I get into that AMD build. Looks like that one particular benchmark doesn't like Ryzen. Probably a BIOS or chipset driver issue.

Maybe it is, or maybe it's a certain sequence of FMA3 instructions that happen to occur in this program when compiled with a particular compiler which is causing the freezing, freezing which only occurs on Ryzen-based machines as the same binary runs without issue on other x86 CPUs. That would point to a fault with the CPU itself.
 
Whoa, that's very bad. That's worse than the pentium fdiv bug. That's likely a die/design problem; you can't fix that with a motherboard update.

AMD might be able to fix it with microcode as they've done in the past so it could just be a BIOS flash away from being fixed. Hopefully not with a big performance hit attached to the solution this time though.
 
The Ryzen bug is probably fixable in microcode, so once they have it tracked down it will be fairly trivial to patch... it may be related to their use of a learning neural network to assign instructions to threads, causing a lockup. In which case it will probably be fixed fairly quickly. It's near as bad as the Pentium F00F bug: https://en.wikipedia.org/wiki/Pentium_F00F_bug but at least they can update the microcode, unlike the older chips.
 
Whoa, that's very bad. That's worse than the pentium fdiv bug. That's likely a die/design problem; you can't fix that with a motherboard update.

No it's not, stop spreading FUD.

The OP of the thread describes a single use case of a benchmark application he wrote crashing/locking up when using FMA instructions on Windows 10 (red flag 1.) Said benchmark application is compiled targeting the Haswell architecture (red flag 2), OP said that other professional benchmark utilities don't crash doing FMA operations (red flag 3) and someone else in the thread said Linux doesn't crash when doing this benchmark (red flag 4.)

We have four red flags here showing either user programming error, Windows 10 problems or compiler problems. None of these point to the CPU even being remotely an issue.

This hive mind mentality hopping on the AMD Ryzen hate train is getting ridiculous.

Just because AMD supports FMA, doesn't mean that it works 100% the same way Intel or anyone else implemented it. It'd be like trying to use similar functions across multiple programming languages and expect all of the operators to be the same, it's not going to work.
 
We have four red flags here showing either user programming error, Windows 10 problems or compiler problems. None of these point to the CPU even being remotely an issue.

If you take a piece of software that runs on one CPU, then locks up on a CPU that claims to be 100% compatible, and everything else is the same, isn't that a CPU issue?

This hive mind mentality hopping on the AMD Ryzen hate train is getting ridiculous.

I'm not on the hate train, I was going to build one next week! I'm just concerned. Now I have to wait.

Just because AMD supports FMA, doesn't mean that it works 100% the same way Intel or anyone else implemented it.

FMA isn't software, it's CPU instruction opcodes -- It had better work the same way Intel implemented it! Otherwise, it's like you're saying "well, ADD and SUB don't need to work exactly the way Intel implemented them" which is patently wrong.
 
It's near as bad as the Pentium F00F bug: https://en.wikipedia.org/wiki/Pentium_F00F_bug but at least they can update the microcode, unlike the older chips.

The best thing to do with the non-issue that was the F00F bug was to pretend it didn't exist, not try to work around it. This was because you'd never encounter it in any non-malicious software as it was an invalid use of an instruction, something a compiler or assembler would never generate, i.e. it would have to be hand coded. The Ryzen bug, if it really is a bug with the CPU (buggy firmware can have some strange effects), is actually of real concern since it is triggered by legitimate code.
 
If you take a piece of software that runs on one CPU, then locks up on a CPU that claims to be 100% compatible, and everything else is the same, isn't that a CPU issue?

If you read the post from the link, you wouldn't be asking this question because what you're saying is NOT what is happening. I already explained in my previous post why this is not a CPU problem.

He claims to be using FMA operations in his program, which is the program in question that crashes using FMA operations, and he goes on to explain that other programs that use FMA operations do not crash. This is why I attributed it to user programmer error, or compiler error. Using optimizations for an architecture other than the one you're currently working with is known to cause problems.

http://stackoverflow.com/questions/2722302/can-compiler-optimization-introduce-bugs

The question you should be asking is what is this programmer doing with his code that's causing crashing.

I'm not on the hate train, I was going to build one next week! I'm just concerned. Now I have to wait.

A programming bug because of user error in a specific use case isn't really grounds for holding off on Ryzen. It's not like the Intel 6 series chipsets with suicide SATA controllers.

FMA isn't software, it's CPU instruction opcodes -- It had better work the same way Intel implemented it! Otherwise, it's like you're saying "well, ADD and SUB don't need to work exactly the way Intel implemented them" which is patently wrong.

Just because two different companies that make CPUs which can conform to a specific instruction set, doesn't mean the registers used, opcode mnemonics, guaranteed execution time or opcode arguments are required to be the same. Only the end result is mostly guaranteed, though not in all cases.

http://stackoverflow.com/questions/1109569/do-intel-and-amd-processor-have-the-same-assembler
https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64
 
Back
Top