• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

The Intel Atom Thread

Page 200 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Mercury Lake is no more. Next is Gemini Lake+ and Jasper Lake.

The CLWB instruction is one necessary for fast non-volatile storage. Maybe Tremont cores will have something nice for us in terms of Optane based storage? CLDEMOTE seems to be important for network processors, so future Atom C series.
 
IntelUser2000 said:
Mercury Lake is no more. Next is Gemini Lake+ and Jasper Lake.
Click to expand...
Apollo Lake(14nm) -> Gemini Lake(14nm) -> Gemini Lake+(14nm++)/Mercury Lake(10nm) -> Jasper Lake (10nm+) -> Meteor Lake (7nm)

MCL will launch within GML+, like CNL launched within CFL/WHL, etc.

All the information I gathered.
Tremont MCL
Tremont Plus JPL
 
Brunnis said:
Thanks for the link! Pretty disappointing benchmark selection (although single threaded performance looks nice, as we already knew). Also disappointing that memory support might be spotty, just like on Apollo Lake. The 2400 MHz HyperX memory is exactly what I have lined up for my NUC7PJYH when it arrives. Looks like I may have to return that...

I don’t know what’s up with the memory controller on Apollo Lake and Gemini Lake, but between the spotty memory support, low bandwidth efficiency and slow memory access, something about the design seems to be quite different compared to the Core based chips.
Click to expand...

It was using single channel memory.

https://browser.geekbench.com/v4/cpu/compare/7802702?baseline=7663733

So we finally catches up Sandy Bridge. And even better in the quad core version.

When is Tremont coming?
 
ksec said:
It was using single channel memory
Click to expand...
Not sure I understand... the NUC7CJYH in that review runs dual channel DDR4-2133.

Triloby said:
Wow. My parents just recently received a NUC6CAYH as a gift to replace their aging FM2 desktop. Kinda surprised to see that their Gemini Lake Celeron is literally no better than the Apollo Lake Celeron they just got.
Click to expand...
Well, the old one was quad core, while the new is a dual, so hardly all that surprising. The NUC7PJYH is the quad core this time around and it should beat the NUC6CAYH pretty easily.
 
Triloby said:
Wow. My parents just recently received a NUC6CAYH as a gift to replace their aging FM2 desktop. Kinda surprised to see that their Gemini Lake Celeron is literally no better than the Apollo Lake Celeron they just got.
Click to expand...

Single thread performance is way better, but the dual core can't keep up with a quad core in multithread performance. No surprise.
 
ksec said:
It was using single channel memory.

https://browser.geekbench.com/v4/cpu/compare/7802702?baseline=7663733
Click to expand...

The scores are similar to Sandy Bridge on that link, but not the memory result.

The memory performance is simply much better on Core chips than Intel's small core ones. Even with the identical memory sticks, timings and both being dual channel.

Oh, and by the way, you guys are missing on the fact the review tested Geekbench 3, not Geekbench 4.

Single thread performance is way better, but the dual core can't keep up with a quad core in multithread performance. No surprise.
Click to expand...

I'd like to see more tests than just Cinebench. I think Cinebench gains are on the high side. But yea, Gemini Lake should be much more responsive than Apollo Lake.
 
Bouowmx said:
Actually quite far behind Sandy Bridge, at iso-frequency and without use of Hyper-threading.
https://browser.geekbench.com/v4/cpu/compare/7663733?baseline=3045740
Celeron J4005 vs Pentium G630 (both max 2.7 GHz)
Single: 2042 (0.750) vs 2723
Multi: 3554 (0.775) vs 4585
Click to expand...

I wasn't measuring IPC. And I am not sure if J4005 were running at 2.7Ghz all the time. There is a different between 2.7Ghz Stock 65W CPU and 2.7Ghz Turbo only 10W CPU.

It is not a fair comparison, but a relevant one.

I wish they just sell me a 14nm++ SandyBridge for cheap though. Sigh.
 
NTMBK said:
Single thread performance is way better, but the dual core can't keep up with a quad core in multithread performance. No surprise.
Click to expand...

That's true. I guess I expected the speed bump in the dual cores to try and close the gap between the old quad core in multithreaded performance.

Not that it really matters, anyway. Our Apollo Lake NUC isn't going to be taxed in daily usage (if al all), so performance differences are a moot point in this regard.
 
Comparing the Apollo lake Celeron with the Core processor, in which generation is that chip?

Core 65 nm?
Core 45 nm (Wolfdale)?
Nehalem?
 
Newegg has J5005 NUC selling for $175. Asrock has the J5005-ITX model for $120. The J5005 NUC uses the lower end CRF module Wireless-AC 9462, and the Asrock boards have CNVi support.

CRF + CNVi = full solution
3 CRF modules available: Wireless-AC 9461/9462/9560

Searching for J4005 and J4105 also shows Asrock boards. It seems quite sneaky of them. 😀
 
It seems the Atom issue with degrading circuitry of I/O blocks is back:
https://www.servethehome.com/another-atom-bomb-intel-e3800-bay-trail-atom-vli89-bug/
https://forums.servethehome.com/ind...l-dying-because-of-lpc-bus-design-flaw.19402/

LPC, USB and SDIO interfaces might stop working over time in Bay Trail Chips, there will be new stepping for embedded version, while the consumer chips are probably left as they are (hopefully the rate of degradation is not fast enough to hit tablets and notebooks... I own one damn!)

Edit: Apollo Lake is affected too, https://www.intel.com/content/dam/w...n-n-series-j-series-datasheet-spec-update.pdf
erratum APL46: System May Experience Inability to Boot or May Cease Operation
 
Last edited:
Jan Olšan said:
It seems the Atom issue with degrading circuitry of I/O blocks is back:
https://www.servethehome.com/another-atom-bomb-intel-e3800-bay-trail-atom-vli89-bug/
https://forums.servethehome.com/ind...l-dying-because-of-lpc-bus-design-flaw.19402/

LPC, USB and SDIO interfaces might stop working over time in Bay Trail Chips, there will be new stepping for embedded version, while the consumer chips are probably left as they are (hopefully the rate of degradation is not fast enough to hit tablets and notebooks... I own one damn!)

Edit: Apollo Lake is affected too, https://www.intel.com/content/dam/w...n-n-series-j-series-datasheet-spec-update.pdf
erratum APL46: System May Experience Inability to Boot or May Cease Operation
Click to expand...
Just... freaking great. 🙁

Is Intel THAT RETARDEDdifferently-enabled when it comes to silicon validation? That was the whole reason that the initial batch of Z68 chipsets were recalled (weak transistor).

Edit: Sorry, didn't know that we had to cater to "safe spaces" on the tech forums.
Edit2: Corporations aren't people.
 
Last edited:
VirtualLarry said:
Just... freaking great. 🙁

Is Intel THAT RETARDED when it comes to silicon validation? That was the whole reason that the initial batch of Z68 chipsets were recalled (weak transistor).
Click to expand...

There was a reddit post where supposedly an Intel manager told the validation team to speed up validation. Since some problems are only fixed with time, the solution was to cut what they thought was unnecessary. The manager also told them their competitors were going from design to product much faster than them. Some other posts I have read said they adopted a more paranoid form of validation after the Pentium FDIV bug.

The important question for me, assuming the allegations were true was this: If its not due to the ISA and its supposed complexity, why do Intel chips take so long to go from design to product? Assuming that, I thought of one possibility, and maybe its their culture...?
 
VirtualLarry said:
Just... freaking great. 🙁

Is Intel THAT RETARDED when it comes to silicon validation? That was the whole reason that the initial batch of Z68 chipsets were recalled (weak transistor).
Click to expand...

It's obvious that they're trying to move more quickly, but there are trade offs to moving fast -- you get worse results. Most of the time this doesn't come back to bite you in such an obviously bad way, but sometimes you get issues like with Avoton and now this.

Intel does need to really step back and rethink its strategy.
 
Last edited:
What Intel did is a very BIG screwup... I was about to buy an Apollo lake based tablet in order to do some homework...

And that problem affects smartphones SoCs??
 
this is a lot worse than the h67/p67 b2 sata II issues, they identified that problem and fixed very quickly, also it only made the sata II ports fail while the rest still worked, and it didn't have a soldered CPU
 
Are there any indications as to how much usage is needed to cause failures? This is obviously bad, but if it requires years of constant, heavy usage to produce a failure, it will be of little consequence for most users.

Not happy with this, though, as I have an Apollo Lake system myself.
 
dark zero said:
And that problem affects smartphones SoCs??
Click to expand...

The problem seems to have existed since Cherry Trail. Though for Cherry Trail it says S0iX supporting chips are not affected. S0iX chips are everything Smartphones and Tablets because its a very important state for long battery life.

The people researching into the problems in that thread speculates fixing the issue is why the C3000 chips were delayed. It's plausible the delay could be attributed to Goldmont Plus chips. For the embedded targeted E3800(Apollo Lake), the D0 revision fixes it.

If lot of Intel delays are due to fixing bugs, perhaps they should take the extra time and fix the bugs instead. What's the point of saving 3 months in validation if it takes 6 months to get a revised part out?
 
Somehow missed reading the ServeTheHome forum thread earlier. This probably won't be an issue at all for most regular systems (i.e. laptops and desktops). Systems that are powered/used 24/7 might be at risk, though.
 
Well, that took friggin long enough to arrive... 😛 Finally got my NUC7PJYH (Pentium J5005) today, more than two months after I ordered it.

EDIT: I'll be posting lots of benchmarks soon, but here's the first one (Geekbench 4):

https://browser.geekbench.com/v4/cpu/8060129

Single: 2135
Multi: 6324

Looking quite good! This is with 2x4GB DDR4-2133 CL15. The HyperX 2400 MHz CL14 did not boot, as expected.

dBUGzsX.jpg
 
Last edited:
You must log in or register to reply here.

TRENDING THREADS

Back
Top