I agree absolutely with HP. Indeed, for me the CPU time analysis is like looking at fuel consumption, i.e. CPU-cycle 
consumption. 
The question is: which process consumes how much of the CPU?
I find it pretty awkward that in a SMP system now the 'running' time of a process may significantly vary between test 
runs (of the identical test case), just because the threads are running more or less in parallel.
I strongly support HP's proposal (separate result for 'realtime execution duration' or at least a preference option 
which value the process summary should represent).
All other states show in process summary view the sum of the threads states. It is quite a violation of consistency to 
define a different summary function for the running state.

Daniel

>-----Ursprüngliche Nachricht-----
>Von: Hans-Peter Reichert [mailto:community-noreply@qnx.com] 
>Gesendet: Sonntag, 6. September 2009 09:29
>An: general-ide
>Betreff: SystemProfiler - Changed Statistics for SMP traces
>
>I want to start a discussion about the changed behaviour of 
>System Profiler Statistics on traces from SMP systems.
>Has anybody else realized that stats have changed?
>Let me show you a short example for how stats are now working:
>
>Example 1:
>Process A with Thread 1 and 2, running on two cores
>A(T1) running from second 0-2 on core 1
>A(T2) running from second 1-3 on core 2
>If you select Process A you get a running time of 3s(!) 
>whereas when you select T1 and T2 you get 4s of running time.
>
>Let me change example 1 a bit:
>A(T1) running from second 0-2 on core 1
>A(T2) running from second 2-4 on core 2
>Now, when you select Process A you get 4s of running time, the 
>same as you will get when you select T1 and T2.
>
>The behaviour of stats when selecting the process line has 
>changed, in older versions it was just the same number as for 
>all threads of a process.
>So what do you think about this change?
>In my oppinion this is inconsistent.
>If you want something like this, you should add a new result 
>called something like "realtime execution"
>
>CPU time or running time is like fuel consumption of a car.
>1 Car driving 2 times from A to B will allways give you the 
>same amount of used fuel as when you have two cars driving 1 
>time from A to B. (1 core vs. 2 cores)
>
>The "General Stats" has been one of my favorites in starting 
>analysis of kernel traces.
>It will get horrible to use for me in future if this will keep 
>unchanged.
>If not the mentioned additional result line will be added, at 
>least this behaviour should be configurable through a 
>perfernces attribute.
>
>what do you think?
>/hp
>
>
>
>_______________________________________________
>
>General
>http://community.qnx.com/sf/go/post37436
>
> 
 
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad | 
Local Court Mannheim: Register No. 361395

 
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat 
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

+1 from me ... though the other values are interesting at times too ... 
I hate not having information.

Thomas

Hans-Peter Reichert wrote:
> I want to start a discussion about the changed behaviour of System Profiler Statistics on traces from SMP systems.
> Has anybody else realized that stats have changed?
> Let me show you a short example for how stats are now working:
>
> Example 1:
> Process A with Thread 1 and 2, running on two cores
> A(T1) running from second 0-2 on core 1
> A(T2) running from second 1-3 on core 2
> If you select Process A you get a running time of 3s(!)
> whereas when you select T1 and T2 you get 4s of running time.
>
> Let me change example 1 a bit:
> A(T1) running from second 0-2 on core 1
> A(T2) running from second 2-4 on core 2
> Now, when you select Process A you get 4s of running time,
> the same as you will get when you select T1 and T2.
>
> The behaviour of stats when selecting the process line has changed,
> in older versions it was just the same number as for all threads of a process.
> So what do you think about this change?
> In my oppinion this is inconsistent.
> If you want something like this, you should add a new result called something like "realtime execution"
>
> CPU time or running time is like fuel consumption of a car.
> 1 Car driving 2 times from A to B will allways give you the same amount of used fuel as
> when you have two cars driving 1 time from A to B. (1 core vs. 2 cores)
>
> The "General Stats" has been one of my favorites in starting analysis of kernel traces.
> It will get horrible to use for me in future if this will keep unchanged.
> If not the mentioned additional result line will be added, at least this behaviour should be configurable
> through a perfernces attribute.
>
> what do you think?
> /hp
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post37436
>
>