Posts by ABPSoft

Quote

Original von netman
Psst: Ich verrate dir was, alle müssen neu flashen

Welchen exakten technischen Grund hat das?

Ich frage nur, weil hier gerade ein manueller Upgrade auf 22032011 anstandslos durchgelaufen ist.

Secondstage wurde hochgezogen (da ist es wohl besser, genau auf die Ausgaben zu achten), Kernel und Driver sind neu, Aufnehmen & Wiedergeben geht (letzteres war wohl die Crux bei Secondstage/Driver/E2-Mischmasch).

Mir ist klar, dass ihr das nicht supporten wollt - ich sehe aber schon noch einen Unterschied zwischen "das geht zwar, aber wenn Du nicht selber weißt, wie, dann flashst Du besser neu" und "das geht nicht, weil dann XYZ passiert/nicht passiert". Insofern wäre ein klarer Warnhinweis angebracht, wenn es mal keinesfalls upzugraden geht - mit 'ner nachvollziehbaren Begründung. Man will die Kiste ja nicht bricken

Thanks,
Andre.

Hi,

ich bemerke gerade eine zunehmende Zombie-Horde:

root@dm800:~# ps | grep Z | grep -v grep | wc -l
134

Nach etwas Rumgesuche wird klar:

Die Zombies werden mehr, sobald die Infobar aktiv ist. Sekündlich. Mit ein paar flott nacheinander abgesetzten ps und etwas gegurke in /proc lässt sich zeigen, dass es Child Processes von /usr/bin/gdaemon sind, die von der HDD Temp Anzeige getriggert werden:

3552 root      2532 S    sh -c smartctl -d ata -A /dev/sda 
 3553 root      3920 R    smartctl -d ata -A /dev/sda

sieht anschließend so aus

3552 root         0 Z    [sh]

und bald sind es wieder ein paar mehr.

Sieht also aus, als würde gdaemon seine Children nicht ordentlich reapen.

root@dm800:~# opkg search /usr/bin/gdaemon 
geminitools - 0.23-r0

Mir scheint, dass das neu ist, gestern habe ich das Upgrade auf 0.24-r10 eingespielt. Ich bin aber auch vorhin mal der Empfehlung gefolgt, diverse Caches und Picons auf einen USB-Stick auszulagern, damit ist also noch was anderes geändert worden. Und wenn es um HDD Temp geht, mag die Anwesenheit eines /dev/sdb schon irgendwas beeinflussen können - wenn auch eigentlich nicht das child reaping in gdaemon.

Sieht das noch jemand?

Image ist das iCVS vom Februar.

BTW, hatte nach dem Upgrade gestern beim Reboot nach dem allerersten Bootlogo kein Bild mehr, die Kiste war fast tot aber nicht ganz (Spinner kam noch, Menü ging noch). Nach einem Power Off und 5min Kurzurlaub ging dann aber erstmal wieder alles.

TIA,
Andre.

Quote

Original von Binsche

Ich habe keinen Vergleich aufgestellt,

Huch, das war mehr auf mich gemünzt. Und ich war verwirrt

Quote

sondern versucht deine Frage nach der Signalstärke (RF-Power) damit zu beantworten. Wir in der Antennen/Empfangstechnik sprechen eben nicht von dBm, sondern von den etablierten dBµV.

Ja, dass das in diesem Teil der HF-Welt der etablierte Bezugspegel ist, ist mir inzwischen auch klar. In dem Teil, mit dem ich zu tun habe (WLAN), denkt halt jeder (Hersteller von APs und WLNICs, Mess- und Surveysoftware, mein Spectrum Analyzer etc) in dBm

Quote

Abgesehen davon kann man dBm nach dBµV herrlich umrechnen (und umgekehrt), in Abhängigkeit von der Eingangsimpedanz
http://www.itwissen.info/defin…oV-decibel-microvolt.html
Das nochmal zum Pegel auf der Leitung bzw zur Signalstärke...

Thanks, ich wollte ja Aufklärung

Damit ist mir klar, wo mein Thinko lag: natürlich sind die dB aus Feldgrößenverhältnissen mit denen aus Leistungsgrößenverhältnissen direkt vergleichbar, genau deswegen werden Erstere ja anders gebildet (quadrieren der Feldgrößen bzw. 20log10 statt 10log10). Damit ist es auch völlig Wurst, ob wir eine SNR aus dBm oder dBµV ermitteln. Kommt davon, wenn man jahrelang nur noch mit Leistungsgrößen operiert und in einer dunklen Ecke der Erinnerung rumspukt, dass bei Feldgrößen irgendwas anders war mit 20-rule und so.

Quote

Für 4096QAM liegt (nach meinem aktuellen Wissensstand) noch keinerlei Wert fest, wobei man davon ausgehen darf, dass dieser oberhalb von 40dB MER liegen würde

Die 35dB kamen mir in einem c't-Artikel zu DVB-C2 unter, der wirkte gut recherchiert.

Thanks,
Andre.

Quote

Original von ibrahim
du kannst gerne in deinem alten icvs probieren, in den opkg config dateien die feed url der icvs spezifischen feeds von 23122010 auf 01022011 zu ändern, und das update laufen zu lassen.
wenn du aber größere probleme dadurch hast, auf jedenfall neu flashen!

Ehe ich neu flashe, dachte ich, probierste das mal. Mit 17MB frei also die Feeds angepasst, opkg update && opkg upgrade. Das ging 99% völlig glatt, nur das CrossEPG-Paket hatte einen MD5sum-Fehler. Da ich das eh loswerden wollte, half ein beherztes opkg remove. Danach noch ein wenig Unsicherheit, weil unter /boot jetzt ein Symlink ins Leere zeigt. Aber autoexec.bat verweist auf vmlinux.gz, und das ist da. Also reboot. Und siehe da: Box kommt mit neuem Kernel wieder hoch und alles ist easy & roger - und noch 15MB sind frei.

Ich würde das als Erfolg deklarieren, aber ich mach auch alle Nase lang Upgrades auf diversen Debian-Kisten und hatte einen Exit Plan (neues Image flashen). Ich glaube mal, das Hauptproblem hier ist Testing von Rolling Upgrades auf Verträglichkeit mit allen möglichen vergurkten Nutzerkisten (wenig Flash frei, Pakete von sonstwo drauf) sowie Support im Fehlerfall. Wer sich selbst zu helfen weiß, kann das aber versuchen und kriegt es sehr wahrscheinlich auch hin. Und wenn es doch mal schiefgeht, flashen geht immer noch. Im Release Announcement darf also gern auch der Feed Tag stehen.

Ich frage mich bloß noch, was ich in /etc/version reinschreib

HTH,
Andre.

Re kodo,

Quote

Original von kodo
Das ist der Ablesewert aus dem WebIf meiner 7025. Und ja, da steht dB

Ich glaub Dir, dass das da steht. Ich glaub bloß nicht, dass es irgendwie mit der Realität korreliert

Ich hab mal im WebIf meiner 800C geguckt, da steht gerade 41.73dB. Das ist identisch mit der Anzeige in der Infobar (danke übrigens für die sechs konfigurierbaren Sensorfelder an iCVS, GP3 und JD, das ist richtig cool). Ich würde jetzt vermuten, dass die 7025 da vielleicht irgendwas verwurschtelt. Was steht denn bei SNR %, AGC und BER?

Wie Rene schon dargelegt hat, sind Werte jenseits von 50dB SNR im Kabel eigentlich physikalisch fast unmöglich. Das BK ist ein riesiges Antennensystem, das großflächig jede Menge "Dreck frisst", den dann mit Verstärkern auch noch im Pegel anhebt und deswegen mit Müh und Not auf SNRs über 40dB getrimmt werden muss. Es rauscht analog z.B. auch signifikant mehr als ein gutes terrestrisches Signal (hat mich damals sehr gewundert, als es das noch gab - eine Grabberkarte offenbarte das ganze Grauen erst so richtig, und wenn ich heute mal aus Versehen am TV auf analog schalte könnte ich heulen).

Ok, wenn man jetzt mit FTTH versorgt würde und nur ein Gerät mit wenigen Metern höchstwertigem Kabel direkt hinter dem Glas-Koax-Umsetzer angeschlossen hätte, alle anderen Ports sauber terminiert wären etc pp - oder ein eigener Kabelkopf in einer kleinen feinen (G)GAA - nee, nicht wirklich 78dB. Du hast nicht zufällig noch 'nen anderen Receiver zwecks Vergleich?

Nix für ungut,
ein Skeptiker.

Ahmd,

Quote

Original von Binsche
Ich gehe mal davon aus, der kodo meinte ein SNR von 78%

Ich glaube da eher an einen Anzeigefehler.

Quote

Im Übrigen kommt es bei DVB-C auf die verwendete QAM an. QAM64 kommt mit einem niedrigeren SNR aus. QAM256 ist da etwas anspruchsvoller und braucht ein paar dB SNR mehr, um die gleiche BER zu erzielen (Abhängig vom KNB, wie er einspeist)

Yep, so isses. AFAIK braucht man für DVB-C mit QAM256 (was wir so momentan meistens verpasst bekommen) mindestens 30dB SNR, um BER von praktisch 0 zu erreichen. Deckt sich perfekt mit meinen Beobachtungen, darunter geht die BER stetig in die Höhe, bis die FEC dann irgendwann versagt.

Mit DVB-C2 und QAM4096 sind dann schon 35dB Pflicht. Ist aber noch Zukunftsmusik.

Quote

Die Norm EN 50083-7 fordert einen Pegel an der TAD bei DVB-C und QAM64 zwischen 47-67dBµV, welchen man nur mit einem (digitalen) Messgerät ermitteln kann

Gefährlich wird es, wenn wir ein- und zweidimensionale dB vergleichen. Ich gehe bei solchen Angaben im HF-Umfeld eigentlich davon aus, dass man sich auf Leistungsflussdichten bezieht, also zweidimensionale Größen. Damit gilt dann 10dB = eine Größenordnung und 78dB SNR klingen sehr unwahrscheinlich. Aber wenn im Kabel-Umfeld oft mit der reinen elektrischen Feldstärke operiert wird, ist das natürlich eine eindimensionale Größe (geht als ein Faktor in die Leistung ein) und damit 20dB = eine Größenordnung. Kläre mich mal jemand auf, was wir hier anzeigen. Rein gefühlt kommt man hier bei 30dB SNR mit QAM256 (ohne OFDM) auf ca. 50Mbps, das kann eigentlich nur auf 'ner Leistungsflussdichte (also dBm) beruhen, nicht auf dBµV...

Quote

Nein

Hilf mir mal: Steht AGC für automatic gain control? Dann sollte sie zumindest ein Hinweis auf den Pegel sein. Ich kann das hier ganz gut nachvollziehen, ich sehe AGCs von 39% bis 48% und die Multiplexe mit dem schlechtesten Pegel (die beim Ausfall letztens komplett weg waren) haben die höheren AGC-Werte. Das ist natürlich nur qualitativ, Zahlen hat man da noch lange nicht (es sei denn, ein Entwickler sagt uns mal, was die AGC da nach welcher Formel auswertet, um zu % zu kommen - und % von was, wie ich mich gerade auch bei SNRs immer frage).

Ansonsten: Wer misst, misst Mist

Thanks,
Andre.

Quote

Original von Freeeeak
Problem:
gestern habe ich im Schlafzimmer noch TV gesehen (7025) und etwas aufgenommen. Heute Morgen kann ich nur noch die öffentlich Rechtlichen, ARD, ZDF, ARTE Neo und so empfangen, alles was "privat" ist, nicht mehr. Dieses auch, wenn ich die KD D02 Karte rausziehe.

Das ist nicht zufällig eine Kabel Digital Free?

Meine war im Laufe des 09.02.2011 auch dunkel geworden. Auch im ollen Humax. Das ist genau fünf Jahre nachdem sie von KDG für KD Free freigeschalten wurde. Ich hatte schon Panik, dass diese gute alte einmalige Freischaltung für die Ewigkeit jetzt Futsch wäre und ich jetzt Abogebühren für das Unterschichten-TV abdrücken darf. Bei KDG angerufen, vom IVR durchrouten lassen, Kartennummer eingetippt (ging aber nicht automatisch), verbunden worden, die freundliche Dame am anderen Ende hat 'ne neue Freischaltung eingekippt (murmelte noch was von "das is ja ne alte Karte" - wer hat schon noch ne K02) und Sekunden nach dem Auflegen wurde es wieder hell.

Ich würde mal vermuten, die haben eine Verfallszeit von fünf Jahren auf Karten, um Leichen aus dem System zu bekommen. Leider erst zwei Tage später gemerkt, einige GB schwarzes Video auf der Platte...

HTH,
Andre.

Hi,

Quote

Original von pudel211
bei installierten Modulen (siehe oben) kann man mit

Code

echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

die CPU auf 37 MHZ

und mit

Code

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

die CPU auf 297 MHZ zwingen

Display More

Warum nicht einfach "ondemand" nehmen, statt mit umständlichen Usermode-tools rumzugurken? Hart runterzwingen ist bekanntlich wenig hilfreich, die optimale Energiespar-Strategie ist "race to completion", das braucht einen zackig reagierenden dynamischen governor. Und den haben wir ja:

root@dm800:~# opkg install kernel-module-cpufreq-ondemand
Installing kernel-module-cpufreq-ondemand (2.6.18-r9.0) to root...
Downloading http://download.blue-panel.com/icvs/dm800/opendreambox/1.6/feed/01022011/dm800/kernel-module-cpufreq-ondemand_2.6.18-r9.0_dm800.ipk
Configuring kernel-module-cpufreq-ondemand


root@dm800:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
performance


root@dm800:~# modprobe cpufreq_ondemand


root@dm800:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
ondemand performance


root@dm800:~# echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor


root@dm800:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Huch?

root@dm800:~# dmesg | tail -1
[ 6858.207000] ondemand governor failed to load due to too long transition latency

Argh. Doch nicht so einfach. Hardware zu lahm für schnelles Umschalten. Und "conservative" lässt sich auch nicht aktivieren, hier kommt noch nicht mal 'ne Meldung...

ISC - Bleibt wohl doch nur "usermode"

Andre.

Quote

Original von kodo
Bei mir, auch Kabel, ist die SNR auf ~78dB, also passt bei dir etwas nicht. Kabel, Dose, Verstärker usw. . Also, entweder Service rufen falls Mietwohnung oder selber schrauben.

78dB? Würde ich ins Reich der Märchen, Fabeln und fehlerhaften Anzeigen verweisen. Vielleicht mit 'nem Messsender und 2m Messkabel direkt in den Tuner, aber nicht hinter einem gewöhnlichen HÜP (womöglich noch mit Mietshaus-Baumverteilung dahinter). Kabel rauscht üblicherweise wie blöde. Wir reden hier von drei Größenordnungen mehr Rauschabstand als den schon als ideal anzusehenden 50dB.

Ich hatte hier vorige Woche unfreiwillig ein wenig Testbetrieb, weil der Pegel am HÜP durch einen Defekt Upstream versackt war. Ich kann daher ziemlich sicher sagen, dass bei SD leichte Probleme beginnen, wenn man deutlich unter 30dB SNR kommt (habe Werte von 21 bis 25 gesehen) und gleichzeitig die BER vom fünfstelligen in den sechsstelligen Bereich geht (80000 auf P7S1 noch Ok, 600000 auf ARD SD praktisch kein Bild mehr). Im Normalbetrieb schwanken die Sender hier von 29dB SNR bei einer BER von ca. 100 und 41dB bei praktisch stabiler BER von 0. Und auch die schlechtesten sind noch stabil.

BTW, die Signalstärke wäre wirklich mal interessant (die SNR ist zwar wichtiger, aber man will ja auch beurteilen können wie die zustande kommt). Kann man die irgendwo anzeigen? Oder aus der AGC darauf schließen? Ich habe mal unter /proc/stb gekramt, da fand sich aber nix passendes (iCVS 20101223).

HTH,
Andre.

Quote

Original von Schaedelmeister
Habe mal bissel getestet. Denke das j6 wird es werden, oder?!

Lahm

Das hier war ein Lappie mit Dualcore:

Quote

NOTE: Running task 2278 of 2278 (ID: 0, /home/beck/devel/dreambox/dm800/openembedded/recipes/images/dreambox-image.bb, do_build)
NOTE: Tasks Summary: Attempted 2278 tasks of which 0 didn't need to be rerun and 0 failed.

real 90m44.425s
user 215m28.111s
sys 39m41.397s

Display More

CPU: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
RAM: 8GB (2x4GB interleaved)
HD: INTEL SSDSA2M160G2GC
OS: Debian Squeeze

BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"

Sources waren schon da, nur enigma2(-plugins) wurde neu von schwerkraft gezogen, aber dank der vier Tasks ging das unter (aller vier Hardware Threads waren trotzdem am Anschlag).

So'n Quadcore muss da doch noch was reißen, zumal die CPU-Zeiten da schon besser aussehen, nur real fällt ab?

HTH,
Andre.