oscam-1.20_svn-r11734-799-aarch64-dreambox-linux-gnu-ssl-libusb-ICAM-V9-no_neon-demuxer_fix_cak7-nv5

[Leo888]

Ich habe mal getestet, was bei mir auf der DM two mit GP4.2 im AIO Image besser läuft und habe mir eine OSCAM selber gebaut die wie folgt erstellt wurde.

oscam_emu.patch (ohne ICAM)
oscam_emu_icam_dvbapi_radegast_v9_no_neon-no-flags.patch
4-demuxer-err.patch

Compiler Option: O2

Diese habe ich mit der auf dem Nobody Feed liegende OSCAM-ICAM verglichen und beide laufen ohne Ton/Bild oder sonstige Probleme. Das Hämmern hatte ich vorher schon so selten, dass ich dazu vielleicht in ein paar Wochen was sagen kann.
So ziemlich alle anderen Compiler Optionen hatten Mikro Freezer

Untern Strich kann ich somit die OSCAM direkt vom Feed, für alle die es einfach und immer aktuell haben wollen empfehlen.
Den Verdacht, dass die Feed OSCAM gut läuft, hatte ich vorher schon, da ich mit der bis jetzt immer gute Erfahrungen gemacht hatte und eigentlich nur selber baue, weil es sehr einfach ist und ich der Meinung bin, dass ein bin was nur beinhaltet was ich wirklich brauche, erstens kleiner ist und zweitens, was nicht da ist, wird auch nicht stören wird

Wer die CAMs vom Nobody Feed erstellt, weiß ich nicht, aber hier mal ein Dank an den Unbekannten und natürlich an alle hier, die Ihre Freizeit für die Optimierung und Hilfe bei dem Thema opfern

@60plus
Die CPU Last sollte bei ner one/two relativ egal sein, da reichlich vorhanden und das Thema bei den arm Boxen mit neon schon gezeigt hat, dass selbst mit neon, was in der Tat was bewirkt die Last nur geringfügig weniger war.
Bei mir mir läuft auf der Box noch Hyperion fürs Ambilight und das hat ne höher Last als die schlechteste OSCAM und die Two langweilt sich trotz Hyperion und OSACM-ICAM


Edit:
kleiner Nachtrag zu der DM900
Ich habe einige Bekannte, die die DM900 mit original OS, GP4.2 und Nobody Feed nutzen. Da läuft überall die OSCAM-ICAM direkt vom Feed. Auf Nachfrage ob was aufgefallen ist, war allgemein die Antwort "der Himmel läuft plötzlich wesentlich besser".

 

[Alex]

Compiler Option: O2

Was setzt du da wo genau?

 

[Leo888]

/s3_releases/support/configs/compiler_option

Spoiler

-O0 optimization for time
-O2 optimization (oscam default)
-O3 optimization (smaller size)
-Os optimization for code size

Das steht normal auf O1, was es in der Liste nicht mal gibt, weshalb ich hier dann auf O2 umstelle was eigentlich nach der Liste eh default sein sollte, aber nie ist, wenn man s3 direkt von Git lädt.

 

[Alex]

Ich baue ja ohne S3 und in der Makefile steht ja schon

# Compiler optimizations
CC_OPTS = -O2 -ggdb -pipe -ffunction-sections -fdata-sections

 

[Leo888]

Ich schreib's ja, dass das normal eh default auf O2 stehen sollte und ich mit der Änderung lediglich den default Wert wieder herstelle
Ich hatte zu Beginn auch ohne s3 gebaut, kann aber mittlerweile kein Unterschied an den bins mehr feststellen und somit ist für mich s3 der bequemere Weg.

 

[ghost0815]

-O1 Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function.
With -O, the compiler tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time.

-O turns on the following optimization flags:

-fdefer-pop
-fmerge-constants
-fthread-jumps
-floop-optimize
-fif-conversion
-fif-conversion2
-fdelayed-branch
-fguess-branch-probability
-fcprop-registers

-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.

-O2 Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. The compiler does not perform loop unrolling or function inlining when you specify -O2. As compared to -O, this option increases both compilation time and the performance of the generated code.
-O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags:

-fforce-mem
-foptimize-sibling-calls
-fstrength-reduce
-fcse-follow-jumps -fcse-skip-blocks
-frerun-cse-after-loop -frerun-loop-opt
-fgcse -fgcse-lm -fgcse-sm -fgcse-las
-fdelete-null-pointer-checks
-fexpensive-optimizations
-fregmove
-fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec
-fcaller-saves
-fpeephole2
-freorder-blocks -freorder-functions
-fstrict-aliasing
-funit-at-a-time
-falign-functions -falign-jumps
-falign-loops -falign-labels
-fcrossjumping

Please note the warning under -fgcse about invoking -O2 on programs that use computed gotos.

-O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -fweb, -frename-registers and -funswitch-loops options

 

[kitte888]

so habe jetzt auf der dm900 mit NN2 ein wenig probiert

verschiedene Toolchains , armdream , dreamarm und solo4k , habe ich keine unterschiede bemerkt

compieliern O0 bis Os , O0 hat eine hohe cpu last von 20-70 , alle anderen ca 5

beim umschalten mal kein bild , denke man muss den bufferv3 ton patch nehmen , mit dem war es dann weg

bild steht kurz nach dem umschalten , keine lösung gefunden

demuxer laufen 2 , ist mit dem demuxer-err patch weg

hatte das gefühl das wenn mit neon die cam auch mal kpl weg ist

mit no neon ist das nicht passiert

also emu,icam,buffer und demuxer patch und no neon

habe auch mal eine version no neon mit upx best gebaut sieht auch gut aus

mal testen

werde mir das jetzt mit opentav mal ansehen , aber da ging es immer

 

[Alex]

also emu,icam,buffer und demuxer patch und no neon

Ja so habe ich es auch. Aber der Buffer-Patch macht auf der ONE/TWO Probleme. Er dekodiert nicht und man hat so kein Bild. Deshalb habe ich den für mich verworfen

 

[kitte888]

laut @60 plus im post 186

ist es auf der one auch so ton und demuxer

 

[Alex]

Funktioniert bei mir nicht. Kann später auch mal ein Log posten

 

[Leo888]

Ja so habe ich es auch. Aber der Buffer-Patch macht auf der ONE/TWO Probleme. Er dekodiert nicht und man hat so kein Bild. Deshalb habe ich den für mich verworfen

Auf der one/two macht der Buffer Patch auch überhaupt kein Sinn, da hier nie ein Problem beim Umschalten mit Bild und Ton vorhanden war, zumindest mal auf dem AIO Image.
Ganz im Gegenteil, das Problem kommt mit dem Buffer Patch und die Umschaltzeiten sind damit natürlich auch doppelt so hoch.

Wie oben schon geschrieben, hatte eh noch nie wirklich Probleme auf der two, aber den wilden Demuxer im Log. Mit dem, Demuxer Patch ist das nun auch sehr ruhig geworden und ich bin recht zuversichtlich, dass das einzige Problem mit dem Hämmern, welches ich auf der two sehr selten hatte, damit nun auch Geschichte sein wird.

 

[Hannes0009]

Also hab das auf meiner 900er grad getestet.
Leider habe ich meistens nur Ton und kein Bild. (Die Datei von Kitte)

Image ist oatv

 

[kitte888]

also der ton patch mit timeout 0 ist beim umschalten genauso schnell wie ohne

@Alex
im S3 wird ja das für icam gesagt

# standard
#cc_opts="-ggdb -pipe -ffunction-sections -fdata-sections -o nodeadcode"

# das fuer ICAM
cc_opts="-ggdb -pipe -ffunction-sections -fdata-sections -funroll-loops -fomit-frame-pointer -fno-schedule-insns"

werde mal deine testen

 

[ghost0815]

im S3 wird ja das für icam gesagt

Ja, weil man die default Werte in S3 ändern soll, die den icam-patch " übergehen"

ICAM Patch oscam-emu

Vielen Dank @SaMMyMaster Konnte jetzt im Gegensatz von V5 auf V6 keine wirkliche Verbesserung erkennen. Wie aber von @icb bereits erwähnt, profitieren ohnehin die MIPS Boxen am meisten.

www.digital-eliteboard.com

 

[kitte888]

also mal mit alex einstellungen gebaut
cc_opts="-ggdb -pipe -ffunction-sections -fdata-sections
mit neon cpu 30
ohne neon cpu 5

ist bei dem nicht so

# das fuer ICAM
cc_opts="-ggdb -pipe -ffunction-sections -fdata-sections -funroll-loops -fomit-frame-pointer -fno-schedule-insns"


@Hannes0009 welche datei hast du den genommen

also auf openatv habe ich keine probleme auf der dm900

also hat image schon ein einfluß