Question:
I?m trying to measure processor utilization of an application relying simply on the output rate of packets. I injected a high priority task and I am going to control the amount of time it gets the processor.
My idea is to measure the output rate of the application without the injected task and then compare it to output rates from runs where the injected task is running. The problem is that the output rate can vary a fair amount from run to run. What I was thinking is that for my ?control? case, I would run several times and then take the average and standard deviation. Then I would start doing ?experiment? runs with the injected task. Due to the aforementioned variations in output rate, I would probably do multiple runs at each stage here as well.
To figure out processor utilization, I was thinking I could then take my control average and start looking at the average output rates from the runs with the injected task. The set of experiment runs where the average output rate exceeded either X standard deviations or a fixed percentage of the control output rate would be defined as the point where the processor became saturated. I would then use the fraction of the processor the control task had to determine how much the rest of the application was using when the processor became fully utilized.
I guess my question is, is that a decent approach? Basically, I?m adding a variable to the system and want to define when it starts noticeably affecting the application. Is there a more common way to do this?
Background:
I?m working on an embedded application and we don?t have any good way to measure processor utilization. However, it is something that I?m being forced to work on. The application was poorly designed and all of the tasks poll event buffers. Therefore, the application is really always running at 100% utilization. However, I?m hoping to identify the headroom the application has by injecting an anti-idle task and monitoring its effects on output rate.
I?m trying to measure processor utilization of an application relying simply on the output rate of packets. I injected a high priority task and I am going to control the amount of time it gets the processor.
My idea is to measure the output rate of the application without the injected task and then compare it to output rates from runs where the injected task is running. The problem is that the output rate can vary a fair amount from run to run. What I was thinking is that for my ?control? case, I would run several times and then take the average and standard deviation. Then I would start doing ?experiment? runs with the injected task. Due to the aforementioned variations in output rate, I would probably do multiple runs at each stage here as well.
To figure out processor utilization, I was thinking I could then take my control average and start looking at the average output rates from the runs with the injected task. The set of experiment runs where the average output rate exceeded either X standard deviations or a fixed percentage of the control output rate would be defined as the point where the processor became saturated. I would then use the fraction of the processor the control task had to determine how much the rest of the application was using when the processor became fully utilized.
I guess my question is, is that a decent approach? Basically, I?m adding a variable to the system and want to define when it starts noticeably affecting the application. Is there a more common way to do this?
Background:
I?m working on an embedded application and we don?t have any good way to measure processor utilization. However, it is something that I?m being forced to work on. The application was poorly designed and all of the tasks poll event buffers. Therefore, the application is really always running at 100% utilization. However, I?m hoping to identify the headroom the application has by injecting an anti-idle task and monitoring its effects on output rate.
Facebook
Twitter