Processor Utilization - VxWorks

This is a discussion on Processor Utilization - VxWorks ; I've been tasked with determining the processor utilization of one of our applications. We have had no luck getting profile scope on our architecture. In the past, we've added an idle task with a low priority and then measure how ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Processor Utilization

  1. Processor Utilization

    I've been tasked with determining the processor utilization of one of
    our applications. We have had no luck getting profile scope on our
    architecture. In the past, we've added an idle task with a low
    priority and then measure how long it runs in relation to the normal
    tasks to get a rough estimate. However, all of the tasks for this
    particular application are structured in such a way that they are
    constantly polling on queues. For example, when a task gets the
    processor, it will first check to see if an event is in a queue. If
    there is an event, it will peform some work. Otherwise, it will just
    release the processor and another similar task will get it and follow
    the same logic flow. Basically, there is never a time where a task
    isn't ready to run, which means that the idle task approach doesn't
    work. I've been directed to just perform a manual analysis to come up
    with an estimate. However, I feel that the application is running at
    100% utilization (excluding the time spent in kernel mode for context
    switching) since something is always ready to run. Am I off base?


  2. Re: Processor Utilization

    Mears wrote:

    >I've been tasked with determining the processor utilization of one of
    >our applications. We have had no luck getting profile scope on our
    >architecture. In the past, we've added an idle task with a low
    >priority and then measure how long it runs in relation to the normal
    >tasks to get a rough estimate. However, all of the tasks for this
    >particular application are structured in such a way that they are
    >constantly polling on queues. For example, when a task gets the
    >processor, it will first check to see if an event is in a queue. If
    >there is an event, it will peform some work. Otherwise, it will just
    >release the processor and another similar task will get it and follow
    >the same logic flow. Basically, there is never a time where a task
    >isn't ready to run, which means that the idle task approach doesn't
    >work. I've been directed to just perform a manual analysis to come up
    >with an estimate. However, I feel that the application is running at
    >100% utilization (excluding the time spent in kernel mode for context
    >switching) since something is always ready to run. Am I off base?


    I suppose that this is one of those how-you-chose-to-define-it sort of
    things. Sure, strictly speaking, your design never goes idle and
    therefore is utilizing 100% of the CPU. There is obviously some amount
    of available processing bandwidth, though, because the system would
    otherwise fail in some way once one of your tasks finds data in its queue.
    It seems, then, that you need to find a new way to define utilization.

    I cannot help asking why this system is implemented in this way. What
    design goal does it help achieve or problem does it solve? Unless there
    are good answers to these questions it seems that the design is, at
    best, non-deterministic and, at worst, might easily fail to meet its
    deadlines.

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at hotmail dot com | - The Who, Bargain

  3. Re: Processor Utilization

    Mears wrote:
    > I've been tasked with determining the processor utilization of one of
    > our applications. We have had no luck getting profile scope on our
    > architecture. In the past, we've added an idle task with a low
    > priority and then measure how long it runs in relation to the normal
    > tasks to get a rough estimate. However, all of the tasks for this
    > particular application are structured in such a way that they are
    > constantly polling on queues. For example, when a task gets the
    > processor, it will first check to see if an event is in a queue. If
    > there is an event, it will peform some work. Otherwise, it will just
    > release the processor and another similar task will get it and follow
    > the same logic flow. Basically, there is never a time where a task
    > isn't ready to run, which means that the idle task approach doesn't
    > work. I've been directed to just perform a manual analysis to come up
    > with an estimate. However, I feel that the application is running at
    > 100% utilization (excluding the time spent in kernel mode for context
    > switching) since something is always ready to run. Am I off base?
    >


    Your processor utilization is indeed 100% and the design sounds like a
    mess. Having said that, someone is paying you and wants an answer other
    than 100% so the question becomes is it possible to provide an answer
    other than 100% that is meaningful with some qualifiers and which is not
    fundamentally dishonest. I suppose the answer is maybe.

    You could attempt to approach this from the opposite of the typical
    direction by making a high priority anti-idle task that busy waits and
    gives up the processor for short period of times (probably using an
    interrupt timer or something since the taskDelay approach might be too
    coarse).

    If it is possible to analyze the system and see the queue's filling up
    you could find out at what fraction of utilization by the high priority
    anti-idle task does the rest of the system start to break. Your actual
    utilization could then be thought of as 1.0 -
    Max_Utilization_Of_Anti_Idle_Task.

    Having said that, I can't help but think that changing the queues to
    message queues that block would not be an easier way to do the analysis
    but of course I don't have the code to see what all of the special cases
    are.

+ Reply to Thread