Welches Spiel braucht viel Bandbreite?

[Linguist]

Gibt's bestimmt, ich kenne aber keines. Gibt es irgendeins, wo ein ganz normales IEEE 802.11b/g nicht reicht? Oder geht es hier um die 2-3ms die auf unter 1 gedrueck werden koennen?

[peddaa]

Linguist schrieb:
--------------------------------------------------------------------------------
> Gibt's bestimmt, ich kenne aber keines. Gibt es irgendeins, wo ein ganz
> normales IEEE 802.11b/g nicht reicht? Oder geht es hier um die 2-3ms die
> auf unter 1 gedrueck werden koennen?

das ist aus physikalischen schon nicht möglich. ist halt wie mein auto hat 90 ps, meine anlage 900 watt, mein rechner 6 GHz, meine digitalkamera 120 megapixel.
das sagt _nichts_ aus, klingt doch aber gut, um beim nachbarn eindruck zu schinden ;)

[IhrName9999]

Die verfügbare Bandbreite ist proportional zur Latenz, eben nicht linear. Als Beispiel wirst du mit einem DSL1024 - Anschluss keinen Ping erreichen der kleiner als (ungefähr) 20 is, bei 32 Mbit sind schon gerne mal 10-15 drin und ein 100Mbit-Anschluss drückt es eventuell sogar auf 5-10. W-LAN allerdings ist stark verzögert weil ein Einzelnes Paket gut und gerne einmal drei bis -vierfach gesendet werden muss, da wird man nochmal so Einiges draufrechnen müssen.



1 mal bearbeitet, zuletzt am 10.03.10 21:00 durch IhrName9999.

[ichneindu]

proportional = linear

[retransmitter]

es geht um die Latenz.
Lies mal den Bericht zu diesen Game-Servern wo man versucht, unter 80ms Latenz zu erreichen.

Und hier gab es neulich einen Bericht über ich glaube HDMI-WLAN-Übertragung. Da gabs iirc den Begriff "fast packet retransmit" oder sowas.

[IhrName9999]

vertippt.

[cyd]

nur so als anmerkung, die größe der maximal verfügbaren Bandbreite hat mit der Latenz nichts zu tun.
Vorteil von n gegenüber b ist die höhere netto bandbreite die dir tatsächlich zur Verfügung steht.

[Linguist]

Natuerlich nicht, aber sag das mal den Experten da oben ;)
Ein Highendrouter kann aber durchaus die Latenz, die sich durch WLAN etwas erhoert, gering halten.

[viele deutsche]

Hier das niveau ist halt gering.

Bandbreite * Latenz = "Füllmenge" in der Pipeline.

Wenn Du redest und es 5 Sekunden bis zum Empfänger braucht, sind 5 Sekunden deines Gespräches in der Leitung.

Wenn man jetzt Videos anzeigt und mitkriegt das ein Packet falsch ist, und erneut gesendet werden muss, kann man das ggf. sofort mitteilen. Wir unterstellen Latenz 0 für die "Schick mir bitte Paket 0815 noch mal"-Meldung.
Aber wenn Paket 0815 sofort gesendet wird, sind noch Latenz*Bandbreite in der Leitung, bis es ankommt. Diese muss man zwischenspeichern bis man das Korrekte Paket 0815 (evtl dann mehrmals gesendet zur Sicherheit) bekommt, und das Videobild darstellen kann. Daraus ergeben sich dann halt Anforderungen an die Größe der Puffer und auch die ABSICHTLICHE Latenz im HDMI-Darstellungs-Gerät.
Ich muss nachschauen, ob das Frame korrekt angekommen ist. Ich muss die fehlenden Teile nachbestellen und darauf warten.
In der Zwischenzeit muss ich die weiteren reingekommenen Frames zwischenspeichern.
Da ich die Latenz auf die korrekten Pakete warten muss, ist das die "Sicherheits-Reserve".

Also kann ein HDMI-Player mit "fast-packet-resubmit" ein Bild immer erst nach der doppelten Latenz anzeigen.
Wenn man Frames droppen oder selber pseudo-korrigieren/interpolieren kann, kann man auch gleich so schnell wie möglich die Frames anzeigen. Also nach der einfachen Latenz.
Wenn man einen Puffer hat, kann man Fehlerhafte Frames interpolieren. Dann kann man Latenz plus Zeit für 1 weiteres Bild oder B oder P-Frame nehmen. ein kaputtes Frame wird an den kaputten Stellen durch die Frames davor und danach interpoliert.
Dann spart man Puffer und kann die Frames schneller anzeigen ohne die Sicherheitsreserver warten zu müssen.

So lange die Fehlerzahl nicht wirklich groß ist, dürfte das gehen. Speziell bei Spielen ist das wohl vorzuziehen.

Es gibt keine perfekte Lösung. Abhängig von der Fehlerquote und den Anforderungen an hinreichende Darstellung gibts halt mehr oder besser funktionierende Lösungen.