Dual-CCD Ryzen 5 5600X and Ryzen 7 5800X In the Wild

[mb194dc]

Interesting find by Igor, there are other weirdies on some of the older Ryzens as well.

E.g my generation one Ryzen 5 1600 with dual channel 2666mhz ram benches at 50GB/s memory transfer rate ~ in AIDA and shows higher than expected bench in others too. Only when I overclock it on the fly using the original version of Ryzen Master. That should be impossible, theoretical max bandwidth with only 2 channels of this ram is 21.3 x 2=42.6GB.

I had wondered if there was either a bug in the benches or if that version of Ryzen Master accidentally has some code AMD should have taken out of it...

 

[Wirko]

IIRC it has been said on-die CCX-to-CCX communication basically goes through IOD.

Given that the latencies are around 80 ns, it doesn't go just through IOD, it goes through DRAM. Well, not exactly "through" but at least it looks like the data needs to be written to main memory before it can be transferred from one CCX to another (Ryzen 2) or from one CCD to another (Ryzen 3).

 

[Valantar]

Given that the latencies are around 80 ns, it doesn't go just through IOD, it goes through DRAM. Well, not exactly "through" but at least it looks like the data needs to be written to main memory before it can be transferred from one CCX to another (Ryzen 2) or from one CCD to another (Ryzen 3).

I very sincerely doubt that - that would be an extreme bottleneck, and would likely cause some serious power draw issues too. Besides, wouldn't that cause a lot more latency than plain DRAM latency, seeing how it would essentially be at least two operations (one write, one read)?

 

[Wirko]

I very sincerely doubt that - that would be an extreme bottleneck, and would likely cause some serious power draw issues too. Besides, wouldn't that cause a lot more latency than plain DRAM latency, seeing how it would essentially be at least two operations (one write, one read)?

Sure it is an extreme bottleneck, one that core-to-core latency tests are designed to create and measure. No, I don't think data is read from DRAM immediately after being written to it. But I do think that when two sections of L3 cache on different CCDs need to be synchronised, this can't be done without also writing the changed data to DRAM. This results in an 80 ns latency.

 

[Valantar]

Sure it is an extreme bottleneck, one that core-to-core latency tests are designed to create and measure. No, I don't think data is read from DRAM immediately after being written to it. But I do think that when two sections of L3 cache on different CCDs need to be synchronised, this can't be done without also writing the changed data to DRAM. This results in an 80 ns latency.

Hm. Given that the L3 is non-inclusive that would make sense, but would that even be a part of the latency measurement? If data needs to be ejected from the L3 and into DRAM, wouldn't that need to happen before the CCX-to-CCX measurement can even take place?

 

[Wirko]

I'm hoping that someone with greater knowledge joins in here.

Inclusive vs. exclusive describes the relation between various levels of cache, not between parts of L3 that reside on separate dies, so it shouldn't matter here.
This is how a core-to-core latency measurement is done, I suppose:
1. A thread running on core A writes some data to memory location X
2. A thread running on core B reads data from memory location X a couple nanoseconds later
3. The control program measures how long core B has waited before it got the data
4. Everything is repeated many times to make sure all write buffers are overflown etc. At the end, some statistical calculations are performed.
Now if A and B are on separate dies, X needs to be copied from A's caches to B's caches (L3 may not even be involved here). To do this, it't not absolutely necessary to write X back to DRAM; however, that's what a Ryzen with two CCDs does, and that makes core-to-core latency as high as DRAM latency. This sounds bad but it probably allows the cache sync logic to be less complex and faster.

Some more info is here (for Ryzen 1), the most interesting bit is "This means that the true LLC for the entire chip is actually DRAM".

 

[Valantar]

I'm hoping that someone with greater knowledge joins in here.

Inclusive vs. exclusive describes the relation between various levels of cache, not between parts of L3 that reside on separate dies, so it shouldn't matter here.
This is how a core-to-core latency measurement is done, I suppose:
1. A thread running on core A writes some data to memory location X
2. A thread running on core B reads data from memory location X a couple nanoseconds later
3. The control program measures how long core B has waited before it got the data
4. Everything is repeated many times to make sure all write buffers are overflown etc. At the end, some statistical calculations are performed.
Now if A and B are on separate dies, X needs to be copied from A's caches to B's caches (L3 may not even be involved here). To do this, it't not absolutely necessary to write X back to DRAM; however, that's what a Ryzen with two CCDs does, and that makes core-to-core latency as high as DRAM latency. This sounds bad but it probably allows the cache sync logic to be less complex and faster.

Some more info is here (for Ryzen 1), the most interesting bit is "This means that the true LLC for the entire chip is actually DRAM".

I'm by no means an expert here, but I don't think this is right. I think it's important to include the entirety of that sentence you quoted at the end:

This means that the true LLC for the entire chip is actually DRAM, although AMD states that the two CCXes can communicate with each other through the custom fabric which connects both the complexes, the memory controller, the IO, the PCIe lanes etc.

What I take from that: "true LLC" for AnandTech is a cache that is equally available/shared across all compute resources (in this case: CCXes). Since the L3 is bound to its CCX, that makes DRAM the "true LLC" in this sense.

As for the above, I don't think your reasoning towards the end is right - that still feels like that would add far more latency than just DRAM latency, as there are more steps involved in a core-to-core measurement than in a straight DRAM access. The part of the sentence from the 1800X review also supports this, by saying that the two CCXes can communicate (implied: directly) through IF, bypassing memory. It's clear that cores on the same CCX can access each other through the L3, so I would assume the access pattern for intra-CCX access to be something like core-L3-IF-[some sort of management system on the IOD]-IF-L3-core.

But I entirely agree on your first point, I hope someone with greater knowledge could jump in and explain this to us

 

[RdGBoY]

i have a 3600 and show "Active CCD#2"

 

[kaisersolo]

Probably not ,start a thread for your issue , if the other CCD is dead ,Lazer cut or removed via other means it's still not there to the system and can't get involved in issues.
Although this isn't impossible it's unlikely.

Actually, It is the reason why I cannot see my cores just like other 2 CCD users of 5600x and 5800x - This will be fixed apparently this month in new version of Ryzen master.

 

[TheChester]

The likelihood of these being somehow unlockable is essentially zero. I would be shocked if anyone could pull that off. If a CCD is disabled, nothing in the system knows it's there, after all.

I'm not so sure of that. I was having trouble getting ryzen master to work. I then opened Clock tuner and it says "You have a unique processor. Active CCD#2."

 

[craxton]

The likelihood of these being somehow unlockable is essentially zero. I would be shocked if anyone could pull that off. If a CCD is disabled, nothing in the system knows it's there, after all.

idk bud best take a "look" at this as it can read that CCD etc.
and tell you if ya gotta "decent" overclocker or not on the core side of things.

my 5600x is a 80 sil quality lowest ive seen out of 100s of other users using it. but
i can run 4000 1:1:1 DAILY c16 flat tuned without issues, overclocking a static core clock however
could only run 4600 at 1.35v and that wasnt prime stable. (did get CO dialed in tho)
this is that tool tho, https://drive.google.com/file/d/1p3ilWHGaVd_Afso4KqpjSsAVpfq88M85/view?usp=sharing

now my 5800x i get 5000 WHEA-19s an hour or did, now i get around 500 an hour with some IOD, CCD adjusting.
but its got 120 sil quality and hits 5ghz on most cores no issues.
none the less ill possibly just shut the dam logger up with Mannaitx's WHEA suppressor from OCN.
but yea its been stated that it can happen by a few who knows what theyre speaking on. not 100% sure or not.
but its being worked on

 

[TheChester]

Am I using the AMD V/F tool correctly for my 5800x? It's show my Sil Quality as 125.278. Also what is the Cooler Score?

 

[PvtMaYhEm]

Is there any update on this?

I apparently have a Dual CCD 5600X.

Wondering if I should try the lottery again, or just go with a 5900X or wait for Zen4 launch.

It still OC's to 4.85GHz with AutoOC/Curve Optimizer enabled w/ -30 per core and 200 boost. But it is warm at that speed. lol.