Das RED Brick Image Version 1.11 ist jetzt Verfügbar: http://download.tinkerforge.com/red_images/full/
Im RED Brick Image 1.10 hatten wir eine große Menge signifikanter Änderungen im Vergleich zu 1.9. Neben anderen Dingen haben wir den Linux Kernel von 3.4 auf 4.13 aktualisiert. Das war eine Menge Arbeit, wir mussten Treiber portieren, unseren SPI-Kommunikations-Code anpassen etc. Dadurch konnten wir einige notwendige Sicherheitsaktualisierungen einpflegen (z.B. der Fix für KRACK WPA) und neuen Treibersupport hinzufügen (z.B. für Bluetooth 5.0). Auf Grund der Sicherheitslücken im 3.4er Kernel war das Kernelupdate aus unserer Sicht alternativlos.
Leider gab es durch das Update einen Rückschritt in der Performance. Diese Regression kam hauptsächlich zustande durch Änderungen am Linux Kernel für Multi-Core Prozessoren (z.B. Busy Waiting auf IO in Interrupts). Diese Änderungen erhöhen die Performance in Multi-Core Systemen, wir hatten allerdings eine Verringerung der Performance des RED Bricks (ein Single-Core System). Der Performanceverlust war bei hohen IO-Belastungen besonders auffällig.
Da wir immernoch viele RED Bricks verkaufen und das Feedback durchgängig sehr positiv ist, haben wir uns dazu entschieden das "Großprojekt" anzugehen die Performance für die nächste Image Version wieder zu verbessern.
Unter anderem haben wir
- den Scheduler von dynamic auf periodic ticks genändert und Control Groups deaktiviert,
- support für rescheduling von Prozessoren während IOCTL aufrufen hinzugefügt,
- das SPI interrupt handling verbessert and
- DMA Support für spidev Treiber hinzugefügt.
Um diese Änderungen zu machen und vernünftig zu testen mussten wir zwei Monate Arbeit investieren. Es benötigte eine Menge "trial-and-error" um die eigentlichen Performance-Flaschenhälse ausfindig zu machen.
Wir haben mti drei verschiedenen Benchmakrs getestet:
Benchmark 1: CPU-Bound
Für die CPU-Bound Performance-Tests haben wir sysbench mit den Parametern "--test=cpu --cpu-max-prime=4096 run" genutzt.
Der governor (wenn zutreffend) war auf "performance" gestellt und die Verbindung zum RED Brick wurde über SSH durch die Ethernet Extension hergestellt.
Die durchschnittliche Ausführungszeit konnte von Version 1.10 auf 1.11 um 5,4ms verringert werden. Das entspricht einem Leistungsanstieg von 25%. Die Performance ist zusätzlich auch etwas besser als in dem 1.9 Image mit 3.4 Kernel.
Benchmark 2: IO-Bound
Für die IO-Bound Performance-Tests haben wir iper3 mit den Parametern "-c ishraq-tinkerforge -N -t 120" genutzt.
Der governor (wenn zutreffend) war auf "performance" gestellt und die Verbindung zum RED Brick wurde über SSH durch die Ethernet Extension hergestellt.
Wir haben mit und ohne Stapel getestet. In den Tests mit Stapel haben wir einen Master Brick mit Thermal Imaging Bricklet genutzt. Das Thermal Imaging Bricklet ist gut geeignet, da es hinreichend viele Daten generieren kann um die Stapel-Kommunikation zu saturieren.
Der Graph spricht für sich selbst. Wir konnten konnten einen Leistungsanstieg von 220% verglichen zu 1.10 und 23% verglichen zu 1.9 messen!
Benchmark 3: Stapel-Kommunikation
Zusätzlich haben wir auch noch Tests zur reinen Stapel-Kommunikation durchgeführt. In diesem Test nutzen wir ein Python-Script welches auf dem RED Brick ausgeführt wird und Daten vom Thermal Imaging Bricklet mit Getter/Callback sammelt und diese ohne zusätzliche CPU-Last zu erzeugen verwirft. Dabei berechnen wir die Bilder pro Sekunde (FPS).
In diesem Test konnten wir die Performance im Verglich zu 1.10 steigern, haben allerdings immer noch eine kleine Regression verglichen zu 1.9. Allerdings läuft die CPU im 1.9er Image in diesem Test bereits am Limit, während im neuen 1.11er Image noch CPU-Zeit für Berechnungen übrig ist. Das lässt sich auch gut im IO-Bound Test beobachten, dort wird CPU-Last hinzugefügt durch das zusätzliche Senden der Daten zum PC.
Insgesamt sind wir mit dem erreichten Kompromiss aus Stapel-Kommunikations-Durchsatz und verfügbarer CPU-Zeit sehr zufrieden. Wir sind zuversichtlich das die Performance in Image 1.11 in echten Anwendungen im Vergleich zu 1.10 erheblich und im Vergleich zu 1.9 moderat verbessert wurde.
