Messages in this thread | | | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15 | From | Mark_H_Johnson@raytheon ... | Date | Mon, 13 Dec 2004 14:02:55 -0600 |
| |
A comparison of PREEMPT_RT (no tracing) to PREEMPT_DESKTOP (no tracing) to help answer previous requests.
Comparison of .32-20RT and .32-20PK results 20RT has PREEMPT_RT (all tracing disabled) 20PK has PREEMPT_DESKTOP and no threaded IRQ's (all tracing disabled) 2.4 has lowlat + preempt patches applied
within 100 usec CPU loop (%) Elapsed Time (sec) 2.4 Test RT PK RT PK | CPU Elapsed X 99.87 99.75 65 * 59 * | 97.20 70 top 99.35 99.97 31 * 30 * | 97.48 29 neto 96.94 98.65 113 * 135 * | 96.23 36 neti 97.05 98.59 119 * 140 * | 95.86 41 diskw 94.36 91.69 30 * 70 * | 77.64 29 diskc 93.85 98.88 98 * 151 * | 84.12 77 diskr 99.39 99.92 133 * 210 * | 90.66 86 total 589 795 | 368 [higher is better] [lower is better] * wide variation in audio duration + long stretch of audio duration "too fast"
With the two versions of -20, they are quite similar in the percentage of CPU loop duration within 100 usec of nominal.
Looking at ping response time: RT 0.134 / 0.208 / 1.502 / 0.075 msec PK 0.089 / 0.159 / 0.467 / 0.047 msec for min / average / max / mdev values. You can see that -20PK does much better than -20RT in this measure.
The maximum duration of the CPU loop (as measured by the application) is in the range of 1.42 msec to 2.57 compared to the nominal 1.16 msec duration for -20RT. The equivalent numbers for -20PK are 1.28 to 1.93 msec. Its a little odd that the big outlier for -20PK was during the X 11 stress test. Its chart was one of the smoothest (less variation) than the others.
I repeated the test without cpu_burn (non RT, nice) for the 20PK kernel as well. For -20PK, all the elapsed times were reduced [as I expected for both RT and PK] and with exception of the network tests, were roughly the same as the 2.4 results.
-20RT with cpu_burn 65 31 113 119 30 98 133 without cpu_burn 63 30 121 150 32 87 97 -20PK with cpu_burn 59 30 135 140 70 151 210 without cpu_burn 62 30 94 60 27 89 93
I reran the 2.4 tests and the network tests ran in 39 and 37 seconds respectively. I guess this shows we have something odd going on in the network stack under 2.6.
--Mark H Johnson <mailto:Mark_H_Johnson@raytheon.com>
- 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/
| |