DrStoned hat geschrieben:Den neuen Snap und einen Testsnap, der zusätzlich noch Günthers neue Aufnahmeoptionen enthält, gibts ab sofort im JtG-Forum.
Bitte daran denken, dass Ihr im JtG-Forum angemeldet und eingeloggt sein müsst, um die Sachen herunterladen zu können.
Greetz von DrStoned
Das liegt daran, daß die Datei mit aus gutem Grund mit O_SYNC geöffnet wird (ist defaultmäßig aktiviert im Menü IIRC). Das heißt immer wenn ein paar Bytes aus dem Ringpuffer auf die Disk geschrieben werden, paßt der Kernel gleich die Inodetables etc. mit an (die liegen auf nem anderen Bereich der Platte, deshalb die Kopfbewegungen).palace hat geschrieben:Bevor ich einschlafe und es wieder vergesse:
Da die Box derzeit offen vorm TV steht, bin ich von "seltenen" Geräuschen "aufgeschreckt": Dauerkopfbewegungen der HDD
Hat denn mal jemand probiert, die bdflush Parameter auf das IDE2 Interface abzustimmen?palace hat geschrieben:Langsam gehen mir die Ideen aus
Code: Alles auswählen
Leider ist es so: Mit Sync OFF -> viele Overflows...union bdflush_param {
struct {
int nfract; /* Percentage of buffer cache dirty to
activate bdflush */
int ndirty; /* Maximum number of dirty blocks to write out per
wake-cycle */
int dummy2; /* old "nrefill" */
int dummy3; /* unused */
int interval; /* jiffies delay between kupdate flushes */
int age_buffer; /* Time for normal buffer to age before we flush it */
int nfract_sync;/* Percentage of buffer cache dirty to
activate bdflush synchronously */
int nfract_stop_bdflush; /* Percetange of buffer cache dirty to stop bdflush */
int dummy5; /* unused */
} b_un;
unsigned int data[N_PARAM];
} bdf_prm = {{30, 500, 0, 0, 5*HZ, 30*HZ, 60, 20, 0}}; Code: Alles auswählen
} bdf_prm = {{30, 500, 0, 0, 5*HZ, 30*HZ, 60, 20, 0}};Code: Alles auswählen
30 - vermutlich OK
500 - 500 Blöcke am Stück schreiben? Autsch. Anpassen!
0 - OK
0 - OK
5*HZ - entspricht 5 Sekunden. Zu selten! Anpassen.
30*HZ - entspricht 30 Sekunden. Zu selten! Anpassen.
60 - könnte verm. höher sein, synchrones Schreiben sollte ja vermieden werden. Anpassen!
20 - evtl. zu klein. In Verbindung mit den 60 oder 30 oben ist bdflush womöglich zu lange am Stück aktiv.
Code: Alles auswählen
MMM_______MMMM______MMMM______MMM_______MM________MMMM
^ ^ ^ ^ ^ ^
0ms 10ms 20ms 30ms 40ms
Code: Alles auswählen
/bin/mount -o remount,noatime,nodiratime /dev/ide/host0/bus0/target0/lun0/part2 /hddCode: Alles auswählen
/bin/mount -o remount,noatime,nodiratime,sync /dev/ide/host0/bus0/target0/lun0/part2 /hdd
)Code: Alles auswählen
CPU states: 7.8% user, 91.9% system, 0.0% nice, 0.3% idle
Mem: 30696K total, 30048K used, 648K free, 4928K buffers
Swap: 1028148K total, 17628K used, 1010520K free, 4628K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1682 root 10 0 0 0 0 SW 49.3 0.0 1:22 kjournald
1724 root 11 0 424 420 340 R 29.1 1.3 0:08 dd
1712 root 18 0 804 804 644 R 12.9 2.6 0:07 top
1666 root 9 0 6116 3048 2024 S 4.5 9.9 0:21 neutrino
4 root 9 0 0 0 0 SW 2.7 0.0 2:15 kswapd
3 root 19 19 0 0 0 SWN 0.4 0.0 2:33 ksoftirqd_CPU0Code: Alles auswählen
/bin/mount -t ext3 -o noatime,nodiratime,data=writeback /dev/ide/host0/bus0/target0/lun0/part2 /hddCode: Alles auswählen
<6>EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
<6>EXT3-fs: mounted filesystem with writeback data mode.
laut ProjektX >15 Mbit/s für 'Wut' (Das Erste) http://www.jackthegrabber.de/viewtopic.php?t=9957 und das ging sogar noch übers Netzwerk. Viel Erfolg beim systematischen optimierenwolgade hat geschrieben:Nachtrag: Ich weiß nicht, wie verläßlich ProjectX in der Beziehung ist. Das Programm behauptet allen Ernstes, daß die maximale Datenrate einer der TS-Dateien bei 12,3 Mbit/s liegt. Das würde allerdings einiges erklären.
na und, wir ham hier DVB. und dort sind datenraten mit 15MBit/s spezifiziertwolgade hat geschrieben:Ach du Scheiße! Das ist mehr als die DVD-Spezifikation zuläßt.>15 Mbit/s für 'Wut' (Das Erste)
Nach den oben angesprochenen Ähnlichkeiten zwischen DVD und DVB müsste man eigentlich ohne Probleme einen DVB-Receiver bekommen, der auf Knopfdruck eine Video-DVD der Lieblingssendung anfertigt - schließlich scheinen die Digital-TV-Daten geradezu mundgerecht serviert zu werden. Doch praktisch kein Gerät unterstützt die Konservierung auf Video-DVD auch nur in Ansätzen - und erst recht nicht, wenn es um Finessen geht.
Zum Teil liegt dies daran, dass der DVD-Standard wesentlich enger gefasst ist als der DVB-Standard. So kennt man beim Digitalfernsehen beispielsweise Horizontalauflösungen von 480, 528 und 544 Pixeln, die im DVD-Standard nicht vorgesehen sind. Auch die Länge der „Group of Pictures“ (GoP) ist beim Digitalfernsehen nicht wie bei DVD auf 15 Frames beschränkt.
Weiterhin liegt die maximale Datenrate beim Digitalfernsehen mit 15 MBit/s wesentlich höher als bei der DVD, die gerade einmal bis 9,8 MBit/s netto zulässt. Dies müsste aber eigentlich ohne Belang sein, da die TV-Sender niemals in solche Sphären vorstoßen. Tatsächlich können aber Schwierigkeiten auftreten, wenn sich ein Programm zum Erstellen von DVDs (Authoring) von im Digital-TV-Strom vermerkten theoretischen Maximalwert verwirren lässt. Lediglich bei den Audioformaten treten keine Probleme auf: Dass DVB keinen DTS-Ton kennt, ist zwar bedauerlich, mit MP2 und AC3 stehen aber kompatible Codecs zur Verfügung.
Offensichtlich doch. Meine Verblüffung hat ihre Ursache darin, daß bis vor gar nicht langer Zeit die Datenraten bei DVB sehr viel niedriger waren, als bei der DVD. Daß sich das gändert hat, habe ich mitgekriegt, daß tatsächlich Datenraten über 10 Mbit/s auftreten, war mir neu.Dies müsste aber eigentlich ohne Belang sein, da die TV-Sender niemals in solche Sphären vorstoßen.
Hi, hat denn von den Imageselbsterstellen schon jemand damit gespielt?just_me hat geschrieben:Hat denn mal jemand probiert, die bdflush Parameter auf das IDE2 Interface abzustimmen?palace hat geschrieben:Langsam gehen mir die Ideen aus
siehe auch: http://forum.tuxbox-cvs.sourceforge.net ... c&start=10 und dort insbesondere Punkt c)Code: Alles auswählen
union bdflush_param { struct { int nfract; /* Percentage of buffer cache dirty to activate bdflush */ int ndirty; /* Maximum number of dirty blocks to write out per wake-cycle */ int dummy2; /* old "nrefill" */ int dummy3; /* unused */ int interval; /* jiffies delay between kupdate flushes */ int age_buffer; /* Time for normal buffer to age before we flush it */ int nfract_sync;/* Percentage of buffer cache dirty to activate bdflush synchronously */ int nfract_stop_bdflush; /* Percetange of buffer cache dirty to stop bdflush */ int dummy5; /* unused */ } b_un; unsigned int data[N_PARAM]; } bdf_prm = {{30, 500, 0, 0, 5*HZ, 30*HZ, 60, 20, 0}};
Es geht um die Werte in dieser Zeile hier:Im einzelnen:Code: Alles auswählen
} bdf_prm = {{30, 500, 0, 0, 5*HZ, 30*HZ, 60, 20, 0}};
Und wie könnte mans kontrollieren?Code: Alles auswählen
30 - vermutlich OK 500 - 500 Blöcke am Stück schreiben? Autsch. Anpassen! 0 - OK 0 - OK 5*HZ - entspricht 5 Sekunden. Zu selten! Anpassen. 30*HZ - entspricht 30 Sekunden. Zu selten! Anpassen. 60 - könnte verm. höher sein, synchrones Schreiben sollte ja vermieden werden. Anpassen! 20 - evtl. zu klein. In Verbindung mit den 60 oder 30 oben ist bdflush womöglich zu lange am Stück aktiv.
Wenn ein Oszilloskop zur Verfügung steht lässt sich ein Pin auf dem IDE Kabel finden, bei dem man die Transfers gut sieht.
Wenn man eine maximale StreamingWriteRate von 1000kByte/Sekunde anpeilt sollten pro TimerTick (von 10ms) halbwegs gleichmässig etwa 20 Blöcke von jeweils 512 Byte geschrieben werden.
Idealerweise würde das Oszilloskopbild vielleicht etwa so aussehen ('M' heist Aktivität auf dem Pin, '_' heist Pin ruhig:)FriederCode: Alles auswählen
MMM_______MMMM______MMMM______MMM_______MM________MMMM ^ ^ ^ ^ ^ ^ 0ms 10ms 20ms 30ms 40ms
