AMD sucks at marketing and product placement. They should have made very clear since the beginning that all Ryzen R7 CPUs are competing against Intel's LGA2011 6-8 core CPUs while offering much better bang for buck. Instead they positioned 8-core low-clock Ryzen 1700 against 4-core high-clock i7 7700k due to price similarity and then lost in game benchmarks because of the lower clock rate.
Not priced it higher, no, but AMD should have marketed Ryzen R7 for pros instead of gamers, a workstation and media creation CPU with much better price/perf ratio than 5960x, 6800k and 6900k CPUs instead of talking too much about gaming.That was exactly what they did since December... And ur argument is that AMD should have priced the 1800 higher to make it looks better?
Last edited:
I disagree. It's obviously a very competent gaming CPU that clearly needs some work by AMD, MS, motherboard makers and game developers to truly make it competitive in that market. Unfortunately for many people, like me, who have older sandy/ivy systems who were looking to upgrade this year with choices from both sides, we're scratching our heads as what to do.
But alas we're barely 2 days into the release. Damn this hobby is cutthroat lol
The bandwidth also did not indicate the command capacity of the fabric. AMD previously used only one physical channel to handle all types of packets, but with an NoC it is possible that they split request and response packet into separate links, like how Intel does with their ring bus.
Moreover, it appears that at least Ryzen is capable of saturating the DDR memory bandwidth, though perhaps it is due to pipelining at work with probe issuing in parallel to the DRAM request.
Edit: IIRC The Stilt had posted his testing of Ryzen in AnandTech, indicating the fabric is running at twice the memory clock. AMD seemed to have implied before that the data fabric is capable of moving 32B/clk. So the theoretical bandwidth of the data path should be at least twice the data rate of the DRAM, assuming IMC itself is just one node. I am curious in how the "inter-core bandwidth" is tested in this case.
Last edited:
A short note on this: The implementation of the Northbridge splits the control flow (e.g. requests, response w/o data, probe broadcasts/response) and the data flow (e.g. dirty cache line data, DRAM data response) into separate paths. Here is how it looks like for anybody who was interested. Also 10.1109/MM.2007.43. The last chip the architecture being used had lasted perhaps more than a decade, and was used in Carrizo (page 81).
Last edited:
https://forums.anandtech.com/thread...and-discussion.2499879/page-128#post-38774366
I think this might explain a lot
I think this might explain a lot
It seems this is caused by AMD packed SMT threads into its ACPI CPU core ID, since the Linux kernel got a patch to fix the SMT topology for the exact same situation earlier. Why it did not push the driver patches earlier to be ready at launch is beyond me though.
hoom
Veteran
I think the guy at Reddit had it identified first https://forum.beyond3d.com/posts/1969190/
Coreinfo is the Sysinternals program but where does it poll: hardware, BIOS, driver, OS?
Did someone at AMD screw up?
Seems like a thing AMD should be setting up to respond how AMD want the processor to be recognised rather than MS needing to update something their side :neutral:
Coreinfo is the Sysinternals program but where does it poll: hardware, BIOS, driver, OS?
Did someone at AMD screw up?
Seems like a thing AMD should be setting up to respond how AMD want the processor to be recognised rather than MS needing to update something their side :neutral:
Yeah going to wait a bit longer. Everyone is bugging me as I promised my current hardware to my kids and their computer to my in-laws
Anarchist4000
Veteran
Phoronix tested with a patched kernel and compiler at least for apps. He still had the game issues. Multithreaded performance was solid in most apps, but still behind in games.
Scheduling will take a patch from MS and I'd imagine qualification takes some time.
One would imagine AMD has had final silicon for quite a few months. Unless MS refuse to work with anything that isn't publicly available hardware.
Anarchist4000
Veteran
That Linux kernel patch was February 5, so a mistake or slow driver process. Assuming windows and Linux on similar timetables, that's only a month from when it may have been submitted to Microsoft.
EDIT: 5th, not 2nd.
Last edited:
hoom
Veteran
Isn't the point of that cache/NUMA mapping stuff supposed to be to allow hardware providers to tell the scheduler how to handle their hardware without MS needing to write special code for each chip/config?
Maybe it doesn't work the way I'm thinking though *shrug*
Anarchist4000
Veteran
Should, but that seems to be the basis for the error with how they passed the information. They seem to report 16 logical cores which is worst case. Might be an ACPI reporting change that Windows missed. Hard to imagine they reported the topology incorrectly from the start, but it could be a holdover from Bulldozer.
If anyone is interested ryzen OC summited by users:
https://docs.google.com/spreadsheet...z5eAOcFK1olCvU-ww8N6e6D6424/edit#gid=27884076
https://docs.google.com/spreadsheet...z5eAOcFK1olCvU-ww8N6e6D6424/edit#gid=27884076
Similar threads
