Tiene razón al no esperar que los temporizadores se activen antes de tiempo, y no es así. Lo aparente el disparo temprano se debe a que no está midiendo el tiempo desde que expiró el temporizador anterior; está midiendo el tiempo desde el gettimeofday() anterior llamar. Si hubo un retraso entre la expiración del temporizador y la programación del proceso, verá este gettimeofday() con retraso, y el siguiente con retraso por la misma cantidad .
En lugar de registrar la diferencia entre gettimeofday() posteriores llamadas, intente registrar los tiempos absolutos devueltos, luego compare los tiempos devueltos con N * 100 ms después del tiempo inicial.
Si quieres PREEMPT_RT Para ayudarlo, deberá establecer una política de programación en tiempo real para su programa de prueba (SCHED_FIFO o SCHED_RR ), que requiere root.
Hice algunos cambios en su código y principalmente reemplacé el timer de la siguiente manera y ejecute el proceso como un progreso RT (SCHED_FIFO).
setitimer() -> timer_create()/timer_settime()
gettimeofday() -> clock_gettime()
mi banco de pruebas es CPU i9-9900k y Linux parcheado PREEMPT-RT con kernel 5.0.21. El intervalo de tiempo del temporizador es de 1 ms y el programa se ejecuta alrededor de 10 horas para generar el siguiente resultado.
También ejecuto Cyclictest (basado en nanosleep() ) en mi máquina, y muestra un mejor control de latencia (latencia máxima inferior a 15us). Entonces, en mi opinión, si desea realizar un temporizador de alta resolución usted mismo, un subproceso RT independiente que ejecute nanosleep en un núcleo aislado puede ser útil. Soy nuevo en el sistema RT, los comentarios son bienvenidos.