[Marcus]

Hallo MLD-Entwickler und -User.

Ich habe hier ein paar zusammengefasste MLD 6.5 Bugs/Probleme, die mir beim Testen bisher aufgefallen sind. Vielleicht können wir zusammen ein paar dieser Probleme abstellen, damit die MLD noch besser wird.

Sytem:
Dell Wyse 3040, Atom x5 z8350 CPU, 2 GB RAM, 8 GB eMMC, Intel gen.8 iGPU, DVB kommt via streamdev-client und Aufnahmen per NFS. Verbindung zum Server via Ethernet, kein WLAN. Fernbedienung per FLIRC, also Tastatur-Events.

Die CPU ist vergleichsweise leistungschwach, vergleichbar mit einem RPi4, daher fällt das träge Verhalten hier vielleicht besonders deutlich auf. Ist halt kein Core i3/5/7. Dekodiert wird sowohl mpeg2 als auch h.264 auf der iGPU, das OSD und auch osdteletext werden per OpenGL gerendert. Beides per intel_gpu_top verifiziert und funktioniert, wie es soll.

Die Probleme im Einzelnen:

- Nach dem (Neu-)Start vom VDR (der APP) oder nach dem Booten braucht ein VDR-Prozess drei Minuten lang >100% und ein weiterer VDR-Prozess rund 25-30%. Ein Kern ist komplett am Anschlag. Nach drei Minuten fällt das schlagartig auf ca. 25-30%. Wenn der VDR-Prozess beendet wird, ist die CPU komplett idle auf allen Kernen, Load 0,01. Das liegt an epgsync (sync beim Start) und ist somit kein Bug der MLD.

- Scrollverhalten in langen Menüs, in denen der gesamte OSD-Inhalt verschoben werden muss, ist sehr langsam und die CPU geht gegen 100% auf einem Kern. MLD 5.4 läuft hier etwas besser. Während bei dem 5.4 die CPU fast komplett ausgelastet ist, ist das Scrollverhalten nur minimal, fast nicht merklich, langsamer. Das scheint ein Grenzfall zu sein, bei der 5.4 geht es gerade noch so, bei der 6.5 nicht mehr. Lösungsmöglichkeit: Den z8350 etwas tunen. Die CPU darf im Wyse 3040 nur 2 Watt verbrauchen. Wenn die GPU das Video dekodieren muss, bleibt für die CPU kaum noch Leistung übrig. Diese taktet dann nur mit dem Grundtaktfrequenz von 480 MHz, was wohl nicht ausreichend ist. Man kann per MSR Interface das Leistungslimit aufbohren, der SoC wird dabei etwas wärmer. Der 3040 hat aber einen ziemlich großen Kühlkörper, daher bleiben die Temperaturen im grünen Bereich. Erledigt! Das war kein Bug in der MLD, sondern ein zu geringes Powerlimit im UEFI von DELL. Claus hat den Intel PowerCap Treiber im Kernel hinzugefügt. Jetzt kann man das Powerlimit überschreiben. Die CPU taktet nun bis auf die vollen 1920 MHz, statt wie bisher nur 480 MHz.

- Scrollverhalten in den VDR-Einstellungen "Sonstiges" ist sehr langsam und die CPU geht gegen 100% auf einem Kern. Ist es in MLD 5.4 x86 aber auch. In MLD 5.4 auf Raspberry Pi 2 läuft es flüssig. Das tritt nur mit aktiviertem SVDRP peering auf. Lösungsmöglichkeit siehe oben, Powerlimit anheben.

- osdteletext ist extrem langsam. Seitenaufbau zwischen 2 - 4 Sekunden. Uhrzeit springt ebenfalls in diesem Intervall. Seiteneingaben brauchen 3x diese Zeit, da drei Ziffern eingegeben werden müssen. Also irgendwas zwischen 6 und 12 Sekunden. Die CPU-Auslastung ist sehr hoch, wenn osdteletext offen ist. osdteletext läuft auf MLD 5.4 flüssig und verbraucht kaum CPU-Zeit, die Uhrzeit springt im Sekundentakt weiter. osdteletext wird, wie das ganze OSD, per OpenGL gerendert. Man sieht bei intel_gpu_top eine Änderung der Auslastung im Bereich Render/3D, wenn man osdteletext öffnet. Daher sollte das nicht träge sein. Das funktioniert mit angehobenem Powerlimit nun zwar deutlich besser, aber nicht gut. Hier ist definitiv ein großer Unterschied zur MLD 5.4. In der MLD 5.4 braucht osdteletext nur sehr wenig CPU, fast nichts, in der 6.5 aber extrem viel.

- Im WebIf stürzt der VDR in einer Endlosschleife ab, wenn man auf VDR OSD geht.

- Plymouth stürzt mit backtrace beim Starten und Herunterfahren ab, wenn keine Tastatur angeschlossen ist.

- ACPI SDHCI eMMC wird nicht erkannt. PCI SDHCI eMMC schon. War bei MLD 5.4 auch schonmal Thema, wurde dort gelöst und funktioniert.
https://www.minidvblinux.de/forum/index.php/topic,8180.msg66510.html#msg66510

- Einmal eingerichtetes WLAN lässt sich nicht mehr entfernen. Es wird getrennt, verbindet nach Neustart aber immer wieder.

- Atom x5 z8350 analog Audio wird nicht erkannt, bzw. lässt sich im WebIf nicht auswählen.

- Im EPG werden die VDR-Fonts bzw. WarEagle-Icons (der "runningman" oder die Uhr) nicht angezeigt, stattdessen * und t/T. In den VDR-Einstellungen unter OSD gab es früher an 4. Stelle den Punkt "WarEagle icons: ja/nein". Das fehlt bei der 6.5 in den Einstellungen. Das Paket vdr-font-symbols, von dem ich glaube, dass es die Symbole enthält, ist installiert. Im EPG von EPGsearch werden sie wohl auch benutzt, zumindest die Uhr für programmierte Timer. Nur im VDR-eigenen EPG nicht.

-

Support Log id ist: IeMdMs

Ich werde hier weitere Auffälligkeiten ergänzen/updaten und gelöste Probleme streichen. Ich hoffe, dass diese Vorgehensweise okay ist. Falls es bessere Wege gibt, so teilt mir diese bitte mit.

Mit freundlichen Grüßen
Marcus

EDIT: Scrollproblem genauer beschrieben.
EDIT: Scrollproblem offensichtlich zwei verschiedene Probleme -> gesplittet.
EDIT: Erkenntnisse zum Scrollproblem ergänzt und fehlenden VDR-Font hinzugefügt.
EDIT: Weitere Infos zu den fehlenden VDR-fonts hinzugefügt.
EDIT: Plymouth stürzt nur ab, wenn keine Tastatur angeschlossen ist.
EDIT: Powerlimit angehoben, Scrollverhalten gelöst!

[clausmuus]

Das Scrollproblem klingt danach, dass für das Anzeigen des OSD nicht die GPU verwendet wird. Wobei ich nicht weiß, ob es da Unterschiede gibt, je nachdem was für ne Grafikkarte man verwendet, oder ob sich da irgendwas in den Einstellungen des Ausgabe Plugin konfigurieren lässt. Ich selbe verwende immer seitenweises Scrollen, weshalb ich nicht mitbekommen würde, wenn das auch bei mir auftreten würde. Das muss ich also erst mal bei meinen Testsystemen beobachten.

Die Hohe Systemlast ist nicht normal. Ist da ein Prozess sichtbar, der CPU Last Produziert, oder ist lediglich der Load hoch? Load heißt ja nicht zwangsweise CPU. Die Load kann auch durch andere Komponenten wie Netzwerk oder Festplatte produziert werden. Da würde schon ein USB Stick reichen der ne Macke hat, und auf Anfragen nur verzögert antwortet (hatte ich gerade erst bei einer Server SSD).

[Marcus]

Es wird definitiv die GPU für das OSD verwendet.
1. Im OSD unter Softhddevice steht es
2. intel_gpu_top zeigt es mir an. Unter Render/3D steigt die Auslastung, sobald ich das OSD öffne oder noch weiter, wenn ich scrolle.

Die hohe Systemlast wird ausschließlich vom VDR-Prozess erzeugt. Und indirekt wohl auch durch Netzwerk, denn ich nutze ja streamdev-client. VDR braucht lt. htop ca 25-30% CPU. Wenn ich VDR beende, ist die Load bei 0,01, welches dann noch von ssh und htop erzeugt wird. Die hohe Load am Anfang können wir ignorieren, ich habe mittlerweile herausgefunden, dass das der epgsync mit dem Server ist. Aber im laufenden Betrieb pendelt es zwischen 1,6 bis 2,0. Man sollte aber auch den Atom im Auge behalten, auf einem Core i9 wäre das vermutlich nichmal wahrnehmbar.

USB-Stick kann ich ausschließen. Es finden keine nennenswerten Schreib- oder Lesezugriffe auf den Stick statt. Die Load ist auch bei einem Live-Test so hoch, und da ist das FS im RAM.

Dieses ziemlich träge Verhalten kommt wohl nur durch das scrollen des OSD Inhalts zustande. Wobei ich nicht verstehe, warum das heutzutage noch ein Problem sein sollte. Der Atom ist zwar relativ schwach auf der Brust, aber das sollte die GPU beschleunigen. Ich hätte nämlich erwartet, dass ich eine Auslastung des Blitters (2. Zeile bei intel_gpu_top) beim Scrollen sehen würde. Der ist aber grundsätzlich 0%. Der ist eigentlich genau für sowas zuständig. Siehe dazu https://de.wikipedia.org/wiki/Bit_blit

[Marcus]

Hier mal ein paar Screenshots. Der VDR lief seit mindestens 30 Minuten einfach so vor sich hin. Habe die FB nicht angefasst. Es läuft phoenix HD via DVB-C (streamdev-client).

[clausmuus]

Mein N100 System hat in Ruhe ein Load von 2,5 bei einer VDR CPU Last von 12%
Das Scrollen geht flüssig und steigert die CPU Last um 2%.

[Marcus]

Der N100 ist sehr viel performanter als der alte z8350 von 2016. Daher fällt mir das so extrem auf. Geh mal ins Menü "System" - "VDR Setup" - "Sonstiges" und scroll da mal und beobachte dabei die CPU-Auslastung. Ich weiß nicht warum, aber dort ist es bei mir extrem. Auch ohne dass der gesamte Bilschirminhalt mit jeder Zeile verschoben wird. In allen anderen Menüs, Aufnahmen z.B. oder EPG, da scrollt es erst ganz normal. Erst wenn er anfängt den gesamten Inhalt zeilenweise zu verschieben, wird es lahm.

[neumann2k]

Welches Skin verwendest Du?

[Marcus]

Ah, richtig. Das ist sicherlich auch wichtig zu erwähnen. Aber leider nix wildes. Ich nutze den Standard LCARS Skin. Von dem würde ich jetzt mal die geringsten Probleme erwarten.

[clausmuus]

Ich habe jetzt auch noch den RPI 4 getestet. Auch bei dem geht alles flüssig. Der Load ist durchgängig bei 3 und CPU < 10%

[Marcus]

Ja ist schon seltsam. Mich wundern zwei Dinge. Erstens, warum ist es in den VDR Einstellungen "Sonstiges" generell so langsam? Was ist in diesem Menü besonders? Weil dort wird ja nur der Cursor (der breite Balken) nach unten verschoben. Und zweitens, wenn der gesamte OSD Inhalt gescrollt werden muss, warum wird dazu nicht der Blitter benutzt? Dafür ist er da. Dass es dann auf lowest end Hardware klemmt, ist klar. Wie gesagt, N100, Core ix, oder was auch immer hat da wohl weniger Probleme mit. Aber diese Frage gehört wohl nach upstream. Entweder an den Entwickler von softhddevice, oder sogar noch weiter an die Jungs von OpenGL.

[Marcus]

Ich habe gerade nochmal mit der MLD 5.4 verglichen:

Das Scrollverhalten im VDR Einstellungsmenü "Sonstiges" ist interessanterweise dort genau so schlecht. Das scheint also eine Eigenart von diesem speziellen Menü im VDR selbst zu sein. Warum auch immer.

Aber! In Menüs in denen der OSD-Inhalt gescrollt werden muss, also z.B. Aufnahmen und EPG, scrollt die 5.4 deutlich besser/flüssiger. Das fällt praktisch nicht auf. Leider gibt es für die 5.4 kein intel_gpu_top. Daher kann ich nicht nachsehen, ob hier der Blitter dazu verwendet wird, oder ob das aus anderen Gründen besser funktioniert.

[franky]

Hallo Marcus,

ich habe versucht das Problem mal auf meinen alten, schon immer kritischen, mobilen Airmont-Systemen der Braswell Generation nachzustellen.
Außer meinen ehemaligen VDR-Server mit N3150 habe ich mein schwächstes Braswell-System, eine Asrock BeeBox N3000 mit 4GB RAM (256MB shared für iGPU), ausgemottet.
Dein Atom x5 z8350 gehört ja als Tablet-CPU auch zu den CPUs mit Airmont Architektur, wobei die iGPU des N3000 nur minimal mehr Grafik Power hat.

Das von dir beschriebene Problem, besonders beim VDR Einstellungsmenü "Sonstiges", kann ich jedoch auch beim N3000 nicht feststellen.
Da läuft das Scrollen in allen OSD-Menüs sowohl mit Tastatur als auch FB über den internen CIR flüssig.

Flirc habe ich nicht getestet, da ich den wegen seinem ruckeligen Verhalten schon lange nicht mehr verwende.

Das scheint eher eine Eigenart dieser Airmont Tablet Atom CPU/iGPUs der CherryTrail-Generation zu sein.
Bin schon am überlegen, ob ich mir so einen Wyse 3040 antun soll, um dein Problem nachzustellen.

[Marcus]

Nee, ich möchte hier auf gar keinen Fall irgendjemanden "nötigen", Hardware zu kaufen, um meine Probleme zu lösen. Das lass bitte sein.

Das du das Problem allerdings nicht nachstellen kannst, verstehe ich nun aber garnicht. Dass der FLIRC ziemlich zickig ist, habe ich auch schon festgestellt. Bin schon am Überlegen, die (ich habe 2) wieder zurück zu geben. Aber das kann nicht die Ursache sein. Wenn es am FLIRC liegen würde, wäre das in jedem Menü. Und nicht nur in einem speziellen. Oder dass er in Aufnahmen und EPG super scrollt, bis zu dem Punkt, an dem er den Bildschirminhalt verschieben muss. Auch den Rest der Hardware kann man dafür ja erstmal nicht verantwortlich machen. Denn auch hier: warum nur in diesem einen Menü? Was ist daran so besonders? Bin da erstmal ratlos und sehe keinen Zusammenhang.

[Marcus]

Der Wyse 3040 hat nur 2 GB RAM, davon (soweit ich das überblicken kann) 128 MB für die iGPU. Von 2048 MB fehlen 156 MB.

Code: [Select]

MemTotal:        1937204 kB
MemFree:         1205492 kB
MemAvailable:    1531624 kB
Buffers:            2120 kB
Cached:           449464 kB
SwapCached:            0 kB
Active:            93368 kB
Inactive:         431172 kB
Active(anon):       1756 kB
Inactive(anon):   191964 kB
Active(file):      91612 kB
Inactive(file):   239208 kB
Unevictable:      110056 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        183072 kB
Mapped:           113316 kB
Shmem:            120764 kB
KReclaimable:      27360 kB
Slab:              60712 kB
SReclaimable:      27360 kB
SUnreclaim:        33352 kB
KernelStack:        3552 kB
PageTables:         4316 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      968600 kB
Committed_AS:    1151204 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       14268 kB
VmallocChunk:          0 kB
Percpu:             1568 kB
DirectMap4k:       68664 kB
DirectMap2M:     1939456 kB


[Marcus]

Ist es eigentlich tatsächlich so, dass die iGPU nur auf derart wenig RAM zugreifen kann? Bisher dachte ich, dass das dynamisch zugewiesen wird. Die HD600/605 im Wyse 5070 soll sich bis zu 8 GB genehmigen können. Beim Wyse 3040 sollen es (theoretisch) die kompletten 2 GB sein. Abzüglich dessen, was die CPU braucht.