TR Forums

Flying Fox wrote:

Things like pro audio apps may be spending a lot of time waiting for the audio to come in. When waiting for I/O, the OS is basically idle so the CPU may choose to go to deeper sleep states (under the Balanced profile). You can't really have the app keep hogging the CPU just to keep it awake either, because that is just an ineffective use of CPU power (the reverse problem). In this case, the wakeup time just seems to be not fast enough for this particular use case, and the app would be forced to catch up, causing stutters.

If it's set to record, it's recording whatever is coming in on the inputs even if what's coming in is (near) silence.

In one of my previous posts I mentioned other reasons the CPU usage might be highly variable though. In a multi-track project with lots of instruments and effects plugins there's a lot going on and the load will vary as things switch in and out during mixing/playback.

Edit: FWIW I've played around a little bit with Rosegarden (DAW application for Linux), and yes there are potential issues with power management and high resolution system timer settings (HPET/TSC/ACPI) there too. In order to get smooth, glitch-free operation, things need to be "just so".

Flying Fox wrote:

Re: RTOS - is QNX considered a real one? That's another big name that came to mind.

Yeah, QNX is (or was) another one. They used to be a major player; IIRC Blackberry acquired them at some point. Have they managed to kill it yet?

Edit: Looks like QNX has a significant presence in automotive. I expect Blackberry will eventually sell them off, or perhaps even morph into a business where developing/supporting QNX is their primary business model (since they're obviously an also-ran in the smartphone market at this point).

VxWorks (now owned by Intel) is another big one.

I haven't read anything from reasonable people that states ryzen sucks for gaming. Quite the contrary. It is good for gaming. It is just not as good as kaby lake or broadwell (yeah I'm skipping over Skylake). It really reminds me a whole lot of a haswell 5960x with faster multithreaded performance closing in on bwe and at half the price. That is a great cpu, but also not as good price/performance for gaming. My friend has the 5960x and he used to swear it ran smoother than his old o/ced 2600k (more cores?). I think he was full of ****, but a couple of beers and a slice of pizza had me sitting there convinced I could feel it too.

Kaby lake has more absolute gaming performance and at a better price than ryzen. Maybe a little platform maturity and all these little optimizations with drivers bios and power profiles will reduce the 25% deficit to 15% over the next two months. ie133fps vs100 to 133fps vs112, IDK. Hell in some games it is faster but that's the outlier and most games it's at least 15% and as much as 35% slower. Its not a bad game cpu though, you can forget percentages and look at the actual data to see that or just compare it to haswell. And I have no comment on the ccx issues as I only barely internet understand it. I'm not a computer engineer. the performance is what it is until it isn't. 25% less gaming performance 50 to 90% more multithreaded performance than 7700k.

ultima_trev wrote:

just brew it! wrote:

I use Linux as my primary OS, so I am effectively a beta tester for Linux desktop environments. (At least I stick to Ubuntu LTS and Debian Stable now, so I'm not an alpha tester any more... )

Last time I used a Linux distro on a desktop was 2011 ish with Ubuntu / Fedora. Considering I couldn't get drivers for my WLAN (a 2008 Dell Inspiron) in Fedora and the fact that they recently switched from Metacity to Unity (which I hated with a fiery passion) I called it quits then and there.

Yeah but 2011 was eons ago. In my experience since then Wi-Fi is *MUCH* more reliable on Linux than windows. (I agree though Unity sucks).

just brew it! wrote:

Yeah, QNX is (or was) another one. They used to be a major player; IIRC Blackberry acquired them at some point. Have they managed to kill it yet?

Edit: Looks like QNX has a significant presence in automotive. I expect Blackberry will eventually sell them off, or perhaps even morph into a business where developing/supporting QNX is their primary business model (since they're obviously an also-ran in the smartphone market at this point).

VxWorks (now owned by Intel) is another big one.

x86 Supporting RTOS's that I can think of. The paid for ones are mega expensive, but there are some OSS ones:

Green Hills Integrity - http://www.ghs.com/products/rtos/integrity.html
Wind River (Intel) VxWorks - https://www.windriver.com/products/vxworks/
RTEMS - https://www.rtems.org/
QNX - http://www.qnx.com/content/qnx/en/produ ... index.html
FreeRTOS - http://www.freertos.org

Yeah FreeRTOS does appear to work with x86 in either Real Mode or Flat 32-bit protected mode.

srg86 wrote:

x86 Supporting RTOS's that I can think of. The paid for ones are mega expensive, but there are some OSS ones:

They all require certified platforms though, because otherwise their guarantees can be wrecked by things outside of their control on the hardware.

SMM is just one really good example of this problem.

As always, exactly as JBI said:

JBI wrote:

Windows and Linux both have real-time priority classes for threads/processes, but this is only a partial solution at best, since the overall environment is fundamentally not designed with real-time in mind.

*That sentence cannot be stressed enough in this context*, and it equally applies to any other OS that runs in the same environment. Yes, those OSs are probably even better on the software side, sure, but the solution still remains partial.

Glorious wrote:

srg86 wrote:

x86 Supporting RTOS's that I can think of. The paid for ones are mega expensive, but there are some OSS ones:

They all require certified platforms though, because otherwise their guarantees can be wrecked by things outside of their control on the hardware.

SMM is just one really good example of this problem.

As always, exactly as JBI said:

JBI wrote:

Windows and Linux both have real-time priority classes for threads/processes, but this is only a partial solution at best, since the overall environment is fundamentally not designed with real-time in mind.

*That sentence cannot be stressed enough in this context*, and it equally applies to any other OS that runs in the same environment. Yes, those OSs are probably even better on the software side, sure, but the solution still remains partial.

I never said a platform primarily designed to be a desktop or mobile PC is the best choice RTOS. That said, taking the SMM example, not all embedded PCs actually implement SMM, though most do....

I still say wait for the r5 (4c/8t) for gaming performance.

I would expect it to be able to rev to 4.5ghz to 5ghz.

That will give you the gaming performance people are looking for.

On the other hand people were worried the r7 would not even match sandybridge performance I'd say AMD did extremely well for version 1.0 of a brand new platform.
Compare their new chip to their their previous generation and its a huge improvement.

srg86 wrote:

I never said a platform primarily designed to be a desktop or mobile PC is the best choice RTOS. That said, taking the SMM example, not all embedded PCs actually implement SMM, though most do....

Sure, I'm just saying this isn't just a matter of the OS.

Glorious wrote:

srg86 wrote:

x86 Supporting RTOS's that I can think of. The paid for ones are mega expensive, but there are some OSS ones:

They all require certified platforms though, because otherwise their guarantees can be wrecked by things outside of their control on the hardware.

SMM is just one really good example of this problem.

As always, exactly as JBI said:

JBI wrote:

Windows and Linux both have real-time priority classes for threads/processes, but this is only a partial solution at best, since the overall environment is fundamentally not designed with real-time in mind.

*That sentence cannot be stressed enough in this context*, and it equally applies to any other OS that runs in the same environment. Yes, those OSs are probably even better on the software side, sure, but the solution still remains partial.

Glorious, I had a super-nasty problem with this once, in a work situation no less. I needed to increase the priority of a application worker thread... and I did, and it worked, solved the problem completely.

I now had a new problem - the Windows was so busy with the application that it couldn't do any I/O. Yeah, the app is working great but all the disks went offline... oops.

Aranarth wrote:

I still say wait for the r5 (4c/8t) for gaming performance.

I would expect it to be able to rev to 4.5ghz to 5ghz.

That will give you the gaming performance people are looking for.

On the other hand people were worried the r7 would not even match sandybridge performance I'd say AMD did extremely well for version 1.0 of a brand new platform.
Compare their new chip to their their previous generation and its a huge improvement.

I agree. In fact, a single-module RyZen won't have any of the weird cross-module cache issues (assuming that they are a thing), so performance might be a lot better than we'd expect just from the extra heat/power headroom.

I continue to believe that RyZen 2.0 will suck in comparison because the iGPU (assuming that it's implemented for Shock and Awe) will take a gigantic part of the CPU's heat/power budget. On the other hand the iGPU won't be effectively throttled by poor IPC.

Hopefully AMD will out-cache Intel with on-package HBM somewhere down the line, but that might simply be too expensive.

Vhalidictes wrote:

I continue to believe that RyZen 2.0 will suck in comparison because the iGPU (assuming that it's implemented for Shock and Awe) will take a gigantic part of the CPU's heat/power budget. On the other hand the iGPU won't be effectively throttled by poor IPC.

That's not really 2.0, the Zen+ arch is due later on (late 2018/19?) iirc.

Aranarth wrote:

I still say wait for the r5 (4c/8t) for gaming performance.

I would expect it to be able to rev to 4.5ghz to 5ghz.

That will give you the gaming performance people are looking for.

Unless we get a zen 1.1, or silicon revision, I would not expect any ghz headroom increase. I'd put money is on 4.1-4.2ghz max, because temp and power usage does not appear to be the issue, more of a silicon+design brick wall.

ColeLT1 wrote:

Unless we get a zen 1.1, or silicon revision, I would not expect any ghz headroom increase. I'd put money is on 4.1-4.2ghz max, because temp and power usage does not appear to be the issue, more of a silicon+design brick wall.

My expectation is headroom increase from having 1/2 the size of chip at 65 or 90 "watts" power budget (however AMD measures it).

If you have an r5 with Vega on board you may still not have a "hot clocker" but if you have just one CCX on chip and no graphics chip I would expect better cooling and more power to go around.

There are lots a theories about why chips do not over clock well from motherboards not providing stable enough power, bios firmware needing updates to fix memory controller bugs, a hard power limit set in microcode on the chip, or needing minor revisions of the chip to fix latency between different parts of the chip (inside a single ccx).

As I've said before just wait 6 months and see how AMD's new chips are doing. I would expect some serious headway.
I'm certainly not worried...

My next machine in a year or so will likely be an AMD r5 or r7 just for bang for buck.

Vhalidictes wrote:

Aranarth wrote:

I continue to believe that RyZen 2.0 will suck in comparison because the iGPU (assuming that it's implemented for Shock and Awe) will take a gigantic part of the CPU's heat/power budget. On the other hand the iGPU won't be effectively throttled by poor IPC.

The APUs are a separate product. The next cpu-only zen revision is called "Pinnacle Ridge", schedule for 2018. "Raven Ridge" is the APU product, where they're taking a Zen chip and replacing one of the CCX units with a Vega GPU (this means it will max out @ 4 cpu cores).

https://videocardz.com/67362/amd-pinnac ... zen2-cores

Demetri wrote:

Vhalidictes wrote:

Aranarth wrote:

I continue to believe that RyZen 2.0 will suck in comparison because the iGPU (assuming that it's implemented for Shock and Awe) will take a gigantic part of the CPU's heat/power budget. On the other hand the iGPU won't be effectively throttled by poor IPC.

The APUs are a separate product. The next cpu-only zen revision is called "Pinnacle Ridge", schedule for 2018. "Raven Ridge" is the APU product, where they're taking a Zen chip and replacing one of the CCX units with a Vega GPU (this means it will max out @ 4 cpu cores).

https://videocardz.com/67362/amd-pinnac ... zen2-cores

Awesome, that sounds like a neat product. Vega on-die though? Or just the CU's from it? We never did see anything like mid-grade GPU performance from a APU, discounting Crystalwell.

Aranarth wrote:

There are lots a theories about why chips do not over clock well from motherboards not providing stable enough power, bios firmware needing updates to fix memory controller bugs, a hard power limit set in microcode on the chip, or needing minor revisions of the chip to fix latency between different parts of the chip (inside a single ccx).

Check out the F/V curve here. It really looks like it's just the process, in which case dropping to 4C8T isn't going to be better for OCing unless you're willing to run insane voltages.

On the plus side, if the F/V curve really looks like that, AMD did their usual excessive factory OC thing *and their perf/watt is competitive anyway*. Also those on-die linear regulators are a wildcard. I'm now very curious to see how far the perf/watt can go in laptop and server applications.

I honestly do not get why people don't understand this. Maybe a lack of understanding or knowledge I suppose, but it's time to listen.

It's not your motherboard, it's not your power supply, it's not some microcode issue. Ryzen on that GF process is just not going to OC well no matter how many cores you put in the package. That is something the Ryzen "i hope the R5 OC's like CrAzY!!!!111!" crowd is just going to have to come to terms with.

R5 may provide some decent gaming performance for your buck, but if you are expecting to OC a 4C/8T Ryzen chip to 4.8GHz, you're kidding yourself. The only way that happens is if R5 (and R3) are being produced on a re-spin/revision of the GF process.

DancinJack wrote:

I honestly do not get why people don't understand this. Maybe a lack of understanding or knowledge I suppose, but it's time to listen.

It's not your motherboard, it's not your power supply, it's not some microcode issue. Ryzen on that GF process is just not going to OC well no matter how many cores you put in the package. That is something the Ryzen "i hope the R5 OC's like CrAzY!!!!111!" crowd is just going to have to come to terms with.

R5 may provide some decent gaming performance for your buck, but if you are expecting to OC a 4C/8T Ryzen chip to 4.8GHz, you're kidding yourself. The only way that happens is if R5 (and R3) are being produced on a re-spin/revision of the GF process.

Quoted for truth.

Vhalidictes wrote:

Glorious, I had a super-nasty problem with this once, in a work situation no less. I needed to increase the priority of a application worker thread... and I did, and it worked, solved the problem completely.

I now had a new problem - the Windows was so busy with the application that it couldn't do any I/O. Yeah, the app is working great but all the disks went offline... oops.

Aranarth wrote:

I still say wait for the r5 (4c/8t) for gaming performance.

I would expect it to be able to rev to 4.5ghz to 5ghz.

It seems that the R5 quads are going to be the same 8 core die in a 2+2 configuration so I doubt it will perform any better regarding overclocking or CCX to CCX communication.

MileageMayVary wrote:

It seems that the R5 quads are going to be the same 8 core die in a 2+2 configuration so I doubt it will perform any better regarding overclocking or CCX to CCX communication.

Knowing AMD I'd believe that. They're probably die harvesting or something. They'd save a ton of money by making 4+0 dies though, the CPU die would be roughly half the size.

Vhalidictes wrote:

MileageMayVary wrote:

It seems that the R5 quads are going to be the same 8 core die in a 2+2 configuration so I doubt it will perform any better regarding overclocking or CCX to CCX communication.

Knowing AMD I'd believe that. They're probably die harvesting or something. They'd save a ton of money by making 4+0 dies though, the CPU die would be roughly half the size.

source: http://www.anandtech.com/show/11202/amd ... april-11th
"We have confirmation from AMD that there are no silly games going to be played with Ryzen 5. The six-core parts will be a strict 3+3 combination, while the four-core parts will use 2+2. This will be true across all CPUs, ensuring a consistent performance throughout."

I hate the idea that they might be hacking good chips to sell at a lower price point but I also don't want them to be having poor yields either.

Let me put it this way. There is no good technical reason I'm aware of to not make a 4+0 die. It would yield better, have more cores per wafer (less cost!), and not have any strange cross-module cache issues.

The only reasons I can think of to intentionally do this are 1) Die harvesting and/or crappy yields, and 2) Some kind of Fab limitation and/or massive production agreement.

I do think that 3+3 is probably fine, though, depending on the above... although again 4+2 might allow for additional die harvesting.

Vhalidictes wrote:

Let me put it this way. There is no good technical reason I'm aware of to not make a 4+0 die. It would yield better, have more cores per wafer (less cost!), and not have any strange cross-module cache issues.

The only reasons I can think of to intentionally do this are 1) Die harvesting and/or crappy yields, and 2) Some kind of Fab limitation and/or massive production agreement.

I do think that 3+3 is probably fine, though, depending on the above... although again 4+2 might allow for additional die harvesting.

For a simple quad core, yes, fabbing a smaller die with only one CCX would be much cheaper. For the six cores, doing them all one way makes sense. There could be scenarios where 4+2 and 3+3 might act slightly differently with communications over the fabric and also asymmetric L3 on a 4+2.

PCPer noted an issue with Ryzen yesterday and speculated power delivery was at fault. AMD says a fix is on the way.

Perhaps there are more power delivery gremlins which the high performance plan 'resolves'.

puppetworx wrote:

PCPer noted an issue with Ryzen yesterday and speculated power delivery was at fault. AMD says a fix is on the way.

Perhaps there are more power delivery gremlins which the high performance plan 'resolves'.

Micro-delays in powering up/down parts of the CPU would make for crummy minimum frame times, but that doesn't appear to be one of RyZen's major problems.

I'm sure it will help though. The "big issue" with RyZen is probably made up of a ton of tiny problems.

MileageMayVary wrote:

Vhalidictes wrote:

Let me put it this way. There is no good technical reason I'm aware of to not make a 4+0 die. It would yield better, have more cores per wafer (less cost!), and not have any strange cross-module cache issues.

The only reasons I can think of to intentionally do this are 1) Die harvesting and/or crappy yields, and 2) Some kind of Fab limitation and/or massive production agreement.

I do think that 3+3 is probably fine, though, depending on the above... although again 4+2 might allow for additional die harvesting.

For a simple quad core, yes, fabbing a smaller die with only one CCX would be much cheaper. For the six cores, doing them all one way makes sense. There could be scenarios where 4+2 and 3+3 might act slightly differently with communications over the fabric and also asymmetric L3 on a 4+2.

Would the Cache thing matter though? My impression is that removing a core doesn't decrease the Cache size(?)

I was really hoping that r5 would be a single ccx not two 1/2 ccx's (2x2) put together.
This was why I was saying that I expect r5's to clock better than 3x3 or 4x4.

I guess we will just have to wait and see what actually ships.
Pricing is right about where it should be though.

(Note: when quoting people make sure you get the quotes right. I rarely ever use the words "shock and awe"... )

Vhalidictes wrote:

Would the Cache thing matter though? My impression is that removing a core doesn't decrease the Cache size(?)

Each CCX is 4 cores connected to 8MB of L3. A core on one side would have to go thru the fabic to talk to L3 on the other side so a 4+2 would have 4 cores with 8MB local and 2 cores with 8MB local.
http://www.anandtech.com/show/11170/the ... and-1700/9

PCPer showed the latency in switching threads between logical cores on the same physical core takes 26ns. Switching between physical cores in the same CCX takes 42ns. Switching between CCXs takes 140ns.
https://www.pcper.com/reviews/Processor ... ver-Bullet

Aranarth wrote:

I was really hoping that r5 would be a single ccx not two 1/2 ccx's (2x2) put together.
This was why I was saying that I expect r5's to clock better than 3x3 or 4x4.

I guess we will just have to wait and see what actually ships.
Pricing is right about where it should be though.

Even if they did have only one CCX, they weren't going to clock much, if any, better than the 8 core parts! You guys keep saying this stuff as if it's all about the TDP and we're butting up against a thermal headroom wall. That's not it. The default voltage for these parts is ~1.36 IIRC. You're just not going to get much headroom out of a chip that starts that high.

Otherwise I agree with you. Need to wait and see what happens. I do think pricing is right on though. I don't think these R5's are going to be amazing gaming chips though. Maybe i'm on my own there.

MileageMayVary wrote:

Vhalidictes wrote:

Would the Cache thing matter though? My impression is that removing a core doesn't decrease the Cache size(?)

Each CCX is 4 cores connected to 8MB of L3. A core on one side would have to go thru the fabic to talk to L3 on the other side so a 4+2 would have 4 cores with 8MB local and 2 cores with 8MB local.
http://www.anandtech.com/show/11170/the ... and-1700/9

PCPer showed the latency in switching threads between logical cores on the same physical core takes 26ns. Switching between physical cores in the same CCX takes 42ns. Switching between CCXs takes 140ns.
https://www.pcper.com/reviews/Processor ... ver-Bullet

The descriptions/diagrams I've seen of the architecture indicate that the 8MB L3 per CCX is in 4 2MB chunks, with lowest latency being to the core "closest" to it.