Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[deimos]

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

[Homoran]

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

[deimos]

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

[Homoran]

@deimos:

du meinst vermutlich haveged. `
Genau der wars!

Und mit deiner Erklärung der Funktion ergibt das auch einen Sinn!

Danke

Rainer

[Homoran]

@deimos:

Mit dem Patch in Armbian wird es zwar etwas besser `
leider nicht wirklich :cry:

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

[deimos]

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

[rudiraz]

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

[Homoran]

Wo setze ich den governor?

kannst du mir den Pfad nennen, bitte?

Gruß

Rainer

[rudiraz]

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

[deimos]

Hi,

@Homoran:

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

[Homoran]

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, sched

Das 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