Intel's 10nm Cannon Lake CPUs Won't Arrive in Mass Quantities Until 2019, Company Says (pcgamer.com)

Intel said this week that it is once again delaying the mass production of its 10-nanometer "Cannon Lake" chips. The company insists that it is already building the chips in low volumes, but said it "now expects 10-nanometer volume production to shift to 2019 [rather than the end of 2018]." From a report: Intel is on solid footing, in other words, though pesky challenges remain in manufacturing its next-generation 10nm parts. CEO Brian Krzanich acknowledged as much during an earnings call, attributing the delay to difficulties in getting 10nm yields to where they need to be. So rather than push to ship 10nm in volume this year, Intel is giving itself some additional time to sort things out.

Comments

Intel in full damage control mode.

[Narcocide]

"No really guys. Don't buy that AMD chip yet. We promise that the next-gen chip we're making that will be so much faster than theirs really exists! We only need about 4 more quarters worth of earnings to prove it..."

Re:Intel in full damage control mode.

[capSAR]

Sounds like business as usual for Intel. I'm looking forward to trying out AMD for the first time, while they might not be perfect as a company I feel a bit better giving them my money.

Re:Intel in full damage control mode.

[TheRaven64]

It's much worse than this:

First, these are Cannon Lake chips. Remember Cannon Lake, due late 2016? Delayed until late 2017? Delayed until late in the first half of 2018? Yup, that Cannon Lake. Among other things, Cannon Lake was scheduled to introduce LPDDR4, so would be the first Intel mobile chips that could manage 32GB of RAM without using a huge power budget. If you think it's bad for Intel now, wait for the Apple fanboys to notice...

Second, one of the features that people have been waiting for since it was originally announced in 2016 and was expected to debut with Cannon Lake is Intel's Control-flow Enforcement Technology. This comprises two parts. The first is a set of magic nops that indicate a valid branch target and protect forward control flow arcs (any jump that isn't to a designated landing pad will trap in code marked as supporting the feature). The second is a secure stack. Every call instruction pushes the return address onto the main stack, but also onto a second stack (which is not readable or writeable by normal instructions). Each ret instruction checks the top of both stacks and traps if they disagree. Sounds great? That's what everyone thought last year, but unfortunately it is incompatible with the retpoline Spectre mitigation that is now fairly widely deployed, so CET is now impossible to deploy in the presence of code using retpolines (e.g. Chrome) and so needs to be redesigned very late in the schedule or skipped entirely.

Re:Intel in full damage control mode.

[Anonymous Coward]

Quad core or desktop Cannon Lake was cancelled loooong ago, so now it's strictly a dual core / quad thread CPU for low power. Thus while this LPDDR4 support is great news it won't be suitable for Macbook Pro. When Cannon Lake production ramps up though it's suitable for the Apple "Macbook".

Yes I would like to see a high end Apple netbook with 32GB RAM lol, afterall I always run out of RAM way easier than I run out of CPU.
I bet the PCIe SSD has enough I/O to run slashdot with all its users.

Interesting will be if "Whiskey Lake" has LPDDR3 or LPDDR4 support. The former would be heinous but this might be yet another Skylake respin.
https://en.wikichip.org/wiki/intel/microarchitectures/whiskey_lake

Architecture
Key changes from Coffee Lake

        Package and pin-compatible with Cannon Lake U
        Die from Coffee Lake U and Cannon Lake PCH

Yea right I have a scoop for you. Whiskey Lake is still stuck with 16GB LPDDR3, if you want 32GB in a trendy laptop or a tablet you'll have to wait for Ice Lake in 2019, or hope someone does a Cannon Lake laptop or tablet with 32GB in 2019.

Re:Intel in full damage control mode.

[jwhyche]

. I'm looking forward to trying out AMD for the first time,

You won't be disappointed with AMD this go around. Take a look at the specs for the new 2700X.

https://www.cpubenchmark.net/c...

That is a $329 chip and has better performance than the closest intel chip in that class, the 8700K. The 8700K is also $30 bucks more. Sure there are more powerful intel chips but those chips are in the $1000+ range.

You can also find AMD chips in that range too but if you are going to do a bitch'n build and not break the bank the 2700X seems to be the way to go.

Re:Intel in full damage control mode.

[jwhyche]

(Pro tip: try it with Linux!)

Okay. Lets see been running linux exclusively on AMD since the '486DX-133. Lets see, since that time I have run some variation of linux on every class of AMD processors. I have been running Centos on a AMD-8350 since 2012. In that time I have had exactly zero issue with linux and AMD processors.

Re:Intel in full damage control mode.

[Tough Love]

There was the segfault issue with early Ryzen production, requiring an RMA. Inconvenient, but AMD handled it with good style. Then there wass the soft lockup at idle issue, apparently resolved by the new "typical power" option in recent bios updates. Otherwise, Ryzen has been really sweet, including for virtualization. It is fair to say that the Ryzen introduction was a little bumpy, but the overall experience is so positive (massive parallel throughput, decent single-core, great power efficiency) that the user community is happy to cut AMD some slack. It's a bit early to say, but I think my Ryzen systems are now in that "golden uptime" zen state. I certainly had that with my Piledriver + Radeon system - uptime measured in months, typically only limited by something like a power outage or a kernel update.

Windows users never noticed either of the above Ryzen issues, it's not clear why. Maybe, they just never put their systems under enough load to get the segfault, or it's hard to distinguish those segfaults from normal life in Windows land anyway. For the idle power issue, maybe AMD quietly supplied a fix to Microsoft months ago, ahead of users noticing it. Don't know. But it's water under the bridge now, I see no compelling argument to build an Intel box now or in the foreseeable future. With the Ryzen 12nm refresh already landed and 7nm parts scheduled to sample around the same time as Intel's roughly equivalent 10nm parts, it's clear that Intel has lost its process edge to TSMC and Glofo.

Of course the real elephant in the room at the moment is Meltdown. Intel does not have a credible answer, while AMD just designed their parts right in the first place. For the moment, if you want a system that is not just one gaping security hole, plus performs decently, AMD is the only game in town.

Re:Intel in full damage control mode.

[jwhyche]

Thanks for bringing me up to speed. I was sniffing around Ryzen to replace my aging FX-8350 in my Centos box. I'm thinking that a 2700X would fit the bill.

Is "sort things out" an euphemism?

[sinij]

Is "sort things out" an euphemism for trying to patch gaping security holes?

Re:Is "sort things out" an euphemism?

[DavidMZ]

No, semiconductor manufacturing has just gotten awfully complicated. If Intel haven't found yet a process integration scheme that gives an acceptable yield, they are not going to put it on the market and sell it for a loss.

Discloser: I work in the semiconductor industry

Re: Thanks but no thanks, Intel

[Anonymous Coward]

You can't VMotion running VMs between Intel and AMD ESXi hosts. So it's not like I can just drop an AMD server into the cluster even if I wanted too. So, I'm kinda stuck with staying with Intel.

Alles Klar Kommissar

[hcs_$reboot]

So, the previous lineup Kaby Lake was also produced in low volumes, and this before the Spectre and Meltdown were revealed to the public, while Intel was aware... It seems 2018 is not the year they're gonna fix these two issues.

Re:Alles Klar Kommissar

[alvinrod]

They probably could fix those issues. The main hold up with the chips is that they've had no end of problems with their 10 nm process and it sounds as though there are still some substantial bugs to be worked out before they can go into full production. If they don't use this as an opportunity to fix the Meltdown/Spectre vulnerabilities, it would be a terrible mismove on their part.

Re:Alles Klar Kommissar

[TheRaven64]

Fixing meltdown is fairly simple - don't speculate across ring transitions. That will come with a small performance hit, but only a small one. Fixing Spectre is much harder because Spectre isn't really a vulnerability so much as a class of vulnerabilities with proofs of concept for the easiest things to attack. Fixing Spectre means making sure that no side effects of speculation, including timing, are visible. That means, among other things, no cache fills or evictions during speculative execution, all instructions in flight must be cancelled as soon as they're known not-taken, rename registers must be returned for use as soon as instructions are known to be cancelled, and so on. It might be possible to design a superscalar chip that is not vulnerable to Spectre-like attacks, but I'm sceptical (and I'm doubly sceptical that, if you could, it would perform better than an in-order processor).

Re:Alles Klar Kommissar

[rahvin112]

The best way to describe spectre is that's it's fundamental to how all out of order instruction processors work. All out of order processors will suffer from spectre.

Getting rid of spectre would require the return to in order execution at a MASSIVE performance penalty, more than 50% and probably closer to 75% drop in compute power. It's mitigateable but it's going to have hundreds of edge cases that will be found for years so it's going to take a long time (years) and a lot of rewriting in the fundamental parts of OS's to negate Spectre based attacks.

Spectre is fundamental to the design assumptions of all modern processors, as I like to say it's the bug that's going to give and give and give. They probably won't have found most of the edge cases until after 2020 so we should expect yearly/quarterly patches to spectre like attacks for a long time.

One thing that's not mentioned in a lot of the articles but the timing based attacks that comprise the spectre attacks were discovered years ago. It took several years for someone to find and demonstrate the first version of these attacks but most experts think this is just the beginning and that we're looking toward years of these type of attacks on all aspects of operating systems and CPU's.

In other words, spectre was just the first timing attack, there will be more, probably a lot more now that there is an actual example of how to do them.

Re: Thanks but no thanks, Intel

[art123]

This isn't a Microsoft specific issue. If a process is running on Windows or Linux and that process was using processor platform specific instructions (which it may have dynamically queried support for upon process startup) how is that process supposed to keep running on the other platform where the instruction doesn't exist?

Re:Nobody wants a defective product in mass qty

[sexconker]

"Addresses in hardware" will mean "performance-fucking changes to built-in microcode" for at least another full generation.

Actual hardware fixes will also result in performance drawbacks. The whole issue is that they're executing and caching results before a simple security check. They've either got to stop that speculative execution, add a delay / wipe that prevents speculative results from being cached, or never let it hit the cache in the first place. All options incur a significant performance penalty for many operations.

Re:Fabbing 10nm hasn't been easy

[Megol]

Citation needed. People have been talking about Apple switching to ARM for at least 5 years.

Re: Thanks but no thanks, Intel

[ckaminski]

Which other hypervisors offer live migration across VM hosts?

Xen is the only other one I know about:
https://support.citrix.com/article/CTX115813

Q: Does XenMotion support live relocation of virtual machines between Intel-based and AMD-based host systems?
A: No, XenMotion supports live relocation of virtual machines between systems with the same type and manufacturer of processor.

Re: Thanks but no thanks, Intel

[sexconker]

KVM does it.

Re: Thanks but no thanks, Intel

[DigiShaman]

ESXi is it's own OS that runs the bare metal that's known as the host. The entire purpose of that OS is to be the hypervisor for all VMs that will run on it. Technically, ESXi is known as a Type-1 hypervisor. VMWare Workstation as an application that runs on Windows, that would be a Type-2.

Trivia time: Did you know that Microsoft Hyper-V is technically a Type-1. It's true. Hyper-V isn't a seperate application that runs on Windows; it gets away with being a Type-1 because it's part of Windows.

In regards to the AC post - He/she is correct. You can't VMotion a running VM in HA mode from AMD to Intel and vice versa. In fact, even in a pure Intel host cluster, the entire cluster is rated at the lowest common denominator in CPU generations. So if one of your host boxes has an older CPU, all hosts within that cluster must be configured to only use instructions sets of that generation. Conversely if you wanted to upgrade the CPU instruction set capability, you just replace that one host.