If they leave it unlocked and it can OC to 4GHz (same with the 16 core), and supermicro makes a supero gaming board for it, while stacking enough pcie slots for graphics, I would buy it...
Last edited:
If they leave it unlocked and it can OC to 4GHz (same with the 16 core), and supermicro makes a supero gaming board for it, while stacking enough pcie slots for graphics, I would buy it...8 core epyc make sense if there is request for it, amd wouldnt base its market strategy on random defective parts
if there's request for it there will be parts sold, defective or less.
You must be too young to remember when AMD schooled the hell out of Intel back in the day, but there were times it even did this with processors that were built on a much larger process than the Intel equivalent. Just because a CPU like Ryzen is using a LP optimized 14 nm process does not mean it can't school the hell out of intel in IPC. That's definitely *NOT* the case for Ryzen, but everything we've seen so far indicates that AMD could get another 15% IPC gain EASILY on the same process. This is to say nothing of moving to a more performant one. Ask an Intel Exec about how they fared against AMD prior to the Core 2 launch. Due to that little screw-up, Intel now has to cross license several technologies from AMD. I can't wait for Threadripper, 2018, and beyond because if AMD keeps this up, the next few years are going to be GREAT for consumers.
The PCIe lane limitation isn't an issue with the dies. It's a packaging issue with them wanting to continue to use a similar socket size to AM3 while supporting APU's. Mobo manufacturers and OEM's probably told them they would rather have that then a bigger socket.B2 reportedly fixes bugs in the uncore/SoC. We know that AM4 doesn't make use of all of the potential 32 PCIe lanes that should be there per Ryzen die, so possibly there were hardware issues there that first had to be resolved for the MCM packages before Epyc/Threadripper's launch. That may be what the B2 stepping is about, functionally equal to B1 wrt its use on AM4 but a necessity for the upcoming MCM chips.
Could B2 change anything about inter-CCX communications? Wasn't there some reports that some of the ES used a different multiplier (of the DDR4 frequency) than the release version?
Now that is a shame...Ryzen engineering samples were able to set infinity fabric clock to 1:1 (ddr), this ability has been removed from final Ryzen, probably wasnt reliable enough for mass production.
https://www.eteknix.com/amd-zen-8core-engineering-sample-leaked/
And false. The confusion is that the clock speed of DDR memory upto and including DDR4 by it's speed post Double Data Rate. The IF configuration is 1:1 on Ryzen. I doubt we will see anything better. This protocol is used for everything including as an interconnect with GPU CUs. They picked the 1:1 for a reason probably has more to do with GPU's than CPU's. I still don't know why this is as much of a focal point (IF latency) as it has become. where theory became certainty with little evidence to back it up. Sure increased latency isn't good, but do we really know it's "adversely" affecting anything?Now that is a shame...
My point was that AM4 doesn't use all 32 PCIe lanes so if that's an area where uncore fixes were done AMD may either have wanted that for increasing yield, or the uncore wrt all lanes wasn't actually finished/completely working by the time Ryzen launched and B2 stepping is what they worked toward for use in the MCMs. Either way wouldn't be visible on AM4.The PCIe lane limitation isn't an issue with the dies. It's a packaging issue with them wanting to continue to use a similar socket size to AM3 while supporting APU's. Mobo manufacturers and OEM's probably told them they would rather have that then a bigger socket.
Which I said prior, except that a new stepping will make it into the inventory. That depends on sales. If the APU is not using it, they still have to move the inventory in channel before coming for more. They likely front-loaded the large number as there is so much fab time and they have products rolling out regularly at least until and through Q3. If they stack volume during the preceding 3 month period, then they have a bit of extra time coming up soon. Until we see Q2 numbers, though (next month to early Aug.), we can't really tell how well Ryzen is doing, as only one month's time was on the Q1 filings. That is why I'm hesitant, but yes, it will be done quietly as with others.And false. The confusion is that the clock speed of DDR memory upto and including DDR4 by it's speed post Double Data Rate. The IF configuration is 1:1 on Ryzen. I doubt we will see anything better. This protocol is used for everything including as an interconnect with GPU CUs. They picked the 1:1 for a reason probably has more to do with GPU's than CPU's. I still don't know why this is as much of a focal point (IF latency) as it has become. where theory became certainty with little evidence to back it up. Sure increased latency isn't good, but do we really know it's "adversely" affecting anything?
As for the stepping changes. It will without AMD announcing a new "series" of Ryzen R7 and such, possibly increase clock limits, improve yields, have less power leakage and display better power management, or resolve some issues that required microcode updates to fix. Things like a tweak to the memory controller to allow to clock memory higher.
It will not include a better IF. It's not going to unlock PCIe lanes. It isn't going to have any noticeable affect on performance. Things that people want to see won't happen till the refresh next year at the earliest.
My point was that AM4 doesn't use all 32 PCIe lanes so if that's an area where uncore fixes were done AMD may either have wanted that for increasing yield, or the uncore wrt all lanes wasn't actually finished/completely working by the time Ryzen launched and B2 stepping is what they worked toward for use in the MCMs. Either way wouldn't be visible on AM4.
Which I said prior, except that a new stepping will make it into the inventory. That depends on sales. If the APU is not using it, they still have to move the inventory in channel before coming for more. They likely front-loaded the large number as there is so much fab time and they have products rolling out regularly at least until and through Q3. If they stack volume during the preceding 3 month period, then they have a bit of extra time coming up soon. Until we see Q2 numbers, though (next month to early Aug.), we can't really tell how well Ryzen is doing, as only one month's time was on the Q1 filings. That is why I'm hesitant, but yes, it will be done quietly as with others.
Now, going from single to double rate speeds is a fair increase in frequency. Although the question pertained to the Ryzen mainstream CPUs, it has implications on the TR and EPYC lines. There, it can add up considerably. Personally, I'd like to hope that extra performance will also be seen with the speed gains from quad and octo-channel memory on the latter lines, but we do not yet know. But to outright say it is not a shame to run at SR vs DR is to say you are satisfied with the lower rate. I'm not saying that the DR is needed, but it would be nice (want to want). I'm also not saying that it negatively effects the chip.
I offer an alternative. The AM4 will include the APU. The APU may dedicate 16 lanes to the iGP. As such, you would need to plan for that from the outset. Considering turning off lanes depending the CPU inserted (as is seen with Intel HEDT) increases costs drastically, it is likely the decision at the outset to have the limited number of PCIe lanes on the platform. Just an educated guess.But AM4 not using all the PCIe has nothing do with PCIe PCH yields. They new what they wanted PCIe wise in Zen for server and workstations. That is why it is 32 lanes on those units per Die. When they designed AM4 they wanted to stop having split platforms for the APU's. To keep the pin count down and probably to avoid moving to LGA on the consumer sockets they didn't connect a bunch of the PCIe lanes. Speculating that there was any need to improve the connectivity has no foundation, because the decision not to include them had nothing to do with yields.
So far, the steppings are line specific, not chip specific, although there is good reason to use a different stepping for the APU. Also, I would suspect EPYC to get first priority, TR next depending on sales between that and Ryzen. Meanwhile, we must remember that previously it has been said GloFo is hitting at over 80% yields on Ryzen dies.I am not questioning it making its way into inventory and there is reason to track and look for newer steppings. The APU's won't be using it. Since the steppings as we know of are chip specific. They can include the changes that they made to other dies. But it would be it's own stepping. But again AMD isn't release new R7's and Threadripper and EPYC may get priority for the new dies. But that screams less leakage than any performance impacting changes.
I never said that it was a bug. In fact, as software optimizations for the architecture have come out, we have seen significant increases in performance. It is needing optimizations from software designers is all. I'm not going to speculate on the choice as this is the first generation in a long time that the graphics processor was not designed around the CPU architecture, nor am I critiquing their decision on the design. With that said, I can still want to clock the infinity fabric faster as the theoretical limit for version 1 (that I've read in a couple places, but not confirmed) is 512Gbps. By being able to increase that frequency further, we just can better utilize the tech in our products. See what I'm saying? I'm not bashing on AMD at all, just excited to see what it could do if cut loose. I'm also excited to see what will come from gen 2 and the potential of multiple GPU dies on a single board instead of increasing the size of a single die, what the scaling will be, and the potential to have n-scale crossfire in future iterations. So I think you may be reading my comment with the wrong tone.Either way what we see on Ryzen with cross CCX communication is not a bug. Something to clean up. There wasn't an issue with IF or the CCX's. What we see is a design decision. Maybe it's something we see cleared up in with the refresh next year. But it's not something AMD walked into late and pushed forward. It is a standard that AMD decided and probably not even for the CPU's because honestly the impact is small either way. It was made for the GPU's. It means we get something by itself is less than optimal. But that is what CPU design is about. Compromise.
We aren't even arguing, all you said is correct (but you keep focusing on parts that never mattered for mine). I never even talked about connectivity aside the fact that AM4 doesn't use all 32 lanes and that B2 is reported to fix stuff in uncore/SoC, not the cores themselves (I'm not KompuKare nor nix_zero). Also steppings like B2 are usually minor enough that we never hear details about what the fixes entail. All I stated was that this particular stepping was likely in preparation for the MCMs and that the above mentioned choice for AM4 means we won't be able to tell either way anyway (unless we come across any Epyc/Threadripper using B1 stepping which I don't expect). If you disagree with that, alright, but all that got way wordier and longer than that particular topic was worth. ^^But AM4 not using all the PCIe has nothing do with PCIe PCH yields. They new what they wanted PCIe wise in Zen for server and workstations. That is why it is 32 lanes on those units per Die. When they designed AM4 they wanted to stop having split platforms for the APU's. To keep the pin count down and probably to avoid moving to LGA on the consumer sockets they didn't connect a bunch of the PCIe lanes. Speculating that there was any need to improve the connectivity has no foundation, because the decision not to include them had nothing to do with yields.
I offer an alternative. The AM4 will include the APU. The APU may dedicate 16 lanes to the iGP. As such, you would need to plan for that from the outset. Considering turning off lanes depending the CPU inserted (as is seen with Intel HEDT) increases costs drastically, it is likely the decision at the outset to have the limited number of PCIe lanes on the platform. Just an educated guess.
I never said that it was a bug. In fact, as software optimizations for the architecture have come out, we have seen significant increases in performance. It is needing optimizations from software designers is all. I'm not going to speculate on the choice as this is the first generation in a long time that the graphics processor was not designed around the CPU architecture, nor am I critiquing their decision on the design. With that said, I can still want to clock the infinity fabric faster as the theoretical limit for version 1 (that I've read in a couple places, but not confirmed) is 512Gbps. By being able to increase that frequency further, we just can better utilize the tech in our products. See what I'm saying? I'm not bashing on AMD at all, just excited to see what it could do if cut loose. I'm also excited to see what will come from gen 2 and the potential of multiple GPU dies on a single board instead of increasing the size of a single die, what the scaling will be, and the potential to have n-scale crossfire in future iterations. So I think you may be reading my comment with the wrong tone.
Yeah I guess I just took offense to the idea that a new stepping was to fix PCIe in any way. It's one of the far out there theories that isn't really based on actual information. We know the PCIe is disabled. We know why it was disabled, Packaging with support for the APU's on a platform that PCIe limitations aren't the biggest worries. So once it was suggested it was those disabled PCIe (more like unconnected) that were the issue it just seemed kind of baseless. They aren't disabled for no reason ala Intel. They aren't disabled because of issues with the yields on that portion of the dies, they are disabled because of APU support and packaging. It isn't a mystery that needs to be solved.We aren't even arguing, all you said is correct (but you keep focusing on parts that never mattered for mine). I never even talked about connectivity aside the fact that AM4 doesn't use all 32 lanes and that B2 is reported to fix stuff in uncore/SoC, not the cores themselves (I'm not KompuKare nor nix_zero). Also steppings like B2 are usually minor enough that we never hear details about what the fixes entail. All I stated was that this particular stepping was likely in preparation for the MCMs and that the above mentioned choice for AM4 means we won't be able to tell either way anyway (unless we come across any Epyc/Threadripper using B1 stepping which I don't expect). If you disagree with that, alright, but all that got way wordier and longer than that particular topic was worth. ^^
Zen+ is where we will see actual optimizations that AMD will openly talk about.
TBH, I haven't paid much attention to the APU as I plan on using discreet graphics and am looking at TR or EPYC (if unlocked on at least one 16C and able to reach 3.6-4.0 overclock with sufficient cooling). So thank you for enlightening me as to the PCIe lane restriction. Do you have a source? (I always ask for sources, so don't take it personal, it is so that I can point to something other than a forum). But noted.Well it's too late to offer that as an alternative. AM4 supports APU's. There are already APU's that use the socket and Raven Ridge will also be using the socket. My point is the same though, well little different. AM4 PCI lanes are restricted to 8x PCIe when an APU is installed to the video card. Which probably means that the 8 they disabled and additional 8 goes to the iGPU. Or some other combination. The end result is a packaging or technical decision and never about bad yields on the PCIe components.
I saw that hoopla. I see why you are fighting it, but I do agree. AIDA64 I don't consider the most accurate, instead relying more on MemMaxx2 for figuring out throughput (and to a lesser degree the numbers from memtest86+). But as I said, you see increased performance from software optimization, which even Intel benefits from, just to a far lesser degree (AMD=15+%, Intel = 1-3%).No not yours in general but all IF latency issues in general. I agree it would be nice to see it in it's unbridled power. But that 512Gbps. Is at Vega's 512bit bus at much higher data rate do to using really fast HBM2 (which would also apply to mini vega's later using GDDR5X). But it goes back to recent other posts and farther back. It starts with someone realizing that sometimes Adia reports a L3 Latency of 120ms. Then someone tests and finds an 80ms increase in latency when going from CCX to CCX. All of a sudden it becomes "the problem" for gaiming. Then it becomes either A.) A crappy design decision B.) A bug in the design that AMD had to push forward and would clear up later. To maybe in the next stepping AMD can take care of the CCX latency bug and on and on. All with very little actual analytical to show that there is even that much of an impact. What was once an early theory became fact and ignores the actual issues like Nvidia's poor core scaling in DX12.
But AM4 not using all the PCIe has nothing do with PCIe PCH yields. They new what they wanted PCIe wise in Zen for server and workstations. That is why it is 32 lanes on those units per Die. When they designed AM4 they wanted to stop having split platforms for the APU's. To keep the pin count down and probably to avoid moving to LGA on the consumer sockets they didn't connect a bunch of the PCIe lanes. Speculating that there was any need to improve the connectivity has no foundation, because the decision not to include them had nothing to do with yields.
So thank you for enlightening me as to the PCIe lane restriction. Do you have a source? (I always ask for sources, so don't take it personal, it is so that I can point to something other than a forum). But noted.
I don't think it will. Those are obviously numbers from the 4 and 8 channel memory and probably won't that great for IF as those stick particularly for EPYC aren't going to be clocked very high. The might be able to get more overall throughput by bundling all the connections. But Latency would not be impacted.I know the theoretical limit was related to HBM/2 performance, with no clear ceiling established, but the reason I brought it up is the 100Gbps of TR and 176Gbps of Epyc estimations on ram speed. If we see infinity fabric scale well with the ram at those rates, then it is as fast or faster than Intel's 100 omnipath, which is for the server board linking. That is more where my mind is, not that the CPU would get the full theoretical limit.
I am not against it, I think I only had to do it two or three times. But on the other hand I would rather straighten one then swap boards. Then again I would rather swap boards than swap CPU's do pins and what not. So I guess in a way I am indifferent. But I wouldn't be surprised if it was a compromise they made with the board guys. We will develop X amount of boards if you don't use LGA. Or more to the Point, we will help with the adoption of TR4 if you you use PGA on AM4.Agree, but wish AM4 was LGA anyway. I hate pins. I've straightened so many of them for older systems that I've had enough of that for a lifetime.
I know, the sticks are 2666 (unless exceeding spec). I'm thinking of supermicro doing a supero board like they are doing for the X299, but supporting the 8 and 16 core EPYC, if OC-able. I'm not as concerned about the latency as that speed would make the latency less of any consequence. But that is what I'm interested in finding out and hoping for (a man can still dream). Building a home server, so going to be TR or Epyc anyways...I don't think it will. Those are obviously numbers from the 4 and 8 channel memory and probably won't that great for IF as those stick particularly for EPYC aren't going to be clocked very high. The might be able to get more overall throughput by bundling all the connections. But Latency would not be impacted.
Trust me, straightening pins on PGA IS A LOT EASIER than fixing a bent pin on LGA. OI!Agree, but wish AM4 was LGA anyway. I hate pins. I've straightened so many of them for older systems that I've had enough of that for a lifetime.
No not yours in general but all IF latency issues in general. I agree it would be nice to see it in it's unbridled power. But that 512Gbps. Is at Vega's 512bit bus at much higher data rate do to using really fast HBM2 (which would also apply to mini vega's later using GDDR5X). But it goes back to recent other posts and farther back. It starts with someone realizing that sometimes Adia reports a L3 Latency of 120ms. Then someone tests and finds an 80ms increase in latency when going from CCX to CCX. All of a sudden it becomes "the problem" for gaiming. Then it becomes either A.) A crappy design decision B.) A bug in the design that AMD had to push forward and would clear up later. To maybe in the next stepping AMD can take care of the CCX latency bug and on and on. All with very little actual analytical to show that there is even that much of an impact. What was once an early theory became fact and ignores the actual issues like Nvidia's poor core scaling in DX12.
Trust me, straightening pins on PGA IS A LOT EASIER than fixing a bent pin on LGA. OI!
One time... a cat made me jump while I was sticking it in the socket and I hit one pin with the corner of the chip. Still simple enough fix, but that pin now bends slightly lower than the others, even though in the correct position now. Works fine, but man... Straightening a pin on PGA is straightforward.Probably - never have had to do that