Messages in this thread | | | From | Mark_H_Johnson@raytheon ... | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 | Date | Wed, 10 Nov 2004 11:31:31 -0600 |
| |
>I may do a variant on this anyway. I think its important to see if >the symptom (> 100 usec CPU delay) is really: >- lots of short delays >OR >- relatively few long delays >and I have an idea of how to code that up and add to latencytrace.
A follow up on this message. My first test completed with the following results. The new code indicates:
X - Min delay was 0. Max delay was 3. Ave delay was 0.015295. top - Min delay was 0. Max delay was 23. Ave delay was 0.025659. netO - Min delay was 0. Max delay was 31. Ave delay was 1.169024. netI - Min delay was 1. Max delay was 35. Ave delay was 1.182864. diskW - Min delay was 0. Max delay was 18. Ave delay was 1.166944. diskC - Min delay was 0. Max delay was 18. Ave delay was 1.080036. diskR - Min delay was 0. Max delay was 7. Ave delay was 0.803804.
A "delay" was counted if 1000 iterations of the CPU inner loop took longer than 10 usec. For comparison, I moved this code to my 2.4 system and got the following results:
X - Min delay was 0. Max delay was 17. Ave delay was 1.277730. top - Min delay was 0. Max delay was 12. Ave delay was 1.452692. netO - Min delay was 0. Max delay was 12. Ave delay was 1.633742. netI - Min delay was 0. Max delay was 12. Ave delay was 1.626565. diskW - Min delay was 0. Max delay was 14. Ave delay was 1.566188. diskC - Min delay was 0. Max delay was 12. Ave delay was 1.701542. diskR - Min delay was 0. Max delay was 12. Ave delay was 1.650909.
Looks pretty comparable at this level. The 2.4 results appear to be more consistent.
Grr. The new code does have an impact on the application measurements under 2.4. It appears the TSC accesses are being delayed while the disk is active. The within 100 usec rate was only 77% (was 90%) but the peak is still pretty close (2.60 vs. 2.38 msec).
I am also not sure this is the "right" measurement either. I probably need to count the delays or divide the overall loop time by the number of delays to see if that is a more meaningful value.
--Mark
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |