AMD's Future Chips & SoC's: News, Info & Rumours.

[jaymc]

"The vulnerabilities are not expected to have performance impact and the company expects to release patches in the "coming weeks."

https://www.marketwatch.com/story/amd-says-no-performance-impact-for-newly-disclosed-security-flaws-2018-03-20

 

[juanrga]

All talks about "latency reduction" that I have read are measurements, not cycles. Where did you read that information? Did you even reply in the right forum? haha.

In any case, I didn't sport the "cycle" part in the documents; my mistake.

As mentioned in the twitter thread, The Stilt and other people claim that the latency was reduced from 17 cycles in Summit Ridge, EPYC, and Threadripper to 12 cycles in Raven Ridge and Pinnacle Ridge thanks to cache improvements.

Then the people in that thread proves the latency was already 12 cycles on Summit Ridge, EPYC, and Threadripper, and that rumored cache improvement isn't real.

 

[-Fran-]

All talks about "latency reduction" that I have read are measurements, not cycles. Where did you read that information? Did you even reply in the right forum? haha.

In any case, I didn't sport the "cycle" part in the documents; my mistake.

As mentioned in the twitter thread that I linked to. The Stilt and other people claim that the latency was reduced to 17 cycles in Summit Ridge, EPYC, and Threadripper to 12 cycles in Raven Ridge and Pinnacle Ridge thanks to cache improvements.

Then the people in that thread proves the latency was already 12 cycles on Summit Ridge, EPYC, and Threadripper, and that rumored cache improvement isn't real.

Didn't AMD say something along the lines of "we put some of the good stuff in TR/EPYC into Zen v1.5 since we couldn't do it in Zen v1"?

I do remember something along those lines, so I think the documentation might be base-lining it to EPYC or something along that way?

I mean... If you're going to write an optimization guide, might as well do it for the most profitable market, right? A few cache misses for not optimizing for desktop Zen is not that much in a single generation. Hell, even more, if you think about it a bit more, makes some business sense to do it like that when you have planned out the same implementation/tweaks to trickle down to desktop afterwards, which is what they said about Zen v1.5 all along.

Anyway, that is just my hunch. I have no way to prove it either way. Except maybe the first part... If I ever remember where I read stuff, lol.

 

[juanrga]

AMD official answer confirming the AMDflaws

https://community.amd.com/community/amd-corporate/blog/2018/03/20/initial-amd-technical-assessment-of-cts-labs-research

I knew that all what I wrote in my reply to Linus was correct, including my claim that AMD was working in fixes:

(i) the flaws are real (i.e. the hardware/software is not working as expected), (ii) PoCs there exists and security experts outside CTS-labs confirmed the code works on AMD hardware as described in the full white paper, and (iii) research packages with full details and PoCs are in the hands of relevant hardware/software companies, including those I mentioned in a former post.

:-D

The only difference between CTS-labs and AMD is that CTS-labs claimed the fixes would require months, but AMD claims can fix this within weeks.

 

[juanrga]

Didn't AMD say something along the lines of "we put some of the good stuff in TR/EPYC into Zen v1.5 since we couldn't do it in Zen v1"?

I do remember something along those lines, so I think the documentation might be base-lining it to EPYC or something along that way?

Summit Ridge, ThreadRipper, and EPYC, use the same dies with the same microarchitecture. So the caches are identical on all them. Moreover, the software optimization guide for Zen products confirms the latency is 12 cycles.

 

[-Fran-]

Didn't AMD say something along the lines of "we put some of the good stuff in TR/EPYC into Zen v1.5 since we couldn't do it in Zen v1"?

I do remember something along those lines, so I think the documentation might be base-lining it to EPYC or something along that way?

Summit Ridge, ThreadRipper, and EPYC, use the same dies with the same microarchitecture. So the caches are identical on all them. Moreover, the software optimization guide for Zen products confirms the latency is 12 cycles.

Strictly speaking, it can't be though?

The interconnects have to be different, so there has to be different implementations for Inf Fabric. I mean, they had to implement external connectivity for TR/EPYC, so the wiring must be different. I'm not saying the core itself (CPU blocks, if you like) are different, but the supporting external design can be. I mean, they *did* change just Cache stuff for Zen v1.5 without altering the Zen core, right?

I'll try to find where it was mentioned... Maybe it was in one of the interviews with Mrs Lisa Su.

 

[juanrga]

Didn't AMD say something along the lines of "we put some of the good stuff in TR/EPYC into Zen v1.5 since we couldn't do it in Zen v1"?

I do remember something along those lines, so I think the documentation might be base-lining it to EPYC or something along that way?

Summit Ridge, ThreadRipper, and EPYC, use the same dies with the same microarchitecture. So the caches are identical on all them. Moreover, the software optimization guide for Zen products confirms the latency is 12 cycles.

Strictly speaking, it can't be though?

The interconnects have to be different, so there has to be different implementations for Inf Fabric. I mean, they had to implement external connectivity for TR/EPYC, so the wiring must be different. I'm not saying the core itself (CPU blocks, if you like) are different, but the supporting external design can be. I mean, they *did* change just Cache stuff for Zen v1.5 without altering the Zen core, right?

I'll try to find where it was mentioned... Maybe it was in one of the interviews with Mrs Lisa Su.

The L2 cache is part of the core (unlike the L3), so one cannot change the L2 cache without changing the core. Also the interconnect doesn't affect the L2 cycle latency, because the interconnect is external to the core.

Precisely the people in the thread I mentioned is claiming there is not any change to the L2 cache and that latency was always 12 cycles since the first Zen product. And the documents they give (including internal docs from AMD) confirm it.

 

[-Fran-]

The L2 cache is part of the core (unlike the L3), so one cannot change the L2 cache without changing the core. Also the interconnect doesn't affect the L2 latency, because the interconnect is external to the core.

Precisely the people in the thread I mentioned is claiming there is not any change to the L2 cache and that latency was always 12 cycles since the first Zen product. And the documents the give (including internal docs from AMD) confirm it.

Since the caches are tied to the IF frequency, it doesn't make sense? If what you're saying is true, then why both L2 and L3 report lower latency for each with no real Zen-core changes? There is something you're missing.

 

[juanrga]

The L2 cache is part of the core (unlike the L3), so one cannot change the L2 cache without changing the core. Also the interconnect doesn't affect the L2 latency, because the interconnect is external to the core.

Precisely the people in the thread I mentioned is claiming there is not any change to the L2 cache and that latency was always 12 cycles since the first Zen product. And the documents the give (including internal docs from AMD) confirm it.

Since the caches are tied to the IF frequency, it doesn't make sense? If what you're saying is true, then why both L2 and L3 report lower latency for each with no real Zen-core changes? There is something you're missing.

I already explained this in a former post. The number of cycles don't change with frequency. What changes with frequency is the number of nanoseconds that one cycle last. 12 cycles at 2993MHz is a shorter period of time (in ns) than 12 cycles at 2666MHz.

12 / 2933 MHz = 4.09 ns

12 / 2666 MHz = 4.5 ns

So those measured latency improvements in ns are the result of RR and PR using a faster IMC/interconnect. There is no changes to the microarchitecture but simply higher clocks.

The L2 cache latency has not been reduced from 17 cycles to 12 cycles in RR/PR. It was always 12 cycles since the first minute.

 

[Gon Freecss]

4.2GHz I think is going to be the new 4GHz.

Funny thing that a mature 14nm or "12nm" process will overclock on par or worse than Broadwell.

Care to share the overclocking numbers with us? I haven't seen any around

Cheers!

Uh, same here, but I figured 4.2GHz will be the new 4GHz because the 2600X has a 4.25GHz maximum turbo speed, and 4GHz was the wall on SR chips. The 1600X had a 4GHz boost with a 4.1GHz XFR.

I think 4.3GHz will be the max on not so insane voltages. Maybe 4.4GHz on the best binned TR chips? We'll see.

 

[-Fran-]

The L2 cache is part of the core (unlike the L3), so one cannot change the L2 cache without changing the core. Also the interconnect doesn't affect the L2 latency, because the interconnect is external to the core.

Precisely the people in the thread I mentioned is claiming there is not any change to the L2 cache and that latency was always 12 cycles since the first Zen product. And the documents the give (including internal docs from AMD) confirm it.

Since the caches are tied to the IF frequency, it doesn't make sense? If what you're saying is true, then why both L2 and L3 report lower latency for each with no real Zen-core changes? There is something you're missing.

I already explained this in a former post. The number of cycles don't change with frequency. What changes with frequency is the number of nanoseconds that one cycle last. 12 cycles at 2993MHz is a shorter period of time (in ns) than 12 cycles at 2666MHz.

12 / 2933 MHz = 4.09 ns

12 / 2666 MHz = 4.5 ns

So those measured latency improvements in ns are the result of RR and PR using a faster IMC/interconnect. There is no changes to the microarchitecture but simply higher clocks.

The L2 cache latency has not been reduced from 17 cycles to 12 cycles in RR/PR. It was always 12 cycles since the first minute.

Then your theoretical numbers are off. The new latency is in the 3.1ns territory:

https://techreport.com/news/33336/rumor-benchmarks-of-upcoming-ryzen-7-cpu-surface

Unless those numbers are not correct, obviously.

@Gon Freecss: Keep in mind they haven't said anything about the 2800X, so they might indeed be binning CPUs.

Cheers!

 

[juanrga]

4.2GHz I think is going to be the new 4GHz.

Funny thing that a mature 14nm or "12nm" process will overclock on par or worse than Broadwell.

Care to share the overclocking numbers with us? I haven't seen any around

Cheers!

Uh, same here, but I figured 4.2GHz will be the new 4GHz because the 2600X has a 4.25GHz maximum turbo speed, and 4GHz was the wall on SR chips. The 1600X had a 4GHz boost with a 4.1GHz XFR.

I think 4.3GHz will be the max on not so insane voltages. Maybe 4.4GHz on the best binned TR chips? We'll see.

4.3--4.4GHz is just what I have been expecting for a while 😉

 

[juanrga]

The L2 cache is part of the core (unlike the L3), so one cannot change the L2 cache without changing the core. Also the interconnect doesn't affect the L2 latency, because the interconnect is external to the core.

Precisely the people in the thread I mentioned is claiming there is not any change to the L2 cache and that latency was always 12 cycles since the first Zen product. And the documents the give (including internal docs from AMD) confirm it.

Since the caches are tied to the IF frequency, it doesn't make sense? If what you're saying is true, then why both L2 and L3 report lower latency for each with no real Zen-core changes? There is something you're missing.

I already explained this in a former post. The number of cycles don't change with frequency. What changes with frequency is the number of nanoseconds that one cycle last. 12 cycles at 2993MHz is a shorter period of time (in ns) than 12 cycles at 2666MHz.

12 / 2933 MHz = 4.09 ns

12 / 2666 MHz = 4.5 ns

So those measured latency improvements in ns are the result of RR and PR using a faster IMC/interconnect. There is no changes to the microarchitecture but simply higher clocks.

The L2 cache latency has not been reduced from 17 cycles to 12 cycles in RR/PR. It was always 12 cycles since the first minute.

Then your theoretical numbers are off. The new latency is in the 3.1ns territory:

https://techreport.com/news/33336/rumor-benchmarks-of-upcoming-ryzen-7-cpu-surface

Unless those numbers are not correct, obviously.

@Gon Freecss: Keep in mind they haven't said anything about the 2800X, so they might indeed be binning CPUs.

Cheers!

The above latency numbers in ns were computed using IMC frequency. I gave those numbers only as illustration that 12 cycles can be faster than 12 cycles when the frequency changes. Those numbers aren't the latency of the L2 cache in ns, because I don't know the working frequency of the L2.

Of course AMD is binning. Already did it with first gen Zen products. Several leakers claim the 2800X, 2500X, 2400, and other models don't exist and the 2700X is the top Pinnacle Ridge model. And slides from AMD show the 2700X as replacement of the 1800X.

 

[Gon Freecss]

4.2GHz I think is going to be the new 4GHz.

Funny thing that a mature 14nm or "12nm" process will overclock on par or worse than Broadwell.

Care to share the overclocking numbers with us? I haven't seen any around

Cheers!

Uh, same here, but I figured 4.2GHz will be the new 4GHz because the 2600X has a 4.25GHz maximum turbo speed, and 4GHz was the wall on SR chips. The 1600X had a 4GHz boost with a 4.1GHz XFR.

I think 4.3GHz will be the max on not so insane voltages. Maybe 4.4GHz on the best binned TR chips? We'll see.

4.3--4.4GHz is just what I have been expecting for a while 😉

Don't think you'll see 4.4GHz except on the best bins.

@Yuka; I doubt the 2800X exists since the 2700X is already 105W.

 

[juanrga]

Don't think you'll see 4.4GHz except on the best bins.

Probably you are right.

 

[-Fran-]

I think there will be a 2800X, but down the road. If not, they'll probably skip to the "3800X" for Zen v2.

In any case, I don't think the 2700X is a bad product just because it didn't get the "higher end" model numbering from AMD. It actually makes sense to have it at the top, since the 1700 siblings just were the better purchases and they're probably "fresher" in everyone's mind.

As for the speeds. They won't be OC kings, that is for sure and I don't think anyone reading this thread thinks they'll OC to 5Ghz after seeing how current gen performed. A speed of 4.5Ghz as top OC would be great, but chances are low for the CPUs to achieve it. But hey, you never know!

In regards to the cache, I still think the documentation aims to explain TR/EPYC Zen versions and leaving Summit Ridge to an earlier version of Zen that wasn't covered in detail. As per the particular details, I have no way to confirm this, so it's just a hunch.

Cheers!

 

[goldstone77]

AMD Responds to CTS Labs Security Allegations, Resolutions Incoming
By Joel Hruska on March 21, 2018 at 7:28 am

TrailofBits, which performed a third-party analysis and verification of the bugs CTS located, writes:

There is no immediate risk of exploitation of these vulnerabilities for most users. Even if the full details were published today, attackers would need to invest significant development efforts to build attack tools that utilize these vulnerabilities. This level of effort is beyond the reach of most attackers…

These types of vulnerabilities should not surprise any security researchers; similar flaws have been found in other embedded systems that have attempted to implement security features. They are the result of simple programming flaws, unclear security boundaries, and insufficient security testing.

The flaws are real, require updates, and need to be dealt with — but they do not represent a cataclysmic security failure. They certainly do not represent the company-ending apocalypse that CTS Labs’ suspected partner-in-crime, Viceroy Research, said they did. Meanwhile, there’s no sign of any effort by CTS Labs to address the backdoors and critical security flaws baked into tens of millions of Intel motherboards courtesy of their onboard Asmedia controllers, even though the ASM1042 and ASM1142 have shipped on Intel products for the past six years.

Bad Faith Doesn’t Excuse Bad Security
CTS Labs entire effort, start to finish, appears to have been an attempt to weaponize security disclosures and harm a company in the name of earning money for unscrupulous investors. It’s a textbook example of why security analysis and disclosure must be handled carefully. But none of this changes the fact that these security issues shouldn’t have existed in the first place.

Both AMD and Intel have asked computer users to accept the presence of black box security implementations in the name of increased security. Intel has its Intel Management Engine, AMD has its TrustZone processor. AMD uses an ARM solution with a Cortex-A5 integrated processor, Intel uses its own Quark CPU. Both companies have resisted calls to provide documentation and/or open source code for these solutions, and yet the security of both has repeatedly been found wanting. As devices become more tightly integrated and the number of components and IP blocks integrated into SoCs rises, it’s increasingly important manufacturers follow best security practices from start to finish. Both Intel and AMD have more work to do in this regard.

https://www.extremetech.com/computing/266046-amd-responds-cts-labs-security-allegations-resolutions-incoming

 

[goldstone77]

AMD Flaws - The Full Story & Analysis
AdoredTV
Published on Mar 21, 2018
Stock manipulation or something even more sinister?
https://www.youtube.com/watch?v=GNPcxXZ2ki8&feature=youtu.be

 

[juanrga]

I think there will be a 2800X, but down the road. If not, they'll probably skip to the "3800X" for Zen v2.

Why would a 2800X model there exist? Because a 1800X model does exist? If we check current line the 1600X has the same clocks than the 1800X. Both are 95W models that can boost up to 4.0GHz. All the rest of 1000-series models have lower clocks.

In the 2000-series the 95W 2600X has 100MHz less than the 105W 2700X. One can boost to 4.25GHz and the other does to 4.35GHz.

Also the 2800X is not the only model lacking in new 2000-series. As showed in a former slide there is no 2200, 2300X or 2500X models, despite the existence of current o 1200, 1300X and 1500X models today. And other slide given shows the 1800X is replaced by the 2700X. (AMD even compared the performance of the 2700X to the 1800X) So what is the rationale to expect a 2800X model? That a 1800X model exists?

AMD Responds to CTS Labs Security Allegations, Resolutions Incoming
By Joel Hruska on March 21, 2018 at 7:28 am
https://www.extremetech.com/computing/266046-amd-responds-cts-labs-security-allegations-resolutions-incoming

All what CTS-labs said was true. There are 13 security flaws on AMD Zen systems. The only disagreement is that CTS-labs claimed months for the fixes and AMD claims weeks.

People in the comment sections of that article and in older articles has explained Joel that it is not the same to have a flawed USB controller in some Intel mobos, than having a flawed security controller (with access to everything) in all AMD Zen-based systems. People has explained him that Ryzenfall, Masterkey, and Fallout are exclusive to AMD.

Some Intel systems could be affected by a version of Chimera; people has explained him that CTS-labs tested Intel systems as well: "We've looked into quite a few computers made by HP, Dell, Lenovo, etc. and they were not affected."

But Joel insists...

 

[juanrga]

CTS-LABS RESPONSE TO AMD’S INITIAL ASSESSMENT OF VULNERABILITIES

Resume:

* We believe AMD is attempting to downplay the significance of the vulnerabilities
* Our view is AMD’s suggested timeline for its patches roll out is drastically optimistic –we believe a number of the fixes are likely to take months, not weeks
* We believe the AMD flaws have potential to turn a local problem into a network-wide problem
* Notably, AMD did not provide a time estimate for patching CHIMERA

https://safefirmware.com/CTS+comments+on+AMD+response+to+vulnerabilities.pdf

 

[-Fran-]

I think there will be a 2800X, but down the road. If not, they'll probably skip to the "3800X" for Zen v2.

Why would a 2800X model there exist? Because a 1800X model does exist? If we check current line the 1600X has the same clocks than the 1800X. Both are 95W models that can boost up to 4.0GHz. All the rest of 1000-series models have lower clocks.

In the 2000-series the 95W 2600X has 100MHz less than the 105W 2700X. One can boost to 4.25GHz and the other does to 4.35GHz.

Also the 2800X is not the only model lacking in new 2000-series. As showed in a former slide there is no 2200, 2300X or 2500X models, despite the existence of current o 1200, 1300X and 1500X models today. And other slide given shows the 1800X is replaced by the 2700X. (AMD even compared the performance of the 2700X to the 1800X) So what is the rationale to expect a 2800X model? That a 1800X model exists?

Yes, is that so weird? Their naming structure is pretty straight forward, all things considered. Although I do concede that having the 1700 siblings and 1800 siblings was a bad idea, since there wasn't enough differentiation between them. Maybe AMD learned about it and just pushed the 2700X for now.

Also, CTS-Labs comeback is weak sauce. Their "beliefs" should not be. This is a deeply technical matter, so they must prove and provide the evidence. There's nothing more to it.

 

[CountMike]

If AMD intended to keep 2700x as top model they would have called it 2800x but they are probably hoping to increase frequencies once production gets improved. Hope they don't do as gradually as with Bulldozer and go to 2720/50/70 as it didn't matter much and was just confusing things.

 

[daerohn]

AMD renaming the top model of their Zen+ line with 2700x can also be a marketing move. In fact if you call your top model of your latest line 2700x people may think it as a successor to previous gen 1700x. and compare the clock speed of both CPU's. However you need to compare the top line CPU's of both generation. Right now 1800x vs 2700x. So we have a CPU of 3,6 GHz base clock vs a CPU with base clock of 3,7 Ghz. So literally the increase in clock speed is around 2,8%.

In fact I was expecting a clock speed increase around 8%-10% which means 3.9~4.0Ghz base clock. And boost speed increased to 4.5 Ghz. Right now there is nothing about Ryzen 2800x and this naming may be a marketing move. And I do not like this kind of politicial decisions. If your process is not as good as you initially think you should say it directly.

Howevever if the performance difference between a 1800x and 2700x is around %8 to %10 this means this CPU is still a good one.

 

[daerohn]

Also there are some so called leaked performance tests going around showing good increase in performance when compared to a 1700x however Intel part comperad is an old one, i7 6700k, I wonder what the results would be like against a 8700k and of course with AVX512 also added to the tests.

https://www.notebookcheck.net/AMD-Ryzen-7-2700X-and-Ryzen-5-2600-get-detailed-in-leaked-review-available-from-April-19.289396.0.html

https://www.forbes.com/sites/antonyleather/2018/03/16/amd-ryzen-7-2700x-benchmark-review-leaked-much-faster-than-1700x/#ec773159598c

https://www.techpowerup.com/242506/amd-ryzen-7-2700x-ryzen-5-2600-review-popped-up-ahead-of-time

http://www.tomshardware.co.uk/amd-review-2700x-2600-ryzen,news-58062.html

 

[goldstone77]

CTS-LABS RESPONSE TO AMD’S INITIAL ASSESSMENT OF VULNERABILITIES

Resume:

* We believe AMD is attempting to downplay the significance of the vulnerabilities
* Our view is AMD’s suggested timeline for its patches roll out is drastically optimistic –we believe a number of the fixes are likely to take months, not weeks
* We believe the AMD flaws have potential to turn a local problem into a network-wide problem
* Notably, AMD did not provide a time estimate for patching CHIMERA

https://safefirmware.com/CTS+comments+on+AMD+response+to+vulnerabilities.pdf

Juanrga, when do scientist use terms like we believe without showing proof of work? It's like going to a used car lot, and having the sales man tell you we believe this is the best deal we could get you! <smile; wink; handshake> Sorry, real or not the threats are over hyped joke requiring administrative access to implement. It's a drop in the bucket in comparison for a typical year.
Nearly 1 million new malware threats released every day
by Virginia Harrison and Jose Pagliery @CNNTech
April 14, 2015: 11:54 AM ET
http://money.cnn.com/2015/04/14/technology/security/cyber-attack-hacks-security/index.html

More than 317 million new pieces of malware -- computer viruses or other malicious software -- were created last year. That means nearly one million new threats were released each day.