The goal of this set of plugin components is to provide a mechanism for measuring
the CPU consumed not just by a single thread, but also the CPU which it is causing
to be consumed by other tasks, or presented another way the CPU consumed by servers
on behalf of clients.

The data recorded includes:
- Direct CPU Usage: 
  This is the amount of time that an element spends in the RUNNING state per processor.  
  It is expected to be exclusive per processor (in SMP systems) such that only one task
  can be RUNNING at a time per CPU.
  NOTE: It currently doesn't exclude time spent in interrupt handlers
  
- Indirect CPU Usage:
  This is the amount of time that a server element spends in the RUNNING state.  An element
  is considered a server element if an element (the client) is blocked waiting for a response
  from it. In a Neutrino system this would allow the server processing time to be accounted
  for in a typical send/receive/reply scenario.
  
Indirect CPU usage is calculated not only for direct blocked clients but also for nested
clients.  For example consider the following scenario:
  A sends to B
   B receives from A
   B sends to C
    C receives from B
    C replies to B
   B replies to A
  ...
In this case A, B, C would all have direct CPU usage results.  A would have indirect CPU usage 
associated with B.  Both A and B would have indirect CPU usage associated with C since C is 
performing processing on B's behalf, but B is working on A's behalf.

Caveates & Fringe Cases:

If a client was blocked on a server before the start of the event trace (ie the client started in a
REPLY/SEND blocked state) then the time spend in the server will not be billed back to the client. 
{Possible to determine with a pre-scan assuming that the REPLY occurs during the lifetime of the log}

If a client sends to a server and then the server replies to the client, but the reply originates
from a different thread than the one which received it initially, then the CPU time will be billed
to the thread which received the message originally. 
{Possible to determine if on-behalf-of generated event, might be better to bill to replying thread}

If you are tracing a sequence based on a time range then the initial starting state is going to
be determined as follows:
Threads initially in the RUNNING state will be billed from the start cycle.
Threads initially in the REPLY/SEND state will not have that section of server time billed.
{
It would be possible to relax this constraint if you were willing to pay the price of a full scan.
The first cut:
 - Do a full scan, but don't record the time, just all of the relationship information up to 
   the startcycle
 - When we pass or equal the start cycle
   - Mark all the running CPUs as starting at the start cycle
   - Mark the IPC clients for the running elements at the current start cycle
}

Future Development:

There are a number of questions you would like to have answered in the future:
- How much CPU time was incurred by a thread/process (for client & servers)
- How much CPU time was caused by other threads/processes (for servers)
- What messages caused the CPU time to be consumed (for clients & servers)
- How much time on average was spent processing particular messages (for clients and servers)

  














  
  
             