Tweet
Hi,
Yes, your assumption is absolutely correct.
Thanks for your detailed explaination of differences. There are a lot of knowlodge. I am also learning a lot when I see your message.
Cheers.
Yes, your assumption is absolutely correct.
Thanks for your detailed explaination of differences. There are a lot of knowlodge. I am also learning a lot when I see your message.
Cheers.
Originally posted by Acigan
View Post
I can explain some of the differences in reported values. You can see them in action if you fire up TaskMgr.exe, MS Performance Monitor MMC plugin, and the ioBit Performance Monitor, MONITOR.exe. If you place all three side by side and just watch the CPU usage values for example, there will be differences at times. Heres the reasons for them:
Both Task Manager, and MS Performance Monitor MMC plugin are native Microsoft applications. In being that, one would expect they would show the same values as they execute but that is not the case. Within the box may be a single core, dual cores or quad cores of the actual processor. When more then one core is involved, the gathered information will be fetched a CPU core at a time and then averaged. To us humans, the processes appear to be running all at the same time but in the reality of the nano and pico-seconds, tasks are being threaded one by one into the cores. So in our three monitor tasks running example, there is a first, a second and a third task waiting in line. Sometimes, depending on the number of cores like a quad core CPU, all three end up in 3 of the 4 cores at the same time, each looking at the other cores and evaluating what they are processing at the moment, and NOT always including themselves in the evaluations. So MMC.exe in core 0 sees core 1, 2 and 3 and evaluates values, MONITOR.exe in core 1 sees core 0, 2 and 3 and evaluates its results and TaskMgr.exe running in core 2 sees core 0, 1 and 3 and evaluates its results.
Since the three apps in question are written differently and even different code-token sizes being executed withing the cores, they all three evaluate different results even within the same CPU clock tick cycle. Even differences of if the EXE module is compiled using x32 or x64 token sizes makes a difference. An x32 app running on a x64 core will bring in 2x the tokens per tick then the larger x64 based code token produced by the compilers when the EXE is created.
Now keep in mind that ioBit apps run on both x32 and x64 based processors and the logic is more then likely x32 bit for both. (am I correct in that assumption, ioBit?) because we dont click seperate links for x32 and x64 when we bring the logic to our boxes. So now there is a new factor in the differences mix..... x32 code running on x64 cores. On an x64 OS, Microsoft has optimized their native applications for the x64 bit cores and MMC.exe and TaskMgr.exe can be different then their x32 counterpart EXE files. So on x64 boxes, run the MONITOR.exe (x32) and it produces some slight differences in results because it is either processing x2 faster as two blocks of code are moved to and from cpu for execution, or its running x2 slower then the x64 MMC.exe and TaskMgr.exe, because of extra paging needing to be performed to bring in code into the CPUs.
There is also the factor of the Software Development Kit (SDK) overhead of MONITOR.exe verses native MMC.exe and TaskMgr.exe that is written native for the operating system and may not even go thru the logic bloat layers of the SDK. So again, MMC and TaskMgr would evaluate faster results then MONITOR.
Now we get to the MMC plug in verses native code of TaskMgr verses SDK layer of MONITOR. The MMC.exe version of Performance Monitor is a plug in to MMC.exe and not a fully compiled App. This means that it also has an extra layer of cycles and processing deep in the cores to fetch the logic compiled in the DLL files of the Plugin. MMC.exe is the basic general logic all the plugins use. Each plugin has its own unique logic in the plugin logic that is not common to any other plugin. So MMC.exe has some extra logic cycles to fetch and execute the code-blocks from the DLLs that other performance monitor apps would not have. This shows up in the other apps as MMC.exe using more CPU cycles then the others, just to show the same results.
All these factors and even more not explained here are why monitoring is always averaged. If you want more exact monitoring, use MMC and set up monitors on each of the CPU cores individually and dont use the ioBit MONITOR.exe at all. Its a high level monitor geared to general users and not exacting techie types that examine every cpu cycle tick. It even averages the CPUs on multi-core machines to present a single value in the panel. Its used to show a generalized usage and reporting values. If something doesnt look kosher then, fire up MMC or TaskMgr and examine in more detail.
As Cicely said above in general terms, some differences are normal. I hope Ive explained some of the reasons for the normalities in further detail. There are many many more subtle things that are also occurring within the CPUs and I only touched on but a few that can produce slight variations in results.
With all that being said, the ioBit modules are not reporting incorrect results, they are just reporting the results from a timeslice that is nano or pico seconds ahead or behind other monitor applications also running at the same time. Same time to us humans, Hours, Minutes, Seconds, are lifetimes to the CPUs in their time scales. They are not processing things at the same time, they are processing them in a defined timely order, defined by oscillating clocks in the mega and gigahertz range ..... in other words.... single file into one or more cores on the processor chip, all timed and orderly...., just very very fast to us.
Think of it as Cars at a traffic intersection. the light turns green and x number of cars go thru, some faster or slower then the green light before or even the one to follow. But if you sit and count them over say a time cycle of a hour, then sum up the number of cars per hour, and divide by 24 hours, ..... you will have that average number of cars (logic block tokens) flowing thru the intersections (the cores). Do that for a month and produce the results for review. Thats what monitor applications are actually doing.....very very very fast. So there will be differences between apps that do that since they dont always even include their own logic blocks executing in every pass. Doing so skews the results. But the others saw the blocks and skewed their own values by not including their own blocks of code. They cant, they evaluate a logic block of their own if that block is the the one that does the evaluations. Its not in core yet to execute the results.
See how freaky it is inside the cores? Now you know why Developers are freaky kinds of people.
I hope Ive explained things and given you things to ponder on or to further understand the box thats before you in how it performs the tasks you ask of it.
Both Task Manager, and MS Performance Monitor MMC plugin are native Microsoft applications. In being that, one would expect they would show the same values as they execute but that is not the case. Within the box may be a single core, dual cores or quad cores of the actual processor. When more then one core is involved, the gathered information will be fetched a CPU core at a time and then averaged. To us humans, the processes appear to be running all at the same time but in the reality of the nano and pico-seconds, tasks are being threaded one by one into the cores. So in our three monitor tasks running example, there is a first, a second and a third task waiting in line. Sometimes, depending on the number of cores like a quad core CPU, all three end up in 3 of the 4 cores at the same time, each looking at the other cores and evaluating what they are processing at the moment, and NOT always including themselves in the evaluations. So MMC.exe in core 0 sees core 1, 2 and 3 and evaluates values, MONITOR.exe in core 1 sees core 0, 2 and 3 and evaluates its results and TaskMgr.exe running in core 2 sees core 0, 1 and 3 and evaluates its results.
Since the three apps in question are written differently and even different code-token sizes being executed withing the cores, they all three evaluate different results even within the same CPU clock tick cycle. Even differences of if the EXE module is compiled using x32 or x64 token sizes makes a difference. An x32 app running on a x64 core will bring in 2x the tokens per tick then the larger x64 based code token produced by the compilers when the EXE is created.
Now keep in mind that ioBit apps run on both x32 and x64 based processors and the logic is more then likely x32 bit for both. (am I correct in that assumption, ioBit?) because we dont click seperate links for x32 and x64 when we bring the logic to our boxes. So now there is a new factor in the differences mix..... x32 code running on x64 cores. On an x64 OS, Microsoft has optimized their native applications for the x64 bit cores and MMC.exe and TaskMgr.exe can be different then their x32 counterpart EXE files. So on x64 boxes, run the MONITOR.exe (x32) and it produces some slight differences in results because it is either processing x2 faster as two blocks of code are moved to and from cpu for execution, or its running x2 slower then the x64 MMC.exe and TaskMgr.exe, because of extra paging needing to be performed to bring in code into the CPUs.
There is also the factor of the Software Development Kit (SDK) overhead of MONITOR.exe verses native MMC.exe and TaskMgr.exe that is written native for the operating system and may not even go thru the logic bloat layers of the SDK. So again, MMC and TaskMgr would evaluate faster results then MONITOR.
Now we get to the MMC plug in verses native code of TaskMgr verses SDK layer of MONITOR. The MMC.exe version of Performance Monitor is a plug in to MMC.exe and not a fully compiled App. This means that it also has an extra layer of cycles and processing deep in the cores to fetch the logic compiled in the DLL files of the Plugin. MMC.exe is the basic general logic all the plugins use. Each plugin has its own unique logic in the plugin logic that is not common to any other plugin. So MMC.exe has some extra logic cycles to fetch and execute the code-blocks from the DLLs that other performance monitor apps would not have. This shows up in the other apps as MMC.exe using more CPU cycles then the others, just to show the same results.
All these factors and even more not explained here are why monitoring is always averaged. If you want more exact monitoring, use MMC and set up monitors on each of the CPU cores individually and dont use the ioBit MONITOR.exe at all. Its a high level monitor geared to general users and not exacting techie types that examine every cpu cycle tick. It even averages the CPUs on multi-core machines to present a single value in the panel. Its used to show a generalized usage and reporting values. If something doesnt look kosher then, fire up MMC or TaskMgr and examine in more detail.
As Cicely said above in general terms, some differences are normal. I hope Ive explained some of the reasons for the normalities in further detail. There are many many more subtle things that are also occurring within the CPUs and I only touched on but a few that can produce slight variations in results.
With all that being said, the ioBit modules are not reporting incorrect results, they are just reporting the results from a timeslice that is nano or pico seconds ahead or behind other monitor applications also running at the same time. Same time to us humans, Hours, Minutes, Seconds, are lifetimes to the CPUs in their time scales. They are not processing things at the same time, they are processing them in a defined timely order, defined by oscillating clocks in the mega and gigahertz range ..... in other words.... single file into one or more cores on the processor chip, all timed and orderly...., just very very fast to us.
Think of it as Cars at a traffic intersection. the light turns green and x number of cars go thru, some faster or slower then the green light before or even the one to follow. But if you sit and count them over say a time cycle of a hour, then sum up the number of cars per hour, and divide by 24 hours, ..... you will have that average number of cars (logic block tokens) flowing thru the intersections (the cores). Do that for a month and produce the results for review. Thats what monitor applications are actually doing.....very very very fast. So there will be differences between apps that do that since they dont always even include their own logic blocks executing in every pass. Doing so skews the results. But the others saw the blocks and skewed their own values by not including their own blocks of code. They cant, they evaluate a logic block of their own if that block is the the one that does the evaluations. Its not in core yet to execute the results.
See how freaky it is inside the cores? Now you know why Developers are freaky kinds of people.
I hope Ive explained things and given you things to ponder on or to further understand the box thats before you in how it performs the tasks you ask of it.
Comment