Speculation: Ryzen 3000 series

[naukkis]

Signals travel really fast in such a short space. Propagation delay will be really small by putting IO on a separate die. The buffering logic will probably be the main contributor of signal delay. I'd be surprised if it added even close to 30 ns of latency.

2700x random access latency is ~83ns with 2666, so maybe 7ns more. But that es sample is with single-channel memory - random access latency should be a bit lower with dual-channel configuration - and we don't know memory timings which might be still suboptimal with ES.

 

[dnavas]

I'm not as familiar with the inner workings of IF and such, how much serializing are they doing from chiplet to IO, does anyone know? Is it fully parallel?

That's why I used the inter-CCX numbers for Ryzen7. All things being equal, you're not going to get better than on-chip, and lo and behold, we did, so, all things aren't equal, they're a lot better. I was more curious why someone thought those numbers looked fishy -- lack of rise between cross-CCX L3 access and memory maybe? Wasn't sure....

2700x random access latency is ~83ns with 2666, so maybe 7ns more.

Note: I was factoring in some improvements to memory access with Zen2, thus my 60/30 split :shrug:

 

[Shivansps]

This was expected.

3.4Ghz base... mmm i would expect at least 4.2ghz turbo.

 

[DrMrLordX]

Does it? Cross-CCX latency was 120ns-ish on the 1800X, so if the separate IO die is only adding (say) 30ns to RAM access, that actually sounds on the better side of what could have been. Clearly the separate I/O die is going to add latency, that isn't a surprise....

The memory controller was already separated from the CCXs by an IF link on Zen/Zen+ so the propagation delay to a IF-connected I/O die shouldn't be that much different.

2700x random access latency is ~83ns with 2666, so maybe 7ns more. But that es sample is with single-channel memory - random access latency should be a bit lower with dual-channel configuration - and we don't know memory timings which might be still suboptimal with ES.

Right, we don't know the timings. Subtimings do matter. I have learned the hard way that if you raise the wrong one, memory performance can go straight to hell.

If Zen2 is still 2CCX design it has 2 L3 caches like Zen1, and memory access latency rises after 16MB L3 chunk like it does after 8MB with Zen1.

That's possible, or it's 16MB per chiplet, and inter-chiplet latency is killing it.

 

[Topweasel]

I'm not sure it is following the same pattern.
That TR graph shows clearly that there's a difference between going across CCX than going to memory. It goes cross CCX between 8MB and 16MB, then to memory beyond that.
The ES goes straight from 16MB L3 to what looks like memory by the point it hits 32MB. I would be expecting the big jump to be after 32MB if there was 32MB L3, but we see that it is already taking that hit at 32MB.
No idea why it then drops off slightly beyond that though. Seems unusual.

But it evens out with memory when it goes to the second chip. Seems like the 7ns jump at 16mb replaces the old 80ns jump when switching CCX's and the big jump at 32 is because the software tricks itself out and thats really because at that size it's at the intersection of on die and off die.

 

[Timorous]

2700x random access latency is ~83ns with 2666, so maybe 7ns more. But that es sample is with single-channel memory - random access latency should be a bit lower with dual-channel configuration - and we don't know memory timings which might be still suboptimal with ES.

As the clockspeed and memory speed are so low it is entirely possible the IO die is not running at full speed either and we all know memory latency improves as IF speed increases.

 

[coercitiv]

2700x random access latency is ~83ns with 2666, so maybe 7ns more. But that es sample is with single-channel memory - random access latency should be a bit lower with dual-channel configuration - and we don't know memory timings which might be still suboptimal with ES.

For reference, I ran the test on a 1600X with 2133 CL15 RAM in single-channel, and the result was 93.8ns.

 

[Grumpy Cat]

Is everyone expecting the 8 core Ryzen 3000 to be a single chiplet like Lisa Su held up?
I'm thinking that 2 four core chiplets might be faster.
With only a single chiplet isn't half the I/O chip to chiplet bandwidth being wasted.
I think there is a reason we don't know the cache, memory configuration. Remember Rome isn't a NUMA design.

 

[DrMrLordX]

Is everyone expecting the 8 core Ryzen 3000 to be a single chiplet like Lisa Su held up?

I expect there to be an SKU that matches the ES they demonstrated, which presumably was one chiplet plus an I/O die.

that 2 four core chiplets might be faster.
With only a single chiplet isn't half the I/O chip to chiplet bandwidth being wasted.

Uh? So far as I can tell, the I/O die just has two external IF links. Leaving one of those IF "dead" is meaningless. You don't want two 4c chiplets anyway since you'll create the same (or worse) thread migration/L3 cache snoop penalties we see on Zen/Zen+. At least in a Zen CCX, we have a direct IF crossbar between CCXs (one hop). In Zen2, there will be two hops from one chiplet to the other.

 

[Tuna-Fish]

Regarding that benchmark, and the latency graph, the various articles are suggesting that the steep rise in latency between 16MB and 32MB indicates 32MB L3 cache, but if the rise is between the two then that must indicate that its 16MB L3, not 32MB, surely? What am I missing?

The current assumption is that each chiplet consist of two CCX, and each CCX has 4 cores and 16MB of cache. So a 12-core chip would have one core of each CCX disabled for 4x3core CCX and each CCX with 16 MB of cache. Since the L3 is a victim cache to it's "own" CCX, no other CCX can benefit from it.

 

[IEC]

I expect there to be an SKU that matches the ES they demonstrated, which presumably was one chiplet plus an I/O die.

Uh? So far as I can tell, the I/O die just has two external IF links. Leaving one of those IF "dead" is meaningless. You don't want two 4c chiplets anyway since you'll create the same (or worse) thread migration/L3 cache snoop penalties we see on Zen/Zen+. At least in a Zen CCX, we have a direct IF crossbar between CCXs (one hop). In Zen2, there will be two hops from one chiplet to the other.

Agreed. It's also why I suspect the single chiplet models will be best for *gaming*, while those of us who want more cores will certainly be interested in 16c/32t models.

 

[Timorous]

I was posting in a console speculation thread else where after reading a user suggest the console CPU might have less cache and it got me thinking.

What if single chiplet designs only have half of the L3 cache and multi chiplet designs use all of it. It might be a way to upsell the 12c and 16c models as well as another way to make use of partially defective chips.

 

[Kedas]

Agreed. It's also why I suspect the single chiplet models will be best for *gaming*, while those of us who want more cores will certainly be interested in 16c/32t models.

Well I assume there will also be some 'gaming mode' for >8 core versions like they have now.

 

[Lovec1990]

do we need gaming mode at all it would be better if games would be tought too use just one Chiplet

 

[PotatoWithEarsOnSide]

Gaming actually gimped performance.

 

[Kedas]

do we need gaming mode at all it would be better if games would be tought too use just one Chiplet

The hardware can do it but it's the OS that may have trouble handling the change in a stable way.

 

[porcupineLTD]

Well, Adored uploaded again, this is going to be fun.

 

[Markfw]

Well, Adored uploaded again, this is going to be fun.

How about a link for those of us that don't know where to go.

 

[thigobr]

That's his new video:

 

[dlerious]

Well, Adored uploaded again, this is going to be fun.

Two 4-core chiplets on the 8-core sounds ok. They can save the 8-core chiplets for Threadripper and Epyc until yields improve more. I think 16-core desktop will come later.

 

[PeterScott]

That's his new video:

Yay, another paragraphs worth of speculation spread over half an hour...

 

[PPB]

Two 4-core chiplets on the 8-core sounds ok. They can save the 8-core chiplets for Threadripper and Epyc until yields improve more. I think 16-core desktop will come later.

What makes you think the yields of an 80mm2 7nm chip are low?

People here underestimate the enormous benefit AMD has found in doing your uncore on your n-1 node: you largely increase yields on your important bit, the n node core die.

 

[Mockingbird]

That's his new video:

FakeTV again?

 

[Markfw]

FakeTV again?

I am sick of you calling this fake tv. The guy got a few things wrong last video. That does not make it fake. He got some right also.
Shut the hell up !

 

[Mockingbird]

I am sick of you calling this fake tv. The guy got a few things wrong last video. That does not make it fake. He got some right also.
Shut the hell up !

Aside from braking the forums rules (http://www.portvapes.co.uk/?id=Latest-exam-1Z0-876-Dumps&exid=threads/anandtech-forum-guidelines.60552/), you just disregarded you own moderator request.


If you have an issue with moderation,
you create a post in moderator discussions.
You do NOT do it here.

AT Mod Usandthem