Lösung für viele Ruckelprobleme! -> Ins Image aufnehmen?!

[AudioSlyer]

mach aus der 500 ene 64

[Innuendo]

mach aus der 500 ene 64

dann macht die nokia600 extrem viele fehler - mit 100 läuft es besser. nokia500 auch mit 64 ziemlich gut. Hast Du auch andere Werte verändert?

Innu

[quarkmark]

Hallo!
Also, ich glaube, diese Diskussion hat sich erstmal erledigt, jedenfalls fürs JTG-Image, denn dort ist momentan kein Download mehr möglich.
Bis auf Weiteres eingestellt.
Ich verstehe zwar nicht warum, aber es ist so.
Wie geht's weiter?
Gruß,
qm

[palace]

Heißt das, dass du mit deiner config ruckelfrei aufnehmen und abspielen kannst, dass es dich aber stört, wenn sync ein ist?
Ich spiele mit dem Gedanken, mir auch ein ide interface zuzulegene, aber halt nur, wenn es auch möglich ist, alle sender aufzuzeichnen.

Genau so ist es!

[palace]

mach aus der 500 ene 64

Tja, wenn ich Images bauen könnte (was ich mir jetzt wohl dringend mal anschauen sollte) Deswegen frag ich euch ja, ob ihr da schon probiert habt...
Also 64 für Nokia 500 okay, ca. 100 für 600er... Danke!

[AudioSlyer]

dann teste ich auch mal die 100

[BigHardy]

dann teste ich auch mal die 100

Ich würde mittesten, wenn ich ein entsprechendes 2x-Image hätte/bekommen würde

[palace]

dann teste ich auch mal die 100

Ich würde mittesten, wenn ich ein entsprechendes 2x-Image hätte/bekommen würde

128 klingt irgendwie Technischer *g* -> 512KByte; 64 -> 256KByte
Bei ca 1,5MByte/Sek Schreibgeschwindigkeit (ext3) wären das ca 0,3 bis 0,35 / 0,15 - 0,16 Sekunden

Mit HDD Cache enabled (8MByte) dürfte das Wegschreiben desselben etwa 0,5 bis 1 Sekunde dauern (angenommene 8 bis 16 MByte/s bei wenig fragmentierter HD).
Hier ist die Überlegung was passiert, wenn der HDD Cache gerade geschrieben wird während die Box ebenfalls schreiben will?

Stelle mich ebenfalls zum Testen zur Verfügung.

Wurde an den anderen Werten schon gefeilt?

[Innuendo]

Wurde an den anderen Werten schon gefeilt?

ein bissl getestet - besser gesagt herumgespielt - habe ich: ich habe keine "perfekte" einstellung gefunden. wahrscheinlich wird das entweder nur was mit einem oszi oder jede box reagiert wieder anders. besonders die nokias (wie immer).
innu

[palace]

Wurde an den anderen Werten schon gefeilt?

ein bissl getestet - besser gesagt herumgespielt - habe ich: ich habe keine "perfekte" einstellung gefunden. wahrscheinlich wird das entweder nur was mit einem oszi oder jede box reagiert wieder anders. besonders die nokias (wie immer).
innu

Hi, könntest Du oder AudioSlyer - wenn es keine Nebenwirkungen hat - das mal einchecken?

[AudioSlyer]

Einchecken? Darf ich nicht, würd ich auch nie machen

[just_me]

Wurde an den anderen Werten schon gefeilt?

... wahrscheinlich wird das entweder nur was mit einem oszi oder ...

Es gibt auch eine Chance ohne Oszilloskop, wenn man die Software modifiziert:)

Hierzu müsste, am besten im Block Layer (notfalls aber auch im IDE Treiber) mitgezählt werden, wieviele Blöcke bei dem jeweiligen Timer Tick geschrieben (oder auch gelesen) wurden.

Der Code könnte ungefähr so aussehen:

Code: Alles auswählen

/* all bugs are mine! */
static int jiffies_last_time_I_was_called;
static int number_of_calls_this_jiffy = 0;

...

if( jiffies_last_time_I_was_called != jiffies ){
        printk("RW: %lu %u", jiffies_last_time_I_was_called, number_of_calls_this_jiffy);
        number_of_calls_this_jiffy = 0;
        jiffies_last_time_I_was_called = jiffies;
}
number_of_calls_this_jiffy++;

Es wäre deswegen gut, dass dieser Code "oberhalb" des IDE Treibers eingefügt würde, weil dann gleich mitgetestet werden könnte, ob der MMC / SD Card Treiber beim Lesen unter dem gleichen Problem leidet.

Für die SD Karte wird ja berichtet ( http://forum.tuxbox-cvs.sourceforge.net ... c&start=37 ), dass die MP3 Wiedergabe zeitweise stockt. Und dass, obwohl die Lesegeschwindigkeit von SD Karte etwa einen Faktor 10 höher ist als die MP3 Wiedergabe erfordern würde!!

Hier drängt sich die Vermutung auf, dass ab und zu ein "Read ahead" in die Quere kommt und auf Verdacht eine grosse Anzahl von Blöcken von der SD-Karte gelesen wird.
Macht bei Systemen Sinn, bei denen die Übertragung per DMA abläuft. Aber ohne DMA läuft dies eben nicht im Hintergrund ab und die Rechenleistung fehlt an der Stelle an der sie ganz konkret gebraucht wird...

Vielleicht löst sich, wenn MP3 von der SD-Karte ohne Aussetzer abgespielt werden kann, das Ruckeln bei der Wiedergabe von Videodaten unter XFS/JFS/whatever ( http://forum.tuxbox-cvs.sourceforge.net ... 6&start=12 ) ganz von selbst?

Frieder

[Houdini]

die "richtige" Lösung sieht so aus:
- in der linuxconfig

Code: Alles auswählen

CONFIG_SYSCTL=Y

setzen.
- (optional) in der busyboxconfig

Code: Alles auswählen

CONFIG_BB_SYSCTL=Y

setzen.

(optional) dann werden mit sysctl -a alle änderbaren Kernelparameter angezeigt
dann stehen in /proc/sys/ alle änderbaren Kernelparameter

diese (incl. (optional)vm.bdflush bzw. /proc/sys/vm/bdflush) können entsprechend abgeändert werden.
Soweit die Theorie, vielleicht kann ein Imagebauer mal nen snap mit den aktivierten Parametern machen, damit ihr euch austoben könnt

Houdini

[palace]

@AudioSlyer&Innuendo:
Habt ihr mittlerweile experimentell sinvolle Werte gefunden?

[palace]

Code: Alles auswählen

fs.xfs.stats_clear = 0
fs.xfs.rotorstep = 1
fs.xfs.inherit_nosymlinks = 0
fs.xfs.age_buffer_centisecs = 1500
fs.xfs.xfsbufd_centisecs = 100
fs.xfs.inherit_noatime = 1
fs.xfs.inherit_nodump = 1
fs.xfs.inherit_sync = 1
fs.xfs.xfssyncd_centisecs = 3000
fs.xfs.error_level = 3
fs.xfs.panic_mask = 0
fs.xfs.irix_symlink_mode = 0
fs.xfs.irix_sgid_inherit = 0
fs.xfs.restrict_chown = 1
fs.xfs.refcache_purge = 32
fs.xfs.refcache_size = 128

Hier könnte man evtl. auch noch was drehen...

[palace]

{5 500 0 0 500 3000 100 0 0} steht zum testen...

nfract; /* Percentage of buffer cache dirty to activate bdflush */
- der eigentlich interessante Wert.
wie gross der Cache jeweils ist, entgeht mir leider...
wählt man diesen Wert kleiner, werden öfter kleinere Mengen an Daten geschrieben.

ndirty; /* Maximum number of dirty blocks to write out per wake-cycle */
- Diesen Wert zu verringern dürfte nur bei genauem Messen etwas bringen; man kann damit zwar die Schreibzyklen verkürzen, dies bringt aber beim Streamen wenig, da der Cache wächst und irgendwann zwangsgeschrieben werden muss

int dummy2; /* old "nrefill" */
int dummy3; /* unused */

int interval; /* jiffies delay between kupdate flushes */
- betrifft "nur" Metadaten

int age_buffer; /* Time for normal buffer to age before we flush it */
- wenn idle

int nfract_sync; /* Percentage of buffer cache dirty to activate bdflush synchronously */
- sync ist nicht gewollt, also 100%; 0 -> sync

int nfract_stop_bdflush; /* Percetange of buffer cache dirty to stop bdflush */
- 0 damit der komplette Cache geschrieben wird

int dummy5; /* unused */

[TDFKAOlli]

Moin,

der Thread hat ja schonmal ein wenig weitergeholfen. Folgende Einstellungen laufen am besten bei meiner Nokia Kabel 2xI mit SAMSUNG SP2514N 250GByte Platte:
- Sync aus
- write cache der Platte aus
- /bin/mount -t ext3 -o noatime,nodiratime,data=writeback /dev/ide/host0/bus0/target0/lun0/part2 /hdd

Vorher nur Probleme gehabt mit rucklern in der Aufnahme.

So, jetzt wäre schön, wenn ich Ton hätte beim abspielen der .ts und ein Bild auf dem Fernseher beim aufzeichen.
Beim Ton habe ich am PC mit dem Media Player Classic mal geschaut was drin ist. Anscheinend ist nur AC3 Ton aufgezeichnet worden. Bei den Tonspureinstellungen habe ich alles auf "Ja". Beim Yadi-Image 2.1.0.11 hatte ich auch ein Bild, selbst beim aufzeichnen. Ich bin jetzt beim 2.2.0.0.
Wenn das jetzt noch funktionieren würde, wärs perfekt.

Gruß, Olli