CUL-Adapter am Tinkerboard
-
Es war bereits schon mal Thema, ich möchte es noch einmal aufgreifen.
Auch ich wunderte mich gestern über die Temperatur meines Tinkerboards. Es war fast 10°C höher als sonst 48°C statt ansonsten unter 40°C. Da stellte ich mir natürlich die Frage warum der kleine Fieber hatte.
Es war auf den ersten Blick nicht ersichtlich. Die System Load lag bei schlappen 0,4, die CPU Auslastung bei durchschnittlichen 6,6% und auch die Prozesse zeigten keinerlei auffällige Last. Weder bei CPU-Nutzung noch bei Mem.
Trotzdem lief die CPU auf Vollgas mit 1800 MHz.
Top bestätigte mir diese Daten.
Ich überlegte Lange, was ich in der letzten Zeit geändert hatte, deaktivierte die entsprechenden beiden Skripte - ohne Veränderung.
Dann erinnerte ich mich an den einen oder anderen Post.
Ich hatte mein einziges FS20 Gerät über den CUL-Adapter in das System eingebunden.
Und siehe da nach Abschalten des CUL-Adapters war sofort Ruhe:
Und nach Reaktivierung wieder dieses Bild mit 1800MHz CPU Takt und 78°C CPU Temperatur.Lt. @deimos scheint das ein Problem mit dem USB-Port beim Tinkerboard zu sein. Wobei http://forum.iobroker.net/viewtopic.php?f=17&t=9395&hilit=pivccu+cull+all+in+tinkerboard der CUL in der piVCCU eingebunden wurde.
Bei mir hängt der CUL an einem Tinkerboard ohne piVCCU und wird über den CUL-Adapter eingebunden.
Ist das wirklich ein Problem nur mit dem Tinkerboard?
Gruß
Rainer
-
Hi,
das Problem liegt nicht an piVCCU, das liegt rein am USB OTG Treiber. Dürfte aber kein reines Tinkerboard Problem sein, sondern ein Problem von allen Boards, welche den USB Chip haben und so verdrahtet sind, wie das Tinkerboard.
Mit dem Patch in Armbian wird es zwar etwas besser (vor allem, wenn man zwei TTY Sticks gleichzeitig dran hat), aber richtig gelöst ist es dann leider immer noch nicht.
Viele Grüße
Alex
-
Hallo Alex,
@deimos:das Problem liegt nicht an piVCCU `
klar, das ist ja gar nicht drauf
deswegen habe ich das Thema für den StandaloneTinker noch mal aufgemacht.danke für deine Einschätzung, dann lohnt es sich nicht den CUL an einen Slave zu hängen.
Mir war noch aufgefallen, dass noch irgendein mir bisher nicht bekannter Daemon ziemlich aktiv ist. Habe jetzt keinen Zugriff auf das Tinkerboard. Erinnere mich nur, dass ich beim googeln etwas gefunden habe, dass dieser Daemon für die Generierung "echter" Zufallszahlen zuständig sein soll.
Kann der etwas mit dem CUL / USB Problem zu tun haben?
Doch eher nicht, oder?
Gruß
Rainer
-
Hi,
du meinst vermutlich haveged.
Der ist direkt von dem Problem betroffen, weil der Zufallszahlen u.A. über die Interrupts berechnet (Deutlich besser als eine PRNG wie /dev/urandom, aber noch weit von "echten" Zufallszahlen entfernt). Und da so viele unnötige Interrupts erzeugt werden hat der verdammt viel zu tun. Mit dem Patch in Armbian wurde das auf meinem Tinkerboard aber deutlich besser.
Viele Grüße
Alex
-
du meinst vermutlich haveged. `
Genau der wars!Und mit deiner Erklärung der Funktion ergibt das auch einen Sinn!
Danke
Rainer
-
Mit dem Patch in Armbian wird es zwar etwas besser `
leider nicht wirklich
Vorher:
erstes Board!Nachher:
keine wirkliche Verbesserung, dafür ist die Uptime futsch
nach wie vor ist haveged der Prozess mit der höchsten CPU-Belastung
Erst wieder nach Deaktivierung des CUL-Adapters ging der Takt und die Temperatur runter.
Gruß
Rainer
-
Hi,
immerhin 2 Grad. Richtig übel war es mit 2 Sticks, da war ein Kern dauerhaft bei 100% und die Temp irgendwo bei knapp 80. Da hat der Patch massiv geholfen.
Aber ich geb dir recht, ideal ist anders.
Viele Grüße
Alex
-
Hi
ich habe das gleiche Problem mit dem Tinkerboard, seitdem ich einen BT-USB-Dongle betreibe.
Meine Lösung ist , den Govenor per cpufreq-set von "conservative" auf "schedutil" zu stellen.
Dann fällt die Taktrate sofort ab und alles läuft, wie es soll
Grüße
-
Wo setze ich den governor?
kannst du mir den Pfad nennen, bitte?
Gruß
Rainer
-
aus dem Kopf: einfach in der Kommandozeile als root eingeben: "cpufreq-set -g schedutil".
Dann kannst du per cpufreq-info sehen, wie das Tinker taktet.
Ich glaube aber, der Governor wird nach einem Neustart wieder zurückgesetzt auf conservative… weiß jetzt nicht. Ich starte das Tinker nur neu nach Kernel-Updates
Ich muss erstmal selbst schauen, wo man das dauerhaft einstellt
-
Hi,
kannst du mir den Pfad nennen, bitte? `
/etc/default/cpufrequtils
Leider wird das bei Armbian leider bei Updates teilweise kommentarlos wieder zurückgesetzt.
Viele Grüße
Alex
-
Danke!
Habe es da auch in schedutils geändert, der governor ist aber nach reboot immer noch auf "interactive"
etwas irritiert mich die Ausgabe von cpufreq-info:
available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance, schedDas schedutil ist abgeschnitten
EDIT:
Habe ihn jetzt auf ondemand gestellt; CPU-Clock ging ohne CUL auf 216MHz zurück und nach aktivieren von CUL blieb sie sogar (erst mal?) da.
EDIT2:
Bringt dauerhaft nichts, auch conservative nicht
Gruß
Rainer
