Máte pravdu, že neočekáváte, že se časovače spustí dříve – a také ne. zdánlivý předčasné spuštění je způsobeno tím, že neměříte čas od vypršení předchozího časovače – měříte čas od předchozího gettimeofday() volání. Pokud mezi vypršením časovače a skutečným naplánováním procesu došlo ke zpoždění, zobrazí se toto gettimeofday() běží pozdě, a další běží dříve o stejnou částku .
Namísto protokolování rozdílu mezi následujícími gettimeofday() volání, zkuste zaznamenat vrácené absolutní časy a poté vrácené časy porovnejte s N * 100 ms po počátečním čase.
Pokud chcete PREEMPT_RT abychom vám pomohli, budete muset pro svůj testovací program nastavit zásady plánovače v reálném čase (SCHED_FIFO nebo SCHED_RR ), který vyžaduje root.
Udělal jsem nějaké změny ve vašem kódu a hlavně nahradil timer a spusťte proces jako postup RT (SCHED_FIFO).
setitimer() -> timer_create()/timer_settime()
gettimeofday() -> clock_gettime()
můj testbed je i9-9900k CPU a PREEMPT-RT patched Linux s jádrem 5.0.21. Časový interval časovače je 1 ms a program běží přibližně 10 hodin, aby se vygeneroval následující výsledek.
Také spouštím Cyclictest (na základě nanosleep() ) na mém počítači a vykazuje lepší kontrolu latence (maximální latence menší než 15us). Takže podle mého názoru, pokud si chcete sami realizovat časovač s vysokým rozlišením, může být užitečné samostatné RT vlákno běžící nanosleep na izolovaném jádře. Jsem v RT systému nový, komentáře vítám.