ICAM Patch oscam-emu

[Token]

@Tec-Hi
Ah okay, Danke für die Info!

 

[el_malto]

Bei mir wird alles richtig angezeigt. Symbol ändert sich und wird grau wenn ich einen Reader ausschalte.

 

[Leo888]

So ist es, nix Bug

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[ackerman76]

Sehr komische Rechnung. Man kann hier nicht einfach 1 + 1 = 2 rechnen.

Doch, Linux gibt die Gesamtauslastung immer als Prozentwert der vorhandenen Kerne an. Sprich, dem System stehen 200% CPU-Zeit zur Verfügung.
Sollte oscam nicht multithreaded sein, ist für den natürlich bei 100% Schluss.
Alle weiteren Prozesse (vor allem enigma2) können aber wunderbar auf der freien CPU-Zeit arbeiten.
90% für oscam sind daher völlig ok.

Edit: Hier mal ein Beispiel. Ich habe die Thread-Anzeige aktiviert. oscam selbst hat schon mal mindestens vier Threads (siehe Speicher), wobei der erste die gesamte Last trägt.
Enigma2 selbst ist ebenfalls multi-threaded.
Das System ist noch zu 33% idle.

Spoiler

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[Token]

@Leo888 @el_malto
hmm, wie gesagt: auf den receivern ist es auch bei mir richtig (grau) ...
aber beim raspi bleibt es grün, und oscam muss restartet werden, damit die Anzeige wieder stimmt.
(ich kann damit aber leben und arbeiten, es ist halt nur aufgefallen!)

 

[Derek Buegel]

Doch, Linux gibt die Gesamtauslastung

Mit "top" vielleicht. Das hat aber "0" Aussagekraft. Versuch es mal mit "htop" (ggf nachinstallieren).

opkg update
opkg install htop

Spoiler

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[inVi`--]

So sieht htop bei mir aus. Icam Sender läuft seit 15 min noch ist die Box nicht eingefroren.

Spoiler: Screenshot htop

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[ackerman76]

Mit "top" vielleicht. Das hat aber "0" Aussagekraft. Versuch es mal mit "htop" (ggf nachinstallieren).

opkg update
opkg install htop

Spoiler

Du musst Regestriert sein, um das angehängte Bild zusehen.

Keine Ahnung, was du sagen möchtest. Auch htop zeigt natürlich je CPU einen Maximalwert von 100% an. In deinem Beispiel also 400%.
Ein Prozess kann diesen Wert auch einzeln erreichen, ein Thread natürlich nur 100%:

 

[ackerman76]

Eine weitere interessante Beobachtung.

Auf dem Ryzen-System, auf dem tvheadend läuft, liegt die CPU-Last des Prozesses bei 1-2%, wenn ich unverschlüsselte Sender schaue. Schaue ich den F1-Kanal, schwankt es zwischen 3 und 3,5%.
Selbst wenn z.B. 7zip auf einen Unterschied im Faktor 15 hindeutet, dürfte die Last auf dem MIPS-System nicht so hoch sein. Ich denke, hier ist noch Verbesserungspotential. Aber erstmal Hut ab für das Erreichte.

 

[frake50]

alle % die anzeigt kein echt werte sind. es hängt an wie Kernel die HD ( Soc ) definiert , Devloper beim Kernel auf HW ( ram / Soc ) anpassen , immer die werte von Kern Anzahl & Mz frq niedrig lassen , nicht wie SOC echte Daten. also ungefähr wenn Soc 4 Kern hat man findt in Kernel nur 2. und wenn Frq zb 2500 man findet 2000 , zerlege dein Kernel und schaue die werte.. sonst nur beobachte die wärme.. weil wärme erster Feind für Soc ist

 

[TuzlaDVB]

Wow, du vergleichst ein Ryzen mit 8 oder mehr Kernen, irgendwas um die 4 GHz Systemtakt, 64 bit Breite, 128bit Multimedia Registern und was weiß ich wieviel Gigabyte RAM ernsthaft mit nem Dual Core MIPS mit 700MHz, 32 bit Breite und 16 MB RAM und erkennst da großes Verbesserungspotential? Respekt!

 

[Deleted member 1100339]

Damit kann man aber Parallel heitzen,ist schon wichtig bei Aktuelle Situation,man spart noch dabei

 

[ackerman76]

Also zunächst vergleiche ich die Leistung eines einzelnen Kerns, es ist also egal, wie viele Kerne die CPU sonst noch hat. Wie ja schon ausgeführt wurde, nutzen die einzelnen Komponenten wohl nur einen Thread (ergo nur eine CPU) für die Aufgabe.
Der 7zip-Benchmark zeigt, dass der Ryzen-Kern ca. Faktor 15 schneller ist. Im Detail kann der Algorithmus von 7zip gut oder schlecht vergleichbar mit der Aufgabe der Emu sein, kann ich nicht beurteilen.
Rechne ich die zwei Prozentpunkte um den Faktor 15 hoch, dürfte die oscam auf dem MIPS-System um 30 Prozentpunkte höher liegen. Sie steigt aber auf 90% an. Hier ist das Verbesserungspotential.

Und ihr könnt es euch gerne selbst ansehen: Ein Thread, der den jeweiligen Kern voll auslastet, belegt diesen zu 100%. Der andere Kern ist dann auch noch voll verfügbar und arbeitet zum Beispiel die enigma2-Threads ab (siehe Screenshot mit sysbench-Prozess und -Threads).
Die MIPS-Box bietet in Summe 200% CPU-Zeit, von der oscam aktuell bei F1 90% benötigt.

 

[icb]

Neben den anderen guten Argumenten von TuzlaDVB hier noch was zu dem Thema:
Ryzen genauso wie Intel CPUs unterstützen SSE2. Vereinfacht ist das genau das gleiche wie NEON. Also Hardwareeinheiten, die bestimmte Dinge sehr schnell ausführen können. Ich finde gerade leider nicht das was ich suche. Aber hier im Commit Test findet sich etwas in die gleiche Richtung:

Sie müssen registriert sein, um Links zu sehen.

sse2 ist gegenüber uint32 doppelt so schnell auf der angegebenen CPU.
(Bei meinen Test war uint64 auf einer Mispel CPU langsamer als uint32. Also anders als bei dem i5 in dem Link.)

Mipsel Boxen unterstützen weder NEON noch SSE2. D.h. sie müssen alles in Software machen. Kompiliere mal deine ffdecsa.dll ohne SSE2 Support und dann vergleiche nochmal.
Mit 7zip würde ich auch nicht vergleichen. Es gibt immer Algorithmen, die besser oder schlechter auf bestimmten CPUs laufen.

Wenn du wirklich vergleichen willst, bau dir ein kleines Programm, das die CSA Entschlüsselung durchführt und lass es auf verschiedenen Plattformen laufen.


Ich sage nicht, dass man das ganze nicht schneller hinbekommt. Aber die Entschlüsselungssache haben sich denke ich schon recht kluge Köpfe angeschaut. Sehr viel läßt sich daran nicht mehr optimieren. Außer vielleicht noch über bestimmte Compilerschalter. Aber davon gibt es hunderte und ich habe nicht die Zeit alle auszuprobieren.

 

[elogugu]

gibt es eine Anleitung für Dream is wie es gemacht wird ?
Und im Board finde ich jur
Die v7 von icb.

Die V7 reicht völlig aus