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.

[Narcocide]

(Pro tip: try it with Linux!)

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.

[sexconker]

Really? Wow. That's interesting! Please detail 3 of these bizarre compatibility issues.

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.

[ckaminski]

Can you elaborate?

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.

[Anne Thwacks]

I am in Europe - we have had a Wine lake and a Milk lake for ages. No sign of Spectre, but I believe the Man from Uncle is still around somewhere (ITV2?)

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.

[Tough Love]

if you are going to do a bitch'n build and not break the bank the 2700X seems to be the way to go.

If quiet is your thing, the 2700 is also a great choice. 65 watt envelope and even better value.

Re:Intel in full damage control mode.

[edwdig]

The 8th gen Kaby Lake Refresh processors support 32 GB. Business oriented ultrabooks with 8th gen processors often have 32 GB as an option. Laptops like Thinkpads, Dell Inspiron, HP EliteBook, etc. It's just an option on customized orders. No one's mass producing laptops with that much built in, as the demand isn't there.

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?

[thegarbz]

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

They have been sorting this platform out long before the gaping holes were first discovered.

Re:Is "sort things out" an euphemism?

[UnknownSoldier]

Marketing speak for "damage control".

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:Is "sort things out" an euphemism?

[Tough Love]

That, and trying to work EUV into the mix, really nasty stuff. Without EUV, multipatterning is a serious bottleneck.

Re:Is "sort things out" an euphemism?

[Tough Love]

Ah, and Intel seems to be way behind AMD in multi-die tech. Strategic blunder.

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.

Re:Fabbing 10nm hasn't been easy

[DontBeAMoran]

Or maybe they're telling us that Apple has paid in advance for all the Cannon lake CPUs Intel is able to produce right now?

Updated Mac mini and/or MacBook Air "soon"?

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:Alles Klar Kommissar

[TeknoHog]

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.

Probably some dumb questions, but anyway:

(1) Does out-of-order necessarily imply speculative execution?

(2) Is in-order really that bad, considering all the other advances in processor design?

(3) What about efficiency? If in-order means the CPU is doing less work in a given time, is it also consuming less power? I.e. is the 50%..75% reduction in absolute computing power, or also efficiency?

(2) is related to some anecdotal experience that hyperthreading works well on in-order Atom processors. In my understanding, HT helps keep the pipeline full, so if it's half empty due to in-order design, the relative improvement would be better compared to OOO processors. (3) is also about pipeline utilization.

Did I mention I like the lack of these vulnerabilities on my Atom server? ;)

$ uname -p
Intel(R) Atom(TM) CPU D510 @ 1.66GHz
$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Not affected

Re:Alles Klar Kommissar

[Anonymous Coward]

Fair questions.

(1) No. For instance, if you multiply two registers, and then load a constant, two things that have only one outcome, you can run them both in parallel and finish the second one first.

However, OO really come into its own when coupled with speculative execution, because a lot of instructions can trigger faults. Anything to do with memory, for a start. That's when it becomes really useful to be able to speculatively execute past the possibly troublesome instruction, expecting there won't be a problem (which is usually the case), and rolling back otherwise.

(2) Yes, but it depends on the workload. If in-order means you can cram more cores, and that suits the workload (GPUs, ahem), then it's actually better. In general, it's bad, though.

(3) Absolutely. That's why low-power ARM designs use in-order, but high-performance ones use out-of-order.

Re:Alles Klar Kommissar

[TheRaven64]

(1) Does out-of-order necessarily imply speculative execution?

No, though typically you move to speculative execution before you move to superscalar. Speculative execution is required to get decent performance from any pipelined processor. The difference between the speculative execution in a superscalar and an in-order pipeline is one of degree, rather than kind. There's a fairly common heuristic that you have a branch roughly ever 7 instructions in code compiled from vaguely C-like languages (code that is often quite misleadingly called 'general-purpose' code). If you have a 7-stage pipeline (fairly small by modern standards), then by the time you've got the first last instruction in a basic block out of the pipeline, you'll have reached the end. You now have two choices: wait until you have the branch target value (i.e. you've finished executing the instruction that computes it) or guess. If you guess and get it right even some of the time, you'll have better performance because you'll be executing useful instructions at least some of the time, whereas if you don't guess you're guaranteed to be executing nothing. This is the essence of branch prediction.

(2) Is in-order really that bad, considering all the other advances in processor design?

That depends a lot on the workload. GPUs, for example, are in-order and don't do speculative execution. They are really fast. They are; however, very slow at running typical C code.

Out of order designs result from the desire to exploit instruction-level parallelism. The basic idea is that it's easy to do things in parallel in hardware: just stamp out more logical blocks. Given sequential code, if you can convert it into sequences of data dependencies, you can then execute anything in parallel once its dependencies are satisfied. Most straight-line code has on the order of 4-way instruction-level parallelism, so if you can fully exploit this then you can run at around four times the speed.

The obvious alternative is to just have four single-pipeline[1] cores. This will give you better power efficiency, but at the cost of requiring some combination of the programmer and the compiler to generate code that exposes parallelism. You can take this even further and have multiple thread contexts per core, so whenever you would have to speculatively execute an instruction, you instead pause the thread and start running instructions from another thread. This approach means that all of the instructions that you're executing are ones where the result is actually used and simplifies some of the very complex parts of a processor (branch predictor, register rename engine) and so gives much better performance per Watt and per unit area than an out-of-order processor. If you have a source language that makes it easy to expose this kind of parallelism, then this will give you much better performance. Unfortunately, most Algol-derived languages (C, C++, Java, and so on) are not in this category.

(3) What about efficiency? If in-order means the CPU is doing less work in a given time, is it also consuming less power? I.e. is the 50%..75% reduction in absolute computing power, or also efficiency?

Good question. If you look in a typical Android smartphone, you will see ARM cores in a big.LITTLE configuration: a cluster of simpler in-order cores and a cluster of higher-performance out-of-order cores. The in-order cores will consume less power than the big cores executing the same sequence of instructions[2]. The peak performance for the big cores will be much higher, but at the cost of efficiency.

(2) is related to some anecdotal experience that hyperthreading works well on in-order Atom processors. In my understanding, HT helps keep the pipeline full, so if it's half empty due to in-order design, the relative improvement would be better compared to OOO processors. (3) is also about pipeline utilization

Pu

Re:Fabbing 10nm hasn't been easy

[DontBeAMoran]

I doubt there will ever be another Mac mini. It's too much like a real, upgradeable computer.

They took care of that with the 2014 "update".

Re:Moore’s law is dying

[Holi]

what do general purpose CPUs have to do with cryptomining?
I don't know of any coin with any traction that uses CPUs, Bitcoin Lite Coin Dash etc are all ASIC mined and the Ethereum clones use GPU's. None of these will effect the sale of CPUs.

Re: Thanks but no thanks, Intel

[Narcocide]

Isn't it interesting how the solutions relying on the Microsoft ecology all seem to deadlock you to Intel hardware too, when none of the other virtualization technology seems to have that problem. I wonder if you've learned your lesson yet.

Re: Thanks but no thanks, Intel

[Anonymous Coward]

ESXi is VMWare not MICROSOFT.

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?

Meanwhile...

[Anonymous Coward]

14nm has become 70% more compact since the first 14nm products, which translates into whatever mix of power saving or performance increase you use it for.

Things have not stood still. 10nm will be another incremental step relative to 14nm.

The Xnm description of processes has become a tool of obfuscation. Gates per square micron might be better.

Re: Thanks but no thanks, Intel

[sexconker]

You can if you fuck around with unsupported shit. I wouldn't trust it to work, however.
Of course, other hypervisors have no issue with this.

You're only stuck with Intel if you cannot afford brief downtime of a single VM. If you cannot afford that, you're in a precarious place regardless.

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:Fabbing 10nm hasn't been easy

[omnichad]

I have no citation yet (Apple would try not to leak until the press event), but the momentum keeps building. The newest iMac Pro has an A10 Fusion chip for some functions (Macbook Pro runs the touchbar on ARM). Before, I think they were mostly driving that speculation themselves (and saving it as a backup plan) to keep Intel pricing under control. Now that AMD is more competitive, Intel will be looking to its major buyers to keep their profits up. Apple introduced bitcode to the OS X app store in 2015, meaning that for software that has this enabled, they can recompile (and even test) software for the new chip before the announcement without telling developers. On launch day, the app could be in the store on a new architecture without developers even updating it themselves.

Re:Fabbing 10nm hasn't been easy

[ckaminski]

Exactly.

A switch away from intel will kill the performance users.

You'll lose them all to the surface books.

Re: Thanks but no thanks, Intel

[ckaminski]

VMotion doesn't require Windows. You can VMotion any supported OS.

https://partnerweb.vmware.com/programs/guestOS/guest-os-customization-matrix.pdf

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.

Do I hear 2020

[oh_my_080980980]

LMOL you were suppose to release this back in 2016. Maybe you should call IBM, they can show you how to do it :)

Re: Thanks but no thanks, Intel

[sexconker]

KVM does it.

Re: Thanks but no thanks, Intel

[b0bby]

That's cool, I use KVM quite a lot but I didn't know they supported that!

Re:Fabbing 10nm hasn't been easy

[angel'o'sphere]

Perhaps you want to enlighten us: in which cases is an Intel CPU faster than an ARM?

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.

Re: Fabbing 10nm hasn't been easy

[Anonymous Coward]

A 7 year old article, nice.

Re: Thanks but no thanks, Intel

[DigiShaman]

Hyper-V does as well

Re:Fabbing 10nm hasn't been easy

[F.Ultra]

Especially those with Meltdown patches ;)

Re:Nobody wants a defective product in mass qty

[F.Ultra]

But with a proper fix in the CPU the performance penalty will be significantly lower than the current software work-around. And Intel have said that they will introduce chips with proper fixes in late 2018 so apparently they are working on it.

Re:Fabbing 10nm hasn't been easy

[omnichad]

Apple hasn't released a true performance computer for a while - even their newest Mac Pro fails to keep up with the times.

The single core Geekbench scores of the Xeon e5 in the current Mac Pro match up not too far off from that of the A10X (with only a TDP of 8W). If Apple did a 10-12 core desktop chip with their A11X, they really could have the performance there.

Re: Fabbing 10nm hasn't been easy

[DontBeAMoran]

The A11 in battery-powered devices where they need to keep the power requirements low and the heat dissipation to a minimum bests some of the lower end Intel Core i3 desktop chips connected to the power lines with massive heatsinks and fans.

We have no idea what kind of A11-style CPUs Apple has in its labs. For all we know, they have "A20" CPUs that can rival quad-core Intel i7.

Re:Moore’s law is dying

[TeknoHog]

I don't know of any coin with any traction that uses CPUs, Bitcoin Lite Coin Dash etc are all ASIC mined and the Ethereum clones use GPU's.

Monero is #12 at Coinmarketcap, and it remains mine-worthy on CPUs. GPUs might be marginally more efficient, but they are within the same order of magnitude.

I'm not exactly vouching for Monero, as it's heavy and slow to use, even compared to its Cryptonote siblings, but it seems to have a lot of backing from the big boys. Also recently, ASICs suitable for Monero were released, and the Monero team reacted in a whack-a-mole fashion by changing some parameters in the proof-of-work algo. So not very professional, but as we know, the smartest tech doesn't always win the market.

Re:Nobody wants a defective product in mass qty

[billyswong]

I guess proper hardware fixes will constitutes new instructions (or new ring), so that a user-mode program can tell the CPU which part of codes are from untrusted internet and to be further sandboxed against side-channel attack, while code not crossing the boundary can be kept high-performance.

Re:Fabbing 10nm hasn't been easy

[Megol]

In other words you got nothing.

Re:Fabbing 10nm hasn't been easy

[Megol]

This line of thinking is oversimplified: one can't just add a lot of stuff and expect everything to scale.

The interconnect between cores in a low power design with a few cores is different in a "manycore"* design designed for intermediary to reasonably high power (say 40-90W). To reduce the communication latency one will burn more power however Apple may try to keep a simple design and use NUMA type techniques to reduce longer latency communications in software.

Memory controllers would consume more, the GPU would probably be scaled significantly and thus consume more power. Just having a larger die means more power consumed (leakage and other effects).

Not saying an Apple processor couldn't provide a very good bang for the (power) buck compared to Intel processors but it isn't easy to compare a low power design with a higher power design.

(* relatively)

Re:Fabbing 10nm hasn't been easy

[omnichad]

It was really for an idea is performance scale, not literally using the same cores. They absolutely have been working on prototypes even if just as insurance against Intel pricing. The threat of being able to change architectures at the drop of a hat has served then well so far. But an educated guess still makes it likely that they will switch to ARM soon. There have been a lot of outwardly visible pointers.

Re: Thanks but no thanks, Intel

[buchanmilne]

"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."

Well, yes, you would need to create a separate cluster (managed by the same vCenter server), and shut VMs down to migrate between clusters. Oh the horror.

  "So, I'm kinda stuck with staying with Intel."

If you can't afford one reboot VMs one at a time, you have bigger problems.

Re:Nobody wants a defective product in mass qty

[F.Ultra]

It was in March that they said that it would come in the second half of 2018 in the Cascade Lake architecture.

Re: Thanks but no thanks, Intel

[Megol]

Either you are an idiot, a troll or someone incapable of reading simple text. What I wrote that was:

VMware ESXi isn't part of the Microsoft ecology.

It isn't based on Microsoft software.

Which means it have nothing to do with Microsoft _WHICH_WAS_THE_FREAKING_POINT_. It was a _CORRECTION_ of the post I responded to.

Suppose I shouldn't complain. Someone moderated me troll for the same post. Correcting an idiot poster by stating facts is now a troll...