Starke CPU-Last durch RTSLoader und irq/32

hekrau · Post by **hekrau** » 05 Apr 2017, 16:29

Ich habe ein kleines Projekt, in dem ich über die serielle RTU-Schnittstelle MODBUS-Daten von einer Steuerung abhole (1. Python Programm) und dann per HTTP versende (2. Python Programm).
Mein Revpi hat bereits im Leerlauf ca. 8% Last allein durch den RTSLoader.
Wenn ich dann meine beiden Python Programme starte, geht die Last auf 70 - 80 % hoch.
Neben dem RTSLoader mit ca. 20 % tragen auch noch diverse Tasks "irq/32-dwc_otg dazu bei.

Code: Select all

top - 13:12:24 up 20 min,  4 users,  load average: 3.86, 3.08, 2.03
Tasks: 138 total,   1 running, 137 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us, 55.3 sy,  0.0 ni, 32.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    445100 total,   207836 used,   237264 free,    21684 buffers
KiB Swap:   102396 total,        0 used,   102396 free,   101476 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
   47 root     -51   0     0    0    0 S  15.0  0.0   0:39.98 irq/32-dwc_otg_
 3236 root      20   0 21144 9.8m 5852 S  13.1  2.2   0:16.71 python
 2813 root      20   0 54880 2864 2360 S  11.2  0.6   1:48.04 RTSLoader
   45 root     -51   0     0    0    0 S   9.3  0.0   0:24.00 irq/32-dwc_otg
   46 root     -51   0     0    0    0 S   4.6  0.0   0:11.61 irq/32-dwc_otg_
    3 root      -2   0     0    0    0 S   3.8  0.0   0:40.17 ksoftirqd/0
 3272 pi        20   0  4688 2488 2112 R   3.5  0.6   0:00.94 top
 2142 root     -61   0     0    0    0 D   3.0  0.0   0:29.46 piGateT
 2144 root     -59   0     0    0    0 D   0.8  0.0   0:05.85 piIoT

Ich habe die identischen Programme auf Raspberry A bis 3B laufen mit maximal 8 bzw. 1% Last.
Woran mag das liegen?

lukas · Post by **lukas** » 05 Apr 2017, 16:58

irq/32-dwc_otg ist der Interrupt Handler für den USB-Controller. Da du über Modbus RTU kommunizierst (ich nehme an über einen USB-Adapter?) und zugleich über HTTP (der Ethernet-Controller hängt am USB dran), ist plausibel dass der Interrupt Handler die CPU belastet.

Benötigst du logi.RTS für dein Projekt überhaupt? Falls nicht könntest du den RTSLoader Prozess killen.

Mich irritiert allerdings die Aussage, auf dem Raspberry A bis 3B sei die Last mit denselben Programmen geringer. Läuft dort auch logi.RTS?

Der USB- und Ethernet-Controller ist eigentlich genau derselbe wie auf dem Raspberry Pi (SMSC LAN9514), von dieser Seite dürfte es keine Unterschiede geben. Das piControl Kernel-Modul verbraucht noch CPU-Zeit, aber wie man an dem top-Output den du gepostet hast sieht, hält sich das in Grenzen. Eine weitere denkbare Ursache ist der verwendete Kernel mit Realtime-Patches: Der sorgt dafür dass die Latenzzeiten kurz sind, aber die Kehrseite der Medaille ist stets, dass der Durchsatz ein wenig geringer ist als bei einem Mainline-Kernel.

volker · Post by **volker** » 05 Apr 2017, 22:20

Hallo hekrau,
Deinen Beschreibungen entnehme ich, dass Du eigentlich gar nicht mit unseren Softwaretools arbeiten möchtest (Prozessabbild, PiBridge, PiControl, PiCtory, logi.RTS), sondern den RevPi Core als reinen Linux IPC verwendest. Außerdem gehe ich bei http davon aus, dass Dir definierbare Jitter bei der Datenübertragung von Modbus nach http eigentlich egal sind.
Unter diesen Umständen ist unser Image nicht optimal. Mit dem Originalimage vom Raspi für das CM1 wärest Du vermutlich viel besser bedient. Weder der RT-Patch im Kernal noch der PiControl Treiber sowie das Runtime-System von logi.cad3 (logi.RTS) sind für Dich relevant. Wenn Du also all diese Dinge gar nicht benötigst, dann versuch doch einfahc mal das original-Image. Wenn Du allerdings Erweiterungsmodule brauchst, diese mit PiCtory konfigurieren möchtest und gar mit logi.Cad3 steuern willst, dann brauchst Du diesen Versuch nicht machen, denn für solche Anwendungen ist unser Image optimiert.
Mit dem original-Image stehen Dir Ethernet, USB und HDMI zur Verfügung, so dass Du eigentlich damit arbeiten können solltest.

Post by **dirk** » 06 Apr 2017, 07:02

Noch ein Hinweis zur Vermeidung von CPU Last - Dienste deaktivieren die nicht gebraucht werden, siehe hier:
https://revolution.kunbus.de/tutorials/ ... ktivieren/

hekrau · Post by **hekrau** » 06 Apr 2017, 12:18

Hallo Volker,

derzeit nutze ich die IOs von Kunbus noch nicht. Aber der nächste Kunde braucht die neuen analogen Eingänge und digitale Ein- und Ausgänge. Demnach muss ich bei eurem Image bleiben.
ich habe, wie Dirk vorgeschlagen hat, auch den Dienst logiCAD3 deaktiviert. Die anderen benutze ich. Die CPU-Last hat das nicht beeinflusst.

Es bleibt also die Frage nach der Ursache für die CPU-Last zunächst unbeantwortet. Ist der RTSLoader unbedingt notwendig? Verursacht er den irq/32? Kann ich diesen ggf. aus dem Image entfernen?

hekrau · Post by **hekrau** » 06 Apr 2017, 12:45

Hallo Lukas,
auf den normalen Raspberry habe ich das Standard-Image ohne RTS. irq/32 taucht gar nicht auf. Ich benutze den Prolific DL2303 USB2serial Konverter auf allen Systemen.
Wenn ich den RTSLoader kille, verringert sich die CPU-Last auf 50 %, die irq/32-Prozesse brauchen zusammen aber immer noch 30 %. Warum sind diese nur auf dem RevPi, aber nicht auf den "normalen" Raspberry?

volker · Post by **volker** » 06 Apr 2017, 20:46

Wenn ich Dich recht verstanden habe, hast Du inzwischen den RTSloader inaktiviert. Wie bereits mehrfach geposted ist dies die Runtimeumgebung von logi.cad3 und wird eben auch nur dafür benötigt. Die CPU-Last ist auf 50% gesunken, also ist doch alles im grünen Bereich, oder? Wie Lukas schon sagte, sind die IRQ-Prozesse durch die USB devices bzw. Ethernet (=USB beim Raspi) geschuldet. Dies kannst Du ja auch leicht überprüfen, indem Du die USB Geräte und das Ethernet absteckst und nachschaust, ob die Last dann sinkt.
Generell gilt für einen Vergleich solch komplexer Systeme, dass es eine Menge Ursachen für Differenzen geben kann. So hat zum Beispiel Raspi org die USB Treiber vor ca. 1 Jahr runderneuert, weil es probleme mit den alten Treibern gab. Auch das Verhalten unter dem RT patch bedeutet, dass die USB-Treiber völlig andere Prioritäten haben und u.U. mit dem von Dir eingesetzten USB-Devices dadurch ein stark vermehrter USB-Traffic entsteht (retries by timeouts).
Wir haben bei den Prioritäten primär sichergestellt, dass eine Steuerung mit PiBridge-Verwendung absolut definierten Jitter hat. Das System ist daher nicht auf permanenten umfangreichen zeitkritischen USB-Traffic optimiert. Möglicherweise würde in der Konstellation, die Du anstrebst, eine Justage der Prozessprioritäten sinnvoll sein, bei der dann ein großer Jitter auf der PiBridge in Kauf genommen wird, aber die Systemlast durch optimalere USB-Services geringer wird. Auch eine drastische Reduktion der Cycle-Time auf der piBridge (würde allerdings eine Veränderung im Sourcecode von PiControl erfordern) könnte in Deiner Konstellation möglicherweise akzeptabel sein und in der Summe die CPU-Last deutlich verbessern, weil die hochprioren Zugriffe der PiBridge seltener stattfinden und dadruch USB-Prozesse optimaler abgearbeitert werden. Aber das alles ist Spekulation und müsste ausprobiert werden.
Wenn die Systemlast für Deine Anwendungen kritisch ist, dann solltest Du vielleicht besser auf das CM3 setzen. Solange die Umgebunsgtemperatur bei dem geplanten Einsatz niedrig bleibt, würde hierbei eine erhebliche Verbesserung der Rechenleistung resultieren. Genaueres dazu werden wir zur HMI veröffentlichen.

hekrau · Post by **hekrau** » 07 Apr 2017, 01:09

Hallo Volker! Danke für deine ausführliche Antwort. Nachdem sich das System etwas eingeschwungen hat, ist es nun in der Tat bei 50 % Last, was wahrscheinlich OK ist. Durch das Deaktivieren von logi.CAD3 ist der RTSLoader auch nach einem Reboot weg. Offenbar benutzen die neuen USB-Treiber auch nicht mehr irq/32. Hoffentlich nutzt der neue CM3 auch die neuen Treiber, denn etwas unwohl ist mir schon bei dem Gedanken, dass der Rechner im Quasi-Leerlauf soviele Resourcen benötigt.
Ich lasse das System jetzt erstmal einige Zeit vor sich hin laufen, um seine Zuverlässigkeit zu prüfen.
Vielen Dank für die schnelle Hilfe.

lukas · Post by **lukas** » 07 Apr 2017, 08:24

hekrau wrote:auf den normalen Raspberry habe ich das Standard-Image ohne RTS. irq/32 taucht gar nicht auf. Ich benutze den Prolific DL2303 USB2serial Konverter auf allen Systemen. Wenn ich den RTSLoader kille, verringert sich die CPU-Last auf 50 %, die irq/32-Prozesse brauchen zusammen aber immer noch 30 %. Warum sind diese nur auf dem RevPi, aber nicht auf den "normalen" Raspberry?

Bei einem Mainline Kernel wird, solange ein Interrupt Handler läuft, alles andere unterbrochen.

Beim RT-Kernel hingegen sind Interrupt Handler preemptible, können also unterbrochen werden um etwas anderes zu erledigen. Hierfür laufen die Interrupt Handler als normale Kernel Threads neben allen anderen Threads. Deshalb tauchen die Interrupt Handler als Threads in der Prozessliste auf.

Die CPU-Zeit, die für den USB Interrupt Handler aufgewendet wird, ist auf einem Mainline Kernel im Prinzip dieselbe (modulo Context Switches weil der Interrupt Handler preemptible ist, oder Warten auf Locks), bloß tauchen dort die Interrupt Handler nicht als Threads auf.