Can anyone explain the System Usage Window?

[Darryl Ramm]

Originally Posted by dave911

A little knowledge is a dangerous thing.
I'm sure all the MS and Intel engineers and software developers will be flocking to DUC when they realize that the processor and system metrics they use to optimize their code and hardware are garbage because they have some limitations.

Developers who care about this stuff are often not just looking at the same tools most users look at. Starting with things like the tool I linked to from Intel, through to profiling tools that can give a much better view of what is going on with CPU burn. And if they do look at tools they hopefully know enough to understand the limitations. Lots of the stats thrown up from OS and performance tools have limitations, are confusing or just plain wrong. Memory usage, some disk performance stats, bandwidth etc. can get especially problematic. Good professional sysadmin type folks tend to pretty quickly work out what metrics are useful and what are not and/or just go read an internals book.

One of my old hiring questions for UNIX/systems developers is to run a full ps command and have them describe what it it *really* showing, how things are measured and what they mean. Mark Russinovich or David Solomon (can't remember which one) does an amusing talk on Windows Performance where he talks about many of the stats in Windows process explorer and similar tools, what they claim to show, and what they really show. (Mark provides the wonderful Sysinternals suite of tools for helping understand Windows systems and their performance. And it was fun to have him and David as early users of VMware Workstation when I was at VMware).

[dave911]

I'm saying Avid can and should take the raw system metrics and provide a useful system resources meter for PT users.
What combination of metrics that would be I don't know, something that reflects the near real-time response required for PT.
Should not be called a CPU meter.

[musicman691]

Originally Posted by Darryl Ramm

Developers who care about this stuff are often not just looking at the same tools most users look at. Starting with things like the tool I linked to from Intel, through to profiling tools that can give a much better view of what is going on with CPU burn. And if they do look at tools they hopefully know enough to understand the limitations. Lots of the stats thrown up from OS and performance tools have limitations, are confusing or just plain wrong. Memory usage, some disk performance stats, bandwidth etc. can get especially problematic. Good professional sysadmin type folks tend to pretty quickly work out what metrics are useful and what are not and/or just go read an internals book.

One of my old hiring questions for UNIX/systems developers is to run a full ps command and have them describe what it it *really* showing, how things are measured and what they mean. Mark Russinovich or David Solomon (can't remember which one) does an amusing talk on Windows Performance where he talks about many of the stats in Windows process explorer and similar tools, what they claim to show, and what they really show. (Mark provides the wonderful Sysinternals suite of tools for helping understand Windows systems and their performance. And it was fun to have him and David as early users of VMware Workstation when I was at VMware).

So are you and your 'experts' saying we shouldn't have cpu usage metering in applications? That it's worthless?

[musicman691]

Originally Posted by Darryl Ramm

Oh Jeez. This has been covered here before on DUC. But Hyperthreading for beginners...

Hyperthread logical cores don't actually exist. A logical core only gets to execute a software thread on a physical core when the other logical core sharing that physical core is idle, stalled on a memory access etc. So you don't have in the example anything actually like 8 physical cores. Four of those cores only get to run at all if the other cores are idle or not able to do work. So wanting/hoping to see all cores busy is a totally confused/false wish. The very best aggregate processor throughput would be to have 4 cores pegged, and never stalling. And CPU usage would show 50% on most tools showing usage on hyperthreading. But real cores stall a lot its good for hyperthreadign to be able to throw workload at the stalled beast. And how much in practice using hyperthreading can eek out of a system, depends on how inefficently it is otherwise running. Extremely code/algorithm/compiler optimization depended, extremely dependent on thread scheduling etc.

Even forgetting hyperthreading (although it can make some of these other things worse...), understanding CPU usage is complex, how schedulers work, effects of statistical sampling, inability to account all systems usage to user threads, confused or just incorrect ways some tools/OSes report things, etc. etc.

Intel has a nice summary of some of the issues around this at http://software.intel.com/en-us/arti...pu-utilization.

But if the pretty meters keep you entertained keep looking at them. They are useful in very few cases (e.g. handy in the past for flagging denormalization bugs). The only way to reliably know how many/what plugins can run is to do the experiment and try to run them. When they don't run the CPU meter might give some useful clues, but often does not.

Just because you don't find them useful doesn't mean you have to put down those that do find them useful. And I do know how hyperthreading works so I don't need some 101 level course on it.

[Darryl Ramm]

Originally Posted by musicman691

Just because you don't find them useful doesn't mean you have to put down those that do find them useful. And I do know how hyperthreading works so I don't need some 101 level course on it.

I am not "putting down" anybody who want to look at the process meters. I am trying to point out that a lot of people seem to waste a lot of time looking at these things and they often don't help. And I've tried to explain why. If you disagree with any of those reasons can you just explain/correct them. And I've already suggested maybe you'd like to contribute something in this thread that would actually help the original poster understand what is going on with their CPU usage report.

A few threads ago you asked me to explain hyperthreading, so I did. Its hard to judge from you posts what you know or don't.

[Darryl Ramm]

Originally Posted by musicman691

So are you and your 'experts' saying we shouldn't have cpu usage metering in applications? That it's worthless?

No not at all. I'd like to see

1. An Avid white paper or similar on what all the resource meters means/how to use it/limitations.
2. Different display layout that tried to deconfuse hyperhteading/virtual core usage
3. Better per-plugin statistics.
4. Better transient capture and display if possible. (hard and I'm not even sure it could ever be made useful).

[musicman691]

Originally Posted by Darryl Ramm

I am not "putting down" anybody who want to look at the process meters. I am trying to point out that a lot of people seem to waste a lot of time looking at these things and they often don't help. And I've tried to explain why. If you disagree with any of those reasons can you just explain/correct them. And I've already suggested maybe you'd like to contribute something in this thread that would actually help the original poster understand what is going on with their CPU usage report.

A few threads ago you asked me to explain hyperthreading, so I did. Its hard to judge from you posts what you know or don't.

I never asked you to explain hyperthreading; you alluded to the 'magic' that hyperthreading supposedly does to process meters - that's what I asked about. Whatever - you're the one with all the knowledge and we're just plebes.

[Ben Jenssen]

Originally Posted by Darryl Ramm

Oh Jeez. This has been covered here before on DUC. But Hyperthreading for beginners...

Originally Posted by Darryl Ramm

If you find metering highly useful, by all means dive in here and explain exactly what is going on.

Arrogance and sarcasm.
We don't need it.
Don't put off Jack. He's a great contributor here, like you.

[Dizzi45Z]

Sorry I was gone for a few days.

I mention that Synthogy Ivory could show different results on an HD system as opposed to a Vanilla system because the HD system does put the mixer on the HD cards which could free up some resources.

I'm not just staring at the system usage window all day long. I simply wanted to see how much PT 11 improved system performance and saw that the numbers didn't make mathematical sense and was wondering why.

I still would like to see a more accurate system usage window incorporated into PT 11. I wanted to see if others were seeing the same weirdness as I was and it sounds like they are.

[Darryl Ramm]

That's true, but the mixer seems pretty benign. And the usage is just low, e.g.on a 96kHz session, playing back 50 plus tracks and a half dozen aux sends, burns only a few percent of a single core. (oh God I actually looked at the CPU meters )

I did look at the Ivory web site, looks like a nice VI.