warum so hohe Festplattenaktivität bei TS-Streaming?

[rimshot]

Moin
Ich hab auf einem P3-450 die SFU installiert. Wenn ich nun aus dem aktuellen yadi-snap direkt TS streame, rödelt die HD wie wild rum (die LED geh quasi kaum noch aus)... bis der Stream irgendwann gerne auch mal abbricht (Daten konnten nicht schnell genug geschreiben werden...). Wenn ich aber auf dem gleichen PC per JtG streame, blinkt die HD-LED nur ab und zu mal auf, es tut sich also kaum was und ich habe auch keine Probleme mit Abbrüchen?
Kann man da irgendwas einstellen, damit beim TS Streaming die Platte weniger beansprucht wird?

Gruß, Rimshot

[DieMade]

Beim TS-Streaming werden relativ kleine Pakete auf die Platte per "fdatasync" committed. Das ist für die interne Festplatte zwingend notwendig (aus der Ecke kam die Direktaufnahme urspünglich), da Linux sonst zu viel puffert und beim "flush" wird der Datenbus zu lange blockiert. Das wiederum führt zu einem "queue overflow" im Demux und der Stream ist unbrauchbar.

Evtl. kann Neutrino um eine weitere Option ergänzt werden, welche das "fdatasync" flexibel konfiguriert.

[insolvenzia]

Keine Ahnung was "SFU" ist, aber das handlen doch idr die Buffer des Netzes - oder? Ich kann keine extrem hohe Aktivität der Platten erkennen

[Tommy]

unter Linux NFSServer (Eisfair) blinkt die HD LED aller 2 sekunden und es werden jeweils zwischen 700-800 Blocks geschrieben. Prozessorlast bei 8%
Das problem muß an Deinem Windoof/SFU liegen.

Was sagt denn dein Taskmanager über die CPU Auslastung deines SFU - NFSServer- Prozesses?

Hast Du evtl. eine Firewall?

[petgun]

hi,

..Das problem muß an Deinem Windoof/SFU liegen...

imo gibt's kein SFU/Windows Problem und die Prozessorlast ist minimal (auf P4 2 GHz < 1 %). DieMade hat den Grund ja perfekt erklaert und ich wuerde eine fdatasync-Konfiguration-Optimierung sehr begruessen.

cu,
peter

[rimshot]

tja, selbst auf meiner 450er Gurke läuft der nfs-Server-Prozess mit weniger als 1% cpu-last. Ich habe auch geradfe mal mit den Mount-Optionen in Neutrino (rsize und wsize) gespielt, aber das hat rein objektiv nichts geändert.
Also schließe ich mich petgun an, was "eine fdatasync-Konfiguration-Optimierung" betrifft

bye, Timo

[Fahrtwind]

Hi,
habe seit heute endlich auch SFU am Laufen. Das mit der hohen Festplattenaktivität ist mir auch sofort aufgefallen. Hat sich bezüglich fdatasync schon was ergeben? So kann ich beim besten willen nicht beim Streamen einschlafen
Ansonsten Hut ab, habe die DBox seit 3 Tagen im Einsatz und bin schlichtweg begeistert!

Lieben Gruß,
Manuel

[Frockert]

Bei meinem Experimenten mit meinen Pentium 75 Mhz Eisfair hatte ich diesen Zustand auch schon.

Und zwar wenn ich den Nfs-Ordner mit der Option "sync" freigegeben und gemountet hatte. Dieses hatte ich testweise probiert, weil mit "sync" meine Festplatte aus dem Schlafmodus sofort aufwacht, während sie mit "async" erst aufwacht wenn der Ringpuffer voll ist.
Also mit "async" rödelte die Festplatte auch wie wild und das Streamen war so ca. unmöglich (viele kleine Streams).

Also bin ich wieder zurück auf die Option "async" und nun ist wieder gut, ich schicke meine Festplatte halt nicht mehr schlafen.

Ich würde gerne den Ringpuffer vergrössern, ich kann aber nicht im Quellcode wühlen, da das yadi-Skript net bei mir funktioniert.
Naja, nur so mal am Rande....



Gruß Frockert

[Treito]

Also mit "async" rödelte die Festplatte auch wie wild und das Streamen war so ca. unmöglich (viele kleine Streams).

Also bin ich wieder zurück auf die Option "async" und nun ist wieder gut

Ja was denn nun?

P.S.: Mein SuSE 9.1-Server werkelt mit async und rödelt nicht rum.

[Tommy]

... das mit "sync" kann ich bestätigen - kein Zustand. "Async" ist hier die beste Wahl. Zum aufwachen kann ich den deepstandby empfehlen. Da hier das Verzeichnis scheinbar neu gemounted wird wacht meine HD rechtzeitig auf. Das einzige Problem dabei ist, das das timergesteuerte Aufwachen auf dem deepstandby nicht immer zuverlässig ist (zumindest bei mir)

zum Glück kommt CSI immer zweimal

[Treito]

Das einzige Problem dabei ist, das das timergesteuerte Aufwachen auf dem deepstandby nicht immer zuverlässig ist

Also bei mir geht das sehr zuverlässig, ich habe das Problem, das meine Box immer nach einer Aufnahme in den Deep-Standby geht, ohne, dass ich das eigentlich will...
Aufgrund eines leichten Festplattenschadens @Server-Platte kann ich aber meine Festplatte eh nicht zum Schlafen schicken

[Frockert]

Also mit "async" rödelte die Festplatte auch wie wild und das Streamen war so ca. unmöglich (viele kleine Streams).

Also bin ich wieder zurück auf die Option "async" und nun ist wieder gut

Ja was denn nun?

P.S.: Mein SuSE 9.1-Server werkelt mit async und rödelt nicht rum.

Sorry, war noch früh am morgen... gemeint war, mit sync rödelt die festplatte rum.

Gruß Frockert

[Tommy]

... das problem ist nicht das Aufwachen an sich sondern das es scheinbar einfach zu lange dauert bis die Platte auf Touren ist. Ist die Aufnahme dann einmal aus dem Tritt habe ich durch die ganze Aufnahme kleine freezes und Tonasynchronitäten. Abbrüche (mehrere TS Dateien) gibts eigentlich nicht mehr

Das mit dem deepstandby kann ich mir auch nicht erklären und es ist auch nicht nachvollziehbar. Manchmal nimmt er einfach nicht auf und der Timer ist gelöscht (klar, liegt ja dann auch in der Vergangenheit)

Eine Vermutung ist, daß die Box zwar aus dem deepstandby aufwacht aber nicht mounten kann weil die HD auch da zu lange braucht. Dann bricht die Aufnahme ab "Aufnahmeverzeichnis nicht beschreibbar" und die Box fährt nach dem Timerevent wieder herunter. Das würde zumindest erklären warum kein Dateifetzen dieser Aufnahme auf der Platte zu finden ist.

Ich habe schon Tagelang meinen PC die logs mitschreiben lassen um dahinterzukommen - immer dann hat's aber normal funktioniert (Murphey's Law).

[rimshot]

Hat evtl. jemand ne Idee, wie man die Optionen synch und asynch unter Windows/SFU bedient? Ich habe leider bisher nichts dergleichen finden können...
cya