Streamen im SPTS-Mode rechenintensiver ?

[Arbitrated_Loop]

Hallo,
mal eine aufgrund fehlendem Grundwissen wahrscheinlich dösige Frage:

Ist das Streamen im SPTS-Mode ressourcenhungriger als ohne ? Ich habe gelesen, dass im SPTS-Mode das TS in einen gemeinsamen Puffer geschoben wird während ohne SPTS 2 getrennte Puffer genutzt werden.

Nun stelle ich mir laienhaft vor, dass die Verwendung von 2 Puffern performanter ist als bei einem gemeinsamen ?


Diese Frage resultiert aus meiner Suche nach den "optimalen" Streaming-Einstellungen für NFS-Direktaufnahme.


Gruss
AL

[Simpled]

Nun stelle ich mir laienhaft vor, dass die Verwendung von 2 Puffern performanter ist als bei einem gemeinsamen ?

Zwei Puffer teilen sich den Speicher (fest?) auf, wärend ein großer Puffer den ganzen Speicher für sich hat. Ein größerer Puffer arbeitet im allgemeinen zuverlässiger, da er auch längere 'Durststrecken' Puffern kann als ein kleinerer.
Wie genau das jetzt bei der dbox aussieht weiß ich leider nicht. Theoretisch sollte es keinen großen unterschied machen, da zwei Einzelpuffer schließlich auch langsamer gefüllt und gelesen werden...

[Arbitrated_Loop]

Ok, das klingt plausibel. Danke für die Erklärung.

Ich nehme ohnehin lieber im SPTS-Mode auf, weil ich die .TS Datei einfacher und schneller "verarbeiten" kann.

Übrigens, ich hatte permanent Streaming-Abbrüche mit z.Tl. defekten TS-Dateien als Resultat. Sämtliche Parameter-Änderungen und Tuningversuche brachten nichts.
Erst als ich die Box über einen (Billig-)Switch statt über Cross-Kabel mit der Box verbunden habe, funktionierte es tadellos.
Eigentlich sollte man meinen, dass ein Switch nur unnötigen Overhead erzeugt und die Sache noch träger macht, aber offenbar hilft beim Streamen das Store and Forward des Switches wahre Wunder.

kcore liefert folgendes Ergebnis:

real 1m 1.90s
user 0m 0.18s
sys 0m 15.66s

Mit Cross-Kabel hatte ich einen deutlich schlechteren Wert > 67s


Gruss
AL

[wolgade]

Erst als ich die Box über einen (Billig-)Switch statt über Cross-Kabel mit der Box verbunden habe, funktionierte es tadellos.
Eigentlich sollte man meinen, dass ein Switch nur unnötigen Overhead erzeugt und die Sache noch träger macht, aber offenbar hilft beim Streamen das Store and Forward des Switches wahre Wunder.

[..]

Mit Cross-Kabel hatte ich einen deutlich schlechteren Wert > 67s

Das wundert mich nicht. In meinem allerersten Thread in diesem Forum, in dem du übrigens auch gepostet hast, habe ich mich mit der Netzwerkperformance rumgeschlagen http://tuxbox-forum.dreambox-fan.de/for ... highlight=

Bei mir war der Durchsatz mit Switch auch höher, als über Crossover-Kabel. Eine weitere Erhöhung des Durchsatzes habe ich durch den Tausch des Switch gegen ein anderes Modell erreicht. Die letzte Optimierung war dann das feste Einkompilieren des NFS-Servers in den Kernel meines Eisfair.

Ich hab damals sehr viele Messungen gemacht, die ich hier auch gepostet habe. Mein Fazit war damals, daß die verwendete Hardware dramatischen Einfluß auf die Performance hat und daß es keine allgemeingültige Empfehlung für die Einstellung der Netzwerkkarte(10Mb/s,100Mb/s,voll-,halbduplex) gibt.

[Arbitrated_Loop]

Bei mir war der Durchsatz mit Switch auch höher, als über Crossover-Kabel.

Genau diese Info muss ich in dem Thread überlesen haben
Denn letztlich war es DIE Ursache für meine Abbrüche.

Sämtliche Parameter wie Ringpuffer, rsize/wsize haben bei mir kaum Auswirkung. Also ob ich einen Ringpuffer von 99 oder nur 20 setze, macht bei mir keinen Unterschied. Ebenso r/wsize, ob ich 32768 oder 8192 setze ist scheinbar unerheblich.


Ich glaube das Problem ist einfach, dass die Box mit 10MBit brutto am unteren Limit fährt was die Datenrate angeht. Und die CPU scheint mir manchmal auch nicht unbeteiligt an der mangelnden Speed der Übertragung.



Gruss
AL

[wolgade]

Sämtliche Parameter wie Ringpuffer, rsize/wsize haben bei mir kaum Auswirkung. Also ob ich einen Ringpuffer von 99 oder nur 20 setze, macht bei mir keinen Unterschied. Ebenso r/wsize, ob ich 32768 oder 8192 setze ist scheinbar unerheblich.

Der Ringpuffer erhöht nicht den Durchsatz. Er kann lediglich Lastspitzen abfangen. Das aber auch nur, wenn die Grundlast unterhalb des Limits ist.

rsize/wsize hatten bei mir meßbare Auswirkungen. Ich meine mich aber zu erinnern, daß SFU Werte über 8192 ignoriert. Unter Linux habe ich solche Probleme nicht mehr.

[Arbitrated_Loop]

Der Ringpuffer erhöht nicht den Durchsatz. Er kann lediglich Lastspitzen abfangen. Das aber auch nur, wenn die Grundlast unterhalb des Limits ist.

Schon klar, aber ein Verändern der Grösse sollte Auswirkung auf den Abbruch des Streams haben. Nur wenn, wie bei mir, die Datenrate unterhalb eines Minimums ist/war, dann nützt das leider nicht viel.

rsize/wsize hatten bei mir meßbare Auswirkungen. Ich meine mich aber zu erinnern, daß SFU Werte über 8192 ignoriert. Unter Linux habe ich solche Probleme nicht mehr.

Ich glaube SFU kann rsize mit 32768, aber wsize nur mit 8192.



Gruss
AL

[wolgade]

Schon klar, aber ein Verändern der Grösse sollte Auswirkung auf den Abbruch des Streams haben.

Bei der Wiedergabe? Klar. Bei der Aufnahme? Nö! Der Ringpuffer betrifft nur die Wiedergabe.

Ich glaube SFU kann rsize mit 32768, aber wsize nur mit 8192.

Ja, sowas liegt mir in Erinnerung.

[DrStoned]

Ich glaube SFU kann rsize mit 32768, aber wsize nur mit 8192.

Das gilt für Win2000 und WinXP, unter WindowsServer2003 kann SFU rsize und wsize mit 32768.

Greetz von DrStoned