For those that are interested, I've gathered some statistics about the high resolution timers. I've already described the test conditions, but here I'll give more information on our platform. MPC8349 (PPC32 @ 528MHz) 512MB DDR2 SDRAM 16GB NAND (x8) Some asked about the jitter distribution, and I've gathered some numbers. I ran this over 10000 samples. Baseline: Min = 3.821ms, Max = 3.951ms, Mean = 3.844ms, Variance = 88.5108 (deviation of about 9.4us) Loaded: Min = 3.833ms, Max = 4.234ms, Mean = 4.099ms, Variance = 1276.35 (deviation of about 35us) We see the mean go up and the variance increase. The large number of timers really do impact the performance of high priority tasks, and the jitter gets much worse. Further, I instrumented the timer_interrupt code to get a feeling for the burden on the interrupt and how often the interrupts happen. I read the timbase register (a 64-bit incrementer that increments once every ~15ns) at the start and end of the interrupt, and determine the maximum. I also measure how the time between the end of the timer interrupt and the start of the next timer interrupt. Baseline: max burden = 79.7us, minimum time between interrupts = 364ns, average time between interrupts 421us. Loaded: max burden = 92.7us, minimum time between interrupts = 24ns, average time between interrupts 180us As we see, the interrupt frequency spikes when loaded, and the time between interrupts drops significantly. The interrupt burden rises slightly, but given the fact we are interrupted quite frequently. Now, our modification to increase the minimum decrementer delta did improve the time between interrupts, but significantly increased the timer interrupt burden (from 92.7us to 462us). So, we either get lots of interrupts, averaging 93us per hit, or few interrupts, but 426us of burden. Either way, it averages out to too much. We are looking into ways to get away from nanosleep (or dramatically drop the number of nanosleep calls). To that end, we are considering a timer "server" type application. This application accepts timer requests, schedules the appropriate nanosleep (or select, poll, etc), then responds when the client needs to be awakened. Does anyone know of an existing project that does something similar to this? Perhaps somethings smaller than dbus, but with the same kind of operation. Thanks, Pete -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
