[GELÖST] QEMU/KVM HB-RF-USB hohe CPU Last

[Jumako]

Hallo zusammen,

bei mir bleibt es nach wie vor bei den 17-19% CPU-Last unter Proxmox (stabil, jetzt seit ca. 3 Tagen).

Eine ganz andere Idee, die ich bisher noch nicht verfolgt habe:

Wäre es möglich, einen USB-Server einzusetzen? Der USB-Stick wird am USB-Server eingesteckt (kleiner Adapter) und der via Netzwerk eingebunden, in der virtuellen Maschine werden die Signale via Netzwerk "empfangen" und über ein Software-USB-Device simuliert. Nebenbei der Vorteil, dass der USB-Server frei positioniert werden könnte.

Ich selbst habe noch einen Silex sx-ds-4000u2 USB-Server, allerdings noch nie genutzt (gibt es überhaupt Treiber für Linux?). Wenn nicht diese Hardware, dann evtl. eine andere? Oder ist durch die Umrechnung und den Transport der Signale die Latenz zu groß und die CCU kommt aus dem Tritt?

Nur als Idee, ich google mal ...

Viele Grüße
Jürgen

[deimos]

Hi,

die Diskussion wurde schon mehrfach geführt. Es gibt keinen bezahlbaren USB Server mit Linux Unterstützung. Und nicht ohne Grund arbeite ich schon seit einiger Zeit für debmatic an einer Platine, mit welcher man das Funkmodul per Netzwerk absetzen kann: viewtopic.php?f=76&t=51754

Viele Grüße
Alex

[Jumako]

@Alex:
Ahh, hätte ich mir denken können/müssen (und mal die Suche benutzen).

Wurde auch schon diskutiert, ob via USBIP (http://usbip.sourceforge.net/) ein Durchreichen möglich ist (da habe ich keine Treffer über die Suche bekommen)?
Es gibt damit ein Modul "vhci-hcd" für den Client (RaspberryMatic) und das Modul "usbip_host" für den USB-Server. Ein kurzes lsmod in RaspberryMatic hat gezeigt, dass das passende Kernel-Modul vorhanden ist (vhci-hcd).
Der vorhandene Host wird als Server eingesetzt (da steckt der USB-Stick ja schon drin) und der Gast (RaspberryMatic) empfängt die Signale via Netzwerk.

[dodi]

Hallo zusammen,
ich habe mir das Ganze gestern nochmal direkt am System angeschaut.
Ich habe folgendes System:
Zotac ZBox CI327
CPU(s): 4 x Intel(R) Celeron(R) CPU N3450 @ 1.10GHz (1 Socket)
RAM: 16GB

Augangssituation:
1xLXC: Debian10 mit nginx -> 1CPU + 512MB RAM --> CPU Last < 1%
1xLXC: Debian 10 mit piHole -> 1CPU + 512MB RAM --> CPU Last < 1%
1xVM: Raspmatic -> 2CPU + 1GB RAM (USB Device HB-RF-USB auf USB 3.0)--> CPU Last ~38%
1xVM: ioBroker -> 4CPU + 3GB RAM --> CPU Last ~11%
Gesamt System: --> CPU Last ~30%

Ich habe dann bei der VM Raspmatic von USB 3.0 auf USB 2.0 umgestellt:
Dabei reduzierte sich die CPU Last der RaspMatic auf 23%.
Das Gesamtsystem entsprechend auf 25%.

Danach habe ich der Raspmatic 4CPU Sockets zugewiesen, was zu einer CPU Last von 12% führte.
Dieser Schritt hat logischerweise auf das Gesamtsystem keine Auswirkung gehabt...

RaspMatic CPU Auslastung.PNG (15.98 KiB) 1470 mal betrachtet

Welche Änderungen könnte man noch ausprobieren?
Besteht theoretisch die Möglichkeit RaspMatic im Container auszuliefern, so dass man das durchreichen des USB Adapters performanter gestalten kann?

Grüße
Sascha

[deimos]

Hi,

Welche Änderungen könnte man noch ausprobieren?

Eine Option: debmatic im (LXC-)Container. Andere Option: Auf meine neue Platine warten.

Viele Grüße
Alex

[Jumako]

Hallo zusammen,

da es mir keine Ruhe lässt, hier noch Stand meiner Tests mit usbip. Bitte wirklich nur als TEST verstehen (dies ist alles nicht "sauber"), ob es denn überhaupt gehen würde.

1.) Für die virtuelle RaspberryMatic (bei mir eine Proxmox-VM):

Diese Pakete aus Debian Buster ziehen (alles i386), da einige benötige Files nicht in RaspberryMatic enthalten sind:
a.) usbip_2.0+4.19.98-1_i386.deb
b.) libwrap0_7.6.q-28_i386.deb
c.) libc6_2.28-10_i386.deb

Aus a.) das Programm "usbip" nehmen und in der RaspberryMatic nach /usr/local/bin bringen ("bin"-Verzeichnis neu anlegen).
Aus b.) den Link "libwrap.so.0" und die Library "libwrap.so.0.7.6" nehmen und in der RaspberryMatic nach /usr/local/lib bringen ("lib"-Verzeichnis neu anlegen).
Aus c.) den Link " libnsl.so.1" und die Library "libnsl-2.28.so" nehmen und in der RaspberryMatic nach /usr/local/lib bringen.

2.) Auf dem Rechner mit dem USB-Stick (bei mir der Proxmox-Host):

apt install usbip

modprobe usbip-host

usbip list -l (= Liste alle USB-Geräte die freigegeben werden können, hier die ID für den EQ-Stick ermitteln)
usbip bind -b "1-11" (= ermittelte ID hier freigeben, bei mir "1-11")

usbipd (= usbip-Server starten, ggf. mit "-d" für weitere Debug-Ausgaben)

Damit läuft der usbip-Server und lauscht auf Anfragen (bewusst nicht mit -D gestartet, da ich die Ausgaben auf der Konsole sehen will).

3.) Danach auf der virtuellen RaspberryMatic:

modprobe vhci-hcd

im Verzeichnis /usr/local/bin
./usbip list --remote=<usbip-Server-Adresse>

Damit werden die USB - Geräte des Host-Systems aufgelistet.

Verbindung mit dem EQ-USB-Stick herstellen:

./usbip attach -r <usbip-Server-Adresse> -b <Port-des-USB-Sticks> (bei mir war es "1-11")

Ein "lsusb" zeigt dann das Device wie wenn es lokal angebunden wäre.

Danach nach /etc/init.d wechseln:

./S11InitRFHardware restart
bei mir : HmIP: HMIP-RFUSB, OK

Der Stick ist zumindest erkannt worden, allerdings war er damit noch NICHT im Webinterface sichtbar. Habe dann "wild" ein paar Services durchgestartet, leider erfolglos (ich hatte dann eine CPU-Last von über 35% ), vermutlich müsste ich die VM komplett durchstarten. Einen Restart überlebt die o.g. Konfiguration so noch nicht, ich habe die Befehle nicht in den Systemstart integriert bekommen (ist ja alles "read only"). Dies versuche ich später oder morgen (oder gar nicht mehr).

Wie geschrieben, alles nur ein TEST, ob es grundsätzlich so eine Möglichkeit geben könnte (so würde ich es NIE produktiv einsetzten wollen). Ist mir ehrlich gesagt auch alles zu komplex.

Ich werde wohl eher endlich mal debmatic testen.

Viele Grüße
Jürgen

[hmpatman]

Hallo!

So, ich hab auch noch ein paar Versuche gestartet und dabei bin ich auf was ganz Simples gestoßen. Die Anzeige der Last ist einfach "falsch". Wenn man unter top/htop sich die CPU% beim Prozess ansieht, dann ist das nicht (wie man/ich) annehmen würde die CPU Auslastung. Wie man in der Anleitung nachlesen kann, zählt da auch die Zeit dazu, die der Prozess auf I/O wartet. Um die richtigen Werte zu sehen, kann man entweder bei top in der dritten Zeile (Gesamtwerte) die 1-idle rechnen oder wenn noch andere Dienste laufen, sollte man virt-top nehmen. Letzteres zeigt die Rechenzeit CPU% der einzelnen virtuellen Maschinen an. Die liegt bei mir bei 5% für RaspberryMatic. Kurz das Problem ist viel (viel) kleiner als ich dachte.

Was ich noch nicht kapiert habe, ist was bei Proxmox gepatcht oder anders konfiguriert ist, dass die VMs nicht lange auf den USB Zugriff warten müssen bzw. die Anzeige anders ist. Selbst ein Ubuntu mit "low-latency" Kernel zeigt da keine Verbesserung. Ich vermute mal, das Warten hat außer einer HM Verzögerung keine Auswirkungen und wie groß (wenn überhaupt) die ist, muss ich erst herausfinden. Könnte aber sein, dass das alles nur Scheinprobleme sind.

Vielleicht hält es ja andere davon ab Zeit zu verschwenden.
Also: virt-top zeigt die "Wahrheit" top/htop Last+Wartezeit.

Viele Grüße,
Patrick