High Resolution Timer aktivieren

[Felix]

Hallo,

ich habe ein Kernelmodul geschrieben, dass einen hochauflösenden Timer benötigt. Auf meinem Laptop funktioniert die ganze Sache absolut problemlos (selbstkompilierter 2.6.23 von SID, der insbesondere HR_TIMERS mit einkompiliert bekommen hat). Auf dem Produktivsystem funktionieren die High Resolution Timer leider nicht. Hier verwende ich einen selbstkompilierten 2.6.25er Kernel, ebenfalls aus dem SID Repository und mit die Timer betreffend gleichen Optionen. Es gibt keine Fehlermeldung, allerdings funktionieren die Timer deutlich ungenauer, leider eben auch viel zu ungenau. Hier der entsprechende Output von cat /proc/timer_list auf dem Entwicklungsrechner:

Code: Alles auswählen

Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
now at 25469434139815 nsecs

cpu: 0
 clock 0:
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     1214976840856921991 nsecs
active timers:
 clock 1:
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <e4d41ee8>, tick_sched_timer, S:01
 # expires at 25469436000000 nsecs [in 1860185 nsecs]
 #1: <e4d41ee8>, it_real_fn, S:01
 # expires at 25469451553408 nsecs [in 17413593 nsecs]
 #2: <e4d41ee8>, hrtimer_wakeup, S:01
 # expires at 25469464666244 nsecs [in 30526429 nsecs]
 #3: <e4d41ee8>, hrtimer_wakeup, S:01
 # expires at 25469470534777 nsecs [in 36394962 nsecs]
 #4: <e4d41ee8>, hrtimer_wakeup, S:01
 # expires at 25470746745258 nsecs [in 1312605443 nsecs]
 #5: <e4d41ee8>, it_real_fn, S:01
 # expires at 25474594786498 nsecs [in 5160646683 nsecs]
 #6: <e4d41ee8>, it_real_fn, S:01
 # expires at 25495680943972 nsecs [in 26246804157 nsecs]
 #7: <e4d41ee8>, hrtimer_wakeup, S:01
 # expires at 25500781027200 nsecs [in 31346887385 nsecs]
 #8: <e4d41ee8>, hrtimer_wakeup, S:01
 # expires at 28958707688459 nsecs [in 3489273548644 nsecs]
  .expires_next   : 25469436000000 nsecs
  .hres_active    : 1
  .nr_events      : 4786932
  .nohz_mode      : 2
  .idle_tick      : 25469424000000 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 6292355
  .idle_calls     : 5737157
  .idle_sleeps    : 3033715
  .idle_entrytime : 25469423503083 nsecs
  .idle_sleeptime : 15391797321745 nsecs
  .last_jiffies   : 6292355
  .next_jiffies   : 6292359
  .idle_expires   : 25469436000000 nsecs
jiffies: 6292358


Tick Device: mode:     1
Clock Event Device: <NULL>
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000


Tick Device: mode:     1
Clock Event Device: pit
 max_delta_ns:   27461866
 min_delta_ns:   12571
 mult:           5124677
 shift:          32
 mode:           3
 next_event:     25469436000000 nsecs
 set_next_event: pit_next_event
 set_mode:       init_pit_timer
 event_handler:  hrtimer_interrupt

Auf den ersten Blick bereits deutlich -> die Auflösung liegt bei 1nsec und der aktive Eventhandler ist hrtimer_interrupt. Auf dem Zielsystem sieht es leider so aus:

Code: Alles auswählen

Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
now at 181813985215 nsecs

cpu: 0
 clock 0:
  .index:      0
  .resolution: 4000250 nsecs
  .get_time:   ktime_get_real
  .offset:     0 nsecs
active timers:
 clock 1:
  .index:      1
  .resolution: 4000250 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <f754bee8>, it_real_fn, S:01
 # expires at 192405231144 nsecs [in 10591245929 nsecs]
 #1: <f754bee8>, hrtimer_wakeup, S:01
 # expires at 203432149920 nsecs [in 21618164705 nsecs]
 #2: <f754bee8>, it_real_fn, S:01
 # expires at 1812649027145 nsecs [in 1630835041930 nsecs]
 #3: <f754bee8>, hrtimer_wakeup, S:01
 # expires at 3613397498878 nsecs [in 3431583513663 nsecs]
  .expires_next   : 9223372036854775807 nsecs
  .hres_active    : 0
  .nr_events      : 0
  .nohz_mode      : 0
  .idle_tick      : 0 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 0
  .idle_calls     : 0
  .idle_sleeps    : 0
  .idle_entrytime : 181810305977 nsecs
  .idle_waketime  : 0 nsecs
  .idle_exittime  : 0 nsecs
  .idle_sleeptime : 2559531932 nsecs
  .last_jiffies   : 0
  .next_jiffies   : 0
  .idle_expires   : 0 nsecs
jiffies: 4294937719


Tick Device: mode:     0
Clock Event Device: <NULL>
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000


Tick Device: mode:     0
Clock Event Device: pit
 max_delta_ns:   27461866
 min_delta_ns:   12571
 mult:           5124677
 shift:          32
 mode:           2
 next_event:     0 nsecs
 set_next_event: pit_next_event
 set_mode:       init_pit_timer
 event_handler:  tick_handle_periodic

Falsche Auflösung und falscher Handler. Woran kann das liegen? Muss ich das noch irgendwo zusaetzlich konfigurieren? Gibt es dafuer bestimmte Hardwarevoraussetzungen? Bin fuer jeden Tipp dankbar.

Gruß, Felix

[Felix]

Hat denn keiner eine Idee? Ich habe nun bereits die gleiche Kernelversion mit fast der gleichen Konfiguration ausprobiert, aber immernoch das gleiche Ergebnis. Gibt es spezielle Hardwarevoraussetzungen fuer diese High Resolution Timer?

[Felix]

Falls es noch jemanden interessieren sollte, ich vermute inzwischen wirklich stark, dass es eine Frage der richtigen Hardware ist. Ich habe es jedenfalls nicht zum Laufen bekommen. Eine Alternative habe ich heute fuer mich ausgearbeitet. Diese heisst RTAI und erweitert den Linux Kernel um echte Echtzeitfaehigkeiten. Sehr angenehm zu programmieren und funktioniert wirklich gut bis jetzt, vorallem extrem praeziese. Eine echte Verbesserung gegenueber den High Resolution Timern.

Gruß, Felix

[brummer]

Eine echte Verbesserung gegenueber den High Resolution Timern.

Jetzt hast du mich neugierig gemacht.

Diese heisst RTAI und erweitert den Linux Kernel um echte Echtzeitfaehigkeiten

Also ich nutze den rt-patch von kernel.org und bin immer an der verbesserung der echtzeitfähigkeiten des kernels interessiert. Ich hab grad ma gegogeld und nur Beiträge von 2005 über RTAI gefunden. Magst du mir sagen ob du da was aktuelleres am start hast ?
Bzw. kann RATI die Echtzeitfähigkeit des Kernels auch bei einem System wie dein Produktivsystem verbessern ? Oder ist dieser Patch nur eine Brücke für "Mangelhafte Hardware" ?

gruß brummer

[Felix]

Hallo,

also wenn man bei Google RTAI eingibt, kommt man schnell auf die offizielle Webseite:

https://www.rtai.org/

Dort wurde am 30.05.2008 die Version 3.6.1 veröffentlicht. Von daher bin ich davon ausgegangen, dass es sich nicht um ein verwaistes Projekt handelt. So wie ich das verstanden habe, ist RTAI im Grunde nur eine Alternative zu dem von dir erwähnten RT-Linux Patch. Ich habe mir beide Projekte angeschaut und konnte auf den ersten Blick keines auf Grund seiner Funktionalität bevorzugen. Beide scheinen einen ähnlichen Mechanismus (korrigiert mich da, wenn das falsch ist) zu verwenden und beide bieten im Grunde die gleichen Funktionen. Der Unterschied der mir nach einem kurzen Studium aufgefallen ist, ist dass RTAI ein reines Open Source Projekte ist und hinter RT-Linux eine Firma steckt (gibt auch von der eine freie Version). Das war der einzige Grund warum ich zuerst RTAI ausprobiert habe. Aber wenn hier jemand die genauen Unterschiede aufzeigen könnte, wäre das natürlich eine Bereicherung für uns alle. Ich hätte vermutlich für meine Zwecke auch das RT-Linux Patch nehmen können.

Gruß, Felix

[gms]

ich vermute inzwischen wirklich stark, dass es eine Frage der richtigen Hardware ist.

die Kernelparameter "clocksource=hpet" bzw "highres=on" hast du versucht ?

Eine Alternative habe ich heute fuer mich ausgearbeitet. Diese heisst RTAI und erweitert den Linux Kernel um echte Echtzeitfaehigkeiten. Sehr angenehm zu programmieren und funktioniert wirklich gut bis jetzt, vorallem extrem praeziese. Eine echte Verbesserung gegenueber den High Resolution Timern.

also kein Hardware-Problem, der RTAI Patch verwendet aber von sich aus einen geeigneten Timer und durch das Echtzeitverhalten "wirkt" der TImer dann auch noch präziser. RTAI ist sicherlich eine sehr gute Alternative, wenn du dieses Echtzeitverhalten auch nutzen kannst.

Gruß
gms

[Felix]

Ja, die beschriebenen Kerneloptionen hatte ich aktiviert. Mit Hardwareproblem meinte ich, dass vielleicht das Kernelmodul hrtimer eine bestimmte Hardware voraussetzt. War nur so eine Vermutung, da es auf dem einen Rechner lief und auf dem anderen nicht. RTAI macht natürlich intern was ganz anderes, wodurch tatsächliche Echtzeitfähigkeit erst möglich wird. Ich hätte da von Anfang an drauf setzen sollen. Durch die hohe Präzision haben sich inzwischen schon ein paar andere Probleme völlig in Luft aufgelöst .

Gruß, Felix

[brummer]

hallo Felix

Ich meine nicht RT-Linux, sondern den rt-patch von kernel.org
http://www.kernel.org/pub/linux/kernel/projects/rt/

allerdings bringt der in punkto timer nichts mehr, der High_res timer im kernel stammt aber ürsprünglich aus diesem patch, und der ist selbstverständlich open source.
Danke für den link, ich hatte ma wieder nur auf google.linux gesucht
Werde ich mir dann mal zu gemüte führn.

also kein Hardware-Problem, der RTAI Patch verwendet aber von sich aus einen geeigneten Timer und durch das Echtzeitverhalten "wirkt" der TImer dann auch noch präziser. RTAI ist sicherlich eine sehr gute Alternative, wenn du dieses Echtzeitverhalten auch nutzen kannst.

Hats du den RTAI Patch schon mal verwendet ? Hat er vorteile gegenüber einem gut funktionierendem High Resolution Timer ? Meiner läuft mit 1nsec eigentlich zufriedenstellend. Wobei, wenn verbesserungen möglich sind . . .
edit:// hab gerade noch Felix letzten beitrag gesehen, damit hatt sich meine frage geklärt, ich werde mir den RTAI Patch auf jeden Fall ma ansehen. danke
gruß brummer

[Felix]

Meiner läuft mit 1nsec eigentlich zufriedenstellend.

Hast du das mal ausgelotet? Das spuckt zwar cat /proc/timer_list aus, aber ich konnte nich annähernd so genaue Timings erreichen. Aber trotzdem viel bessere Timings als ohne HR-Timer. Das verblüffende ist nun, dass es mit RTAI möglich ist. Ich habe einen periodischen Timer auf 10000ns eingerichtet und mir bei jedem Aufruf die vergangene Systemzeit seit dem letzten Aufruf ausgeben lassen. Die Aufrufe lagen alle 10048ns auseinander, manchmal war der Zeitunterschied auch nur 10047ns. Echt krass sowas. Meiner Erfahrung nach ist sowas mit normalen Timern vollkommen unmöglich zu erreichen. Die 48ns Offset lassen sich sicher auch noch beseitigen, wenn man das mitgelieferte Kallibrierungstool benutzt. Das habe ich kurz versucht, da mir die Genauigkeit aber vollkommen ausreicht nicht weiter mit beschäftigt. Aber es wäre mal interessant, obs dann wirklich perfekt ist.

[gms]

Ich meine nicht RT-Linux, sondern den rt-patch von kernel.org
http://www.kernel.org/pub/linux/kernel/projects/rt/

Mit diesem Patch wird derzeit nur die Latenz verringert, garantierte Antwortzeiten können damit aber meines Wissens nach nicht erreicht werden. Für Audio bzw Multimedia-Anwendungen sollte der Patch aber eigentlich ausreichend sein.
RTLinux bzw RTAI bilden für die Interrupt-Kontrolle eine Schicht zwischen Hardware und dem Linux-Kernel. Der Linux-Kernel lauft dann praktisch als Idle-Task des RT Kernels und kann die Realtime-Task dadurch nicht mehr blockieren.

[Felix]

Hab grad noch ein komisches Phaenomen festgestellt. Auf meinem Entwicklungsrechner ist die CPU seit der Installation von RTAI zu einem signifikanten Prozentsatz dauerausgelastet. Sobald ich aber mein selbstgeschriebenes Kernelmodul lade, dass einen Timer auf Basis von RTAI nutzt ist die Auslastung wieder normal (fast 0). Was kann das sein? Ausserdem ist jetzt schon 2 mal mein Mauszeiger stehengeblieben (USB Maus). Er ging erst in dem Moment wieder, wo ich eine Taste gedrückt habe.

Gruß, Felix