PlayStation Now: Sony startet Spiele-Streaming-Beta in Deutschland

Bisher konnte der Dienst PlayStation Now nur von PS4-Nutzern in den USA und in England genutzt werden. Jetzt hat Sony angekündigt, dass der Spielestreamingdienst ab heute unter anderem erstmals auch in Deutschland in einem 1-monatigen Beta-Test ... mehr... Sony, PlayStation 4, PS4, Sony PlayStation 4, Design, Sony PS4 Bildquelle: Sony Sony, PlayStation 4, PS4, Sony PlayStation 4, Design, Sony PS4 Sony, PlayStation 4, PS4, Sony PlayStation 4, Design, Sony PS4 Sony

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Das es überhaupt nutzer gibt die für sowas bezahlen. Krass.
 
@Edelasos: darf ich fragen wieso? ich finde die idee gut.

edit: habs glaub falsch verstanden. geht es hier wirklich nur darum spiele von ps auf andere geräte zu streamen?
 
@Mezo: Nein, PS Now ermöglicht dir PS3 Spiele zu leihen für einen bestimmten Zeitraum gegen ein nicht unerhebliches Entgeld, welche dann von irgendwelchen Servern auf deine PS4 gestreamt werden. D.h. im Gegensatz zur One musst du hier die Spiele leihen auch wenn du Sie bereits besitzt und sie werden nicht lokal abgespielt sondern gestreamt.
 
@lurchie: streamen, ist da richtiges streamen gemeint? und wieso nur ps3? als ich gefragt habe, dass ich die idee gut finde, dachte ich, es wäre ein art netflix für games.
 
@Mezo: ne, du kannst wirklich nur Spiele streamen welche auf der PS3 erschienen sind und das Abo dafür kostet 99,99 Dollar für 12 Monate in Amerika. https://www.playstation.com/en-us/explore/psnow/subscriptions/
 
@lurchie: + noch ein PlaystationPlus Abo welches auch noch 50?$ kostet.
 
@Edelasos: Man braucht kein PS+ Abo um PSNow zu nutzen.
 
@Minty_Insurrect: Wenn du alte PS3 Games online zocken willst schon.
 
@Edelasos: Auch dann nicht.
 
@Edelasos: Ich frag mich das alles bei Pay-To-Win, den ganzen In-App-Purchases, etc. Allerdings ist meine Erkenntnis mittlerweile die, dass ich die Minderheit repräsentiere.
 
Streaming kann man bei den meisten Genres doch schon zuhause komplett vergessen. Über das Internet wird das in den nächsten Jahrzehnten nicht funktionieren können. Ist ja auch klar: die Zeit um ein Bild zu berechnen liegt bei 16,7 ms (1 Bild / 60 Bilder/s = 16,7 ms). Die PS4 schafft das ja bei vielen Spielen schon nicht, wenn sie das Bild direkt auf dem TV ausgibt. Wenn ich von hier aus Sony.com pinge sind es schon 58ms, selbst google.de braucht 28ms. Das ist als Latenz viel zu hoch. Selbst In-Home vom einen i7 zum anderen per Gigabit ist noch zu langsam. Jeder, der denkt, dass dieses Spielestreaming von Sony über das Internet funktionieren kann, hat offensichtlich ein zu geringes technisches Verständnis.

edit: lol, da ist wohl ein armer Konsolero traurig, weil er niemals richtig zocken kann, oder wie soll ich das Minus verstehen? Inhaltlich ist mein Kommentar ja korrekt, darauf kann man das Minus ja offensichtlich nicht beziehen.
 
@conan179: Wie lange die Bildberechnung braucht ist unerheblich. Bei einer Latenz von 20ms, hinkst du mit dem Bild 20ms hinterher. Außer bei Spielen wie Guitar Hero (wo man das aber in den Einstellungen kompensieren kann), die auf schnelle Reaktion wert legen, sind 20ms egal. Der Input-Lag ist da die größere Hürde. Bild 20ms hinterher, Input 20ms hinterher macht 40ms. Plus den normalen lokalen Input Lag von 40-150 ms merkt man schon eher. Aber da kann man sich auch dran gewöhnen.

Für Singleplayer dürfte das aber durchaus reichen. Vor allem wenn viele behaupten das sie keinen Unterschied zwischen 30 (100-166ms) und 60 (50-66ms) fps merken, wo allein der Lokale Input Lag bei 60fps schon deutlich geringer ist.
 
@Minty_Insurrect: "Wie lange die Bildberechnung braucht ist unerheblich." Natürlich ist das NICHT unerheblich. Es stehen MAXIMAL 16,7s zur Verfügung sonst kann man 60fps vergessen.

"Bei einer Latenz von 20ms, hinkst du mit dem Bild 20ms hinterher."
Falsch! Wenn ein Bild nicht in 16,7ms berecht werden kann, dann kann kann auch nicht alle 16,7 ms ein Bild dargestellt werden. Dann wir ein und dasselbe Bild doppelt angezeigt. Dann sind es nur noch 30 fps. Da braucht man eigentlich gar nicht weiter reden: 30 fps sind absolut inakzeptabel.

Die Eingabelatenz und die Ausgabelatenz erhöhen sich zusätzlich zu dem was normal schon vorhanden ist mindestens um die Ping-Zeit. Das sind 2-3 Frames zusätzlich. Das ist extrem viel. Das entspricht in etwa dem, wenn am vergessen hat, am TV die 'Bildverbesserungsmaßnahmen' abzuschalten.

"30 (100-166ms) und 60 (50-66ms)"
Keine Ahnung was du da rechnest 30 fps entsprechen einer Frametime von 33,3ms und 60fps entsprechen 16,7ms. Deine Zahlen ergeben irgendwie gar keinen Sinn, oder?!
 
@conan179: Hast du überhaupt eine Ahnung was du da schreibst? Okay...

1. Die PS4 berechnet die Bilder nicht, die kriegt einen Stream gesendet. Daher ist es unerheblich wie lang die ps4 zur Berechnung braucht. 20 ms Latenz = 20 sekunden verzögerung, nicht das gleiche Bild 2 mal darstellen.
2. 30 fps sind nicht unakzeptabel für Konsolenspieler, sie sind meist die Regel.
3. Selbst wenn ein Bild 2 mal dargestellt wird, ist die Input Latenz bei 60fps immer noch besser als bei 30fps.
4. 30fps entsprechen einem Inputlag von 100-166ms, 60 fps einem von 50-66ms. Es behaupten viele keinen Unterschied zwischen 30 und 60 fps zu sehen oder zu spüren. Wer keinen Unterschied zwischen 100 und 50ms Input Lag spürt, der spürt auch 40-60ms mehr nicht oder nur wenig.
 
@Minty_Insurrect: "Hast du überhaupt eine Ahnung was du da schreibst? Okay..." Offensichtlich deutlich mehr als du.

"1. Die PS4 berechnet die Bilder nicht, die kriegt einen Stream gesendet. Daher ist es unerheblich wie lang die ps4 zur Berechnung braucht. Und nein, es spielt keine Rolle. "
Du hast ja gar nichts verstanden. Ich hab doch nirgends geschrieben, dass die PS4 das Bild berechnet. Schon klar, dass das auf dem Server passiert. WO das Bild berechnet wird ist aber völlig irrelevant.

"20 ms Latenz = 20 sekunden verzögerung, nicht das gleiche Bild 2 mal darstellen."
Das ist aber KEINE Latenz. Wie kommst du denn darauf?

"4. 30fps entsprechen einem Inputlag von 100-166ms, 60 fps einem von 50-66ms."
Was hat denn deiner Meinung nach die Framerate mit Inputlag zu tun? Was verstehst DU eigentlich unter Inputlag?

Eigentlich ist es ziemlich egal, was du darunter verstehst, die Differenz der Frametimes von 30 und 60 fps ist 16,7ms. Egal was du unter Inputlag verstehst, das unterscheidet sich bei 30 und 60 fps um genau diesen Wert. Wo soll denn bitte ein anderer Wert herkommen?

"Wer keinen Unterschied zwischen 100 und 50ms Input Lag spürt"
Deine Zahlen ergeben keinen Sinn.

"der spürt auch 40-60ms mehr nicht oder nur wenig."
Du hast vergessen, dass du die noch dazu addieren musst. Wenn du also bei 30 fps schon bis zu 166 ms Latenz annimmst, dann musst du die 100 ms dazurechnen und kommst auf 266 ms. Das ist ne Viertelsekunde. Wer ne Viertelsekunde nicht merkt, der muss zwangsläufig so schlecht spielen, den will keiner in seinem Team haben. Selbst wenn er im gegnerischen Team ist wird so jemand auf Dauer sehr langweilig, der wird nie einen Treffer landen.
 
@conan179: Ne, anscheinend hast du 0 Plan wie das läuft.

"Das ist aber KEINE Latenz. Wie kommst du denn darauf?"

Was ist denn Latenz für dich? oO Ich frage beim Server nach dem Stream. Die Anfrage + Antwort dauert 20ms. Danach liefert der Server mir einen kontinuierlichen Stream. Und der Stream ist echtzeit, sofern die Verbindung ausreicht, daher kommt das Bild nur mit Verspätung an und nicht abgehackt. Oder glaubst du wenn du Twitch bei 60fps guckst das wegen der Latenz keine 60fps bei dir ankommen? Die kommen an, nur eben verzögert um die Latenz und zwar nur einmal verzögert, weil nur einmal angefragt wurde. (Solange die Verbindung reicht natürlich und nicht nochmal angefragt werden muss, weil sie verloren geht, aber selbst dann wird bei einem Live-Stream nur etwas übersprungen und die Verzögerung bleibt sozusagen die gleiche.)

"Was hat denn deiner Meinung nach die Framerate mit Inputlag zu tun? Was verstehst DU eigentlich unter Inputlag?"

Inputlag der Zeitraum zwischen Knopfdruck und Darstellung der Aktion. Der Frame den du siehst ist schon berechnet. Der nächste Frame ist ebenfalls bereits berechnet (weil Page Flipping), ergo hast du schon mal 1/30 Verzögerung bei 30fps und 1/60 bei 60fps. Dann wird die Eingabe verarbeitet, und der davor gerenderte Frame dargestellt. Damit bist du bei 2/30 bzw. 2/60 Verzögerung. Danach wird der Frame mit der Aktion dargestellt und damit bist du, im optimalsten Fall, bei 3/30 bzw. 3/60.

3/30 sind 0,1, also 100 ms. 3/60 sind 0,05 also 50ms. Das ist das Minimum an Input-Lag den man hat.

"Du hast vergessen, dass du die noch dazu addieren musst. Wenn du also bei 30 fps schon bis zu 166 ms Latenz annimmst, dann musst du die 100 ms dazurechnen und kommst auf 266 ms. Das ist ne Viertelsekunde. Wer ne Viertelsekunde nicht merkt, der muss zwangsläufig so schlecht spielen, den will keiner in seinem Team haben. Selbst wenn er im gegnerischen Team ist wird so jemand auf Dauer sehr langweilig, der wird nie einen Treffer landen."

Die Latenz die du drauf addieren musst, ist die Zeit die es braucht "Knopfdruck" zum Server zu senden. Das ist die Hälfte der Ping Zeit (weil Ping die Zeit bis zur Antwort misst, ergo braucht es hin Ping/2 und zurück ebenfalls Ping/2, grob gesagt.). Und da der Stream, je nach Ping, ohnehin x ms zurückliegt kommt lediglich das noch dazu.

Edit: Youtube mit Twitch ersetzt.
 
@Minty_Insurrect: "Ne, anscheinend hast du 0 Plan wie das läuft." Dass du diese Schlussfolgerung ziehst zeigt, dass DU null Plan hast, aber lassen wir das. Du zeigst ja durch deine Äußerungen, dass dem so ist, da spar ich mir mal jeden weiteren Kommentar diesbezüglich.

"Ich frage beim Server nach dem Stream. Die Anfrage + Antwort dauert 20ms."
20ms ist doch utopisch. Ping doch mal Google. Google hat auf jeden Fall eine schnellere Internetanbindung, als Sony für ihren Spielkram. Bei einem Ping muss nichts berechnet werden. Beim Streamen schon.Es ist also damit zu rechnen, dass es länger dauert.

"Danach liefert der Server mir einen kontinuierlichen Stream."
Ja, aber wenn er es nicht schafft, das Bild in 16,7 ms zu berechnen, kannst du niemals 60 fps haben.

"Und der Stream ist echtzeit, sofern die Verbindung ausreicht,"
UND auch die Rechenleistung des Servers. Das darfst du nicht vergessen!

"Oder glaubst du wenn du Youtube bei 60fps guckst das wegen der Latenz keine 60fps bei dir ankommen?"
Bei YT liegt der fertige Stream aber schon mit 60fps vor. Der muss nur rausgeschickt werden. Die Streamingserver fürs Gaming müssen die Eingaben verarbeiten, das Bild berechnen, das Bild komprimieren und verschicken. Dafür stehen insgesamt pro Bild 16,7 ms zur Verfügung, sonst sind 60 fps nicht möglich. Denk doch mal nach: wenn jedes Bild 20 ms braucht, und du benötigst eines nach 16,7ms, nach 33,3ms, nach 40ms, nach 56,7ms, etc. Dann reicht das eben nur für jedes zweite Bild, also 30 fps.

"Inputlag der Zeitraum zwischen Knopfdruck und Darstellung der Aktion."
Nur, wenn du davon ausgehst, dass du keine Ausgabelatenz hast.

"Der Frame den du siehst ist schon berechnet. Der nächste Frame ist ebenfalls bereits berechnet (weil Page Flipping), ergo hast du schon mal 1/30 Verzögerung bei 30fps und 1/60 bei 60fps. Dann wird die Eingabe verarbeitet, und der davor gerenderte Frame dargestellt. Damit bist du bei 2/30 bzw. 2/60 Verzögerung. Danach wird der Frame mit der Aktion dargestellt und damit bist du, im optimalsten Fall, bei 3/30 bzw. 3/60."

Quatsch. Ein Frame wird dargestellt, gleichzeitig wird der nächste berechnet. Das Berechnen des nächsten Frames schließt selbstverständlich die Auswertng der Eingaben mit ein. Somit hast du eine minimale Latenz von 16,7ms. Sollten 60 fps nicht möglich sein, sondern nur 30, dann kommen weitere 16,7ms dazu, weil der eine Frame doppelt so lange dargestellt wird. Die minimale Latenz entspricht der Frametime.

Wenn du einen schlechten Monitor hast, oder am TV spielst, dann kommt noch mindestens 2-3 Frame Ausgabelatenz hinzu. Am TV mit eingeschalteten 'Bildveresserungsmaßnahmen' können das auch 4 oder 5 Frames sein.

"Das ist die Hälfte der Ping Zeit (weil Ping die Zeit bis zur Antwort misst, ergo braucht es hin Ping/2 und zurück ebenfalls Ping/2, grob gesagt.). Und da der Stream, je nach Ping, ohnehin x ms zurückliegt kommt lediglich das noch dazu."
Vergiss nicht, dass der Stream nicht als Rohdaten, sondern komprimiert übertragen wird. Sowohl das Komprimieren, als auch das Dekomprimieren kosten Zeit. Aber selbst wenn du das ignorierst, kommen durch die Netzwerklatenz noch mal weiter 2-3 Frames dazu.

Im Normalfall (also am PC) hat man also 1 Frame = 16,7 fps Latenz. An der Konsole per Streaming und 30 fps hat man dann schon mindestens 5-7 Frames. Wie schon gesagt, das ist ungefähr so, wie wenn du die 'Bildverbesserungsmaßnahmen' nicht abstellst.

Man merkt ja schon den Unterschied von PC am Moni (16,7ms + ca. 10ms fürs Display) und PC am TV im Gaming-Modus (16,7ms+ ca. 30ms).

50 ms sind schon inakzeptabel und du bist der Meinung, das sogar über 100ms noch ok wären. Was für ein Bullshit.
 
@conan179: Ey... Die Spiele sind auf PS3 gelaufen und werden das auch jetzt vermutlich tun. Ergo gibt es bei der Berechnung 0 Probleme.

Der Rest den du schreibst zeugt von horrendem Unwissen darüber wie Spiele und Rendering funktionieren. Informiere dich da vorher. Hat so keinen Sinn dir was erklären zu wollen.

Für den Anfang empfehle ich:
http://www.gamasutra.com/view/feature/1942/programming_responsiveness.php

und

http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php?print=1
 
@Minty_Insurrect: "Ey... Die Spiele sind auf PS3 gelaufen und werden das auch jetzt vermutlich tun." Wie kommst du zu dieser Annahme? Die PS3 hat schon damals nicht immer 60fps geschafft. Warum sollten die das jetzt auf einmal schaffen, nur weil die bei Sony im Serverraum stehen?
 
@conan179: Ich wollte damit nur sagen das es keine Rolle spielt, da die Spiele so laufen wie auf der PS3, plus die Latenz halt. Mit wieviel FPS sie gelaufen sind, darüber hab ich gar keine Aussage gemacht.
 
@Minty_Insurrect: " Ich hab dir Quellen gegeben, du bist am Zug." Du sagst, 3 Frames wären Minimum, deine Quelle sagt "When a player presses a button, the game can take up to three frames" 'up to' bedeutet 'bis zu'. Somit widerlegt deine Quelle deine eigene Aussage. lol
 
@conan179: Up to 3 Frames in the best case.
 
@Minty_Insurrect: "Up to 3 Frames in the best case." Ja, zu den 'bis zu 3' können unter Umständen noch mehr dazukommen, die 'bis zu 3' können aber auch 1 sein
 
@conan179: 1 Frame Delay ist bei Page Flipping, wie es üblich ist, Mathemathisch unmöglich, weil der Button erst verarbeitet werden kann nachdem der nächste Frame schon im Buffer ist, sonst gäbe es zwischenzeitlich einen schwarzen Bildschirm.

3/60 und 4/60 sind schon sehr gut.
 
@Minty_Insurrect: "Ne, du hast nur keine Ahnung, das ist alles. Ob mein DSL 10kb/s Upload hat oder 5000Kb/s, an der Paketlaufzeit ändert sich 0."

Wäre deine Aussage korrekt, dann würde die Geschwindigkeit ja keinen Unterschied machen. Dann würdest du mit 1 Mbit genau so lange an einem MByte laden, wie mit 1 Gbit. Merkst selber: das passt net, oder?
 
@conan179: Dann empfehle ich dir auch noch einen Artikel zu Latenz durchzulesen, bevor du dich noch lächerlicher machst mit deinen Aussagen.
 
@Minty_Insurrect: "1 Frame Delay ist bei Page Flipping, wie es üblich ist, Mathemathisch unmöglich, weil der Button erst verarbeitet werden kann nachdem der nächste Frame schon im Buffer ist, sonst gäbe es zwischenzeitlich einen schwarzen Bildschirm." Quatsch. WÄHREND der Frame dargestellt wird wird die Eingabe gemacht und verarbeitet. Wenn du drückst BEVOR die Eingabe verarbeitet wurde, dann fließt es in die Berechnung mit ein. Vergisst du vielleicht, dass das Verarbeiten der Eingabe und die Berechnung des Bildes zwei verschiedene Threads sind, die ASYNCHRON laufen?
 
@Minty_Insurrect: "bevor du dich noch lächerlicher machst mit deinen Aussagen." DU machst dich doch lächerlich mit dem ganzen Blödsinn, den du schreibst.
 
@conan179: Sag mal verstehst du das nicht? Während der Frame dargestellt ist den du siehst, ist der nächste schon berechnet, und der nächste wird erst berechnet nachdem du den Knopf gedrückt hast und dann erst als der Frame DANACH dargestellt.

Du vergisst offensichtlich das ASynchrone daran.
 
@Minty_Insurrect: "Ob mein DSL 10kb/s Upload hat oder 5000Kb/s, an der Paketlaufzeit ändert sich 0."

In der Realität ist es so, dass die Paketlaufzeit bei 5000Kb/s 500 mal kleiner ist als bei 10Kb/s. Nur so kann in der selben Zeit die 500-fache Datenmenge übertragen werden.

Wenn du davon ausgehst, dass die Paketlaufzeit gleich ist, wie erklärst du dir dann, dass die Geschwindigkeit höher ist? Denkst du, dass da 500 mal soviele Leitungen sind und die Pakete gleichzeitig verschickt werden?

Soviel zum Thema 'lächerlich machen'...
 
@Minty_Insurrect: "Du vergisst offensichtlich das ASynchrone daran." Asynchron bedeutet in diesem Fall, dass es GLEICHZEITIG passiert. Du hingegen meinst, es sei nacheinander. Das ist dein Denkfehler.
 
"In der Realität ist es so, dass die Paketlaufzeit bei 5000Kb/s 500 mal kleiner ist als bei 10Kb/s. Nur so kann in der selben Zeit die 500-fache Datenmenge übertragen werden.

Wenn du davon ausgehst, dass die Paketlaufzeit gleich ist, wie erklärst du dir dann, dass die Geschwindigkeit höher ist? Denkst du, dass da 500 mal soviele Leitungen sind und die Pakete gleichzeitig verschickt werden?"

Damit hast du gar nicht so unrecht, deswegen heisst es auch Band"BREITE". Das Band ist breiter, der Weg und die Geschwindigkeit die ein Bit von X nach Y braucht ist die selbe, es können nur mehrere Bits gleichzeitig verschickt werden.
 
@Minty_Insurrect: "Damit hast du gar nicht so unrecht, deswegen heisst es auch Band"BREITE". Das Band ist breiter, der Weg und die Geschwindigkeit die ein Bit von X nach Y braucht ist die selbe, es können nur mehrere Bits gleichzeitig verschickt werden."
Wir sprechen aber von Paketen, nicht von Bits.
 
"Wir sprechen aber von Paketen, nicht von Bits."

Kommt aufs gleiche raus, weil Pakete innerhalb eines Dienstes immer gleichgroß sind.
 
@Minty_Insurrect: "Kommt aufs gleiche raus, weil Pakete innerhalb eines Dienstes immer gleichgroß sind."

Natürlich kommt das nicht aufs Gleiche raus. So ein TCP-Paket hat ca 1500 Bits. Bei 1,5KBit/s kannst braucht ein Paket also 1s. Wenn du jetzt 15Kbit/s hast, dann braucht ein Paket nur 0,1s. So kommst du insgesamt auf 10 Pakete/s.

So wie du das beschreibst würden 15 Pakete gleichzeitig verschickt. Jedes auf einem eigenen Band mit jeweils 1,5KBit/s. Das ist einfach nicht so.

edit: sorry, falsche Zahlen
 
@conan179: "Asynchron bedeutet in diesem Fall, dass es GLEICHZEITIG passiert. Du hingegen meinst, es sei nacheinander. Das ist dein Denkfehler."

Nun, sagen wir mal so: Mir ist egal ob du es schlussendlich verstehst (bzw. wir uns einigen können) oder nicht. Wenn du dir Input-Lag oder Response Time Messungen anschaust, dann wirst du erkennen das selbst 3/60 äußerst selten ist. und eher 4/60 oder höher die Regel ist.
 
@conan179: "Natürlich kommt das nicht aufs Gleiche raus. So ein TCP-Paket hat ca 1500 Bits. Bei 1KBit/s kannst braucht ein Paket also 1s. Wenn du jetzt 10Kbit/s hast, dann braucht ein Paket nur 0,1s. So kommst du insgesamt auf 10 Pakete/s."

Soweit so richtig. Die Pakete kommen alle gleichzeitig an, statt nacheinander, aber dennoch mit der gleichen Latenz von (gedachten) 20ms. Nur das alle Pakete gleichzeitig nach den 20ms ankommen, während bei geringerer Bandbreite die Pakete nacheinander ankommen, jedes nach 20ms. Du siehst: An der Latenz ändert sich 0.
 
@Minty_Insurrect: "Wenn du dir Input-Lag oder Response Time Messungen anschaust, dann wirst du erkennen das selbst 3/60 äußerst selten ist. und eher 4/60 oder höher die Regel ist."

An einer Konsole und am TV, wenn du Eingabe- und Ausgabelatenz addierst.

Du hast aber geschrieben: "3/60 sind 0,05 also 50ms. Das ist das Minimum an Input-Lag den man hat.". Das Minimum liegt bei 60 fps bei 16,7 ms Eingabelatenz + ca 5-10 ms Ausgabelatenz.
 
@conan179: Nope, wenn du Eingabe- und Ausgabelatenz rausrechnest. Mit liegt sie weit höher.
 
@Minty_Insurrect: "Soweit so richtig. Die Pakete kommen alle gleichzeitig an, statt nacheinander, aber dennoch mit der gleichen Latenz von (gedachten) 20ms."
Nein, das ist doch Blödsinn. Durch die höhere Bandbreite kommen die einzelnen Bits des Pakets gleichzeitig an. Somit ist das ganze Paket früher da.
 
@Minty_Insurrect: "wenn du Eingabe- und Ausgabelatenz rausrechnest"
Wenn du alle Latenzen rausrechnest bis du bei 0 ms.
 
@Minty_Insurrect: Ist dir eigentlich klar, dass die Übertragung von Bits und von TCP-Paketen auf unterschiedlichen OSI-Layern abläuft? Soviel zum deiner falschen Aussage Pakete würden parallel übertragen.
 
@conan179: "Nein, das ist doch Blödsinn. Durch die höhere Bandbreite kommen die einzelnen Bits des Pakets gleichzeitig an. Somit ist das ganze Paket früher da."

Himmel... Ja, das gesamte Paket ist früher da, das spielt aber keine Rolle, weil die Latenz die Spanne von Anfrage bis Antwort ist. Ganz egal wie schnell deine Verbindung ist, das allerste Bit kommt, ganz unabhängig von den restlichen, in 20ms an. Es dauert immer MINDESTENS diese 20ms bis du eine Antwort hast. Egal wie schnell die Verbindung ist. Das ist der Latenz geschuldet.

Das die Daten insgesamt schneller da sind, das ist der Bandbreite geschuldet.

Wenn du eine Latenz von 5000 hast, dann kommen alle Pakete frühestens nach 5 Sekunden an, egal ob sie in einem Rutsch durch deine Bandbreite passen oder nicht.
 
@Minty_Insurrect: "Ganz egal wie schnell deine Verbindung ist, das allerste Bit kommt, ganz unabhängig von den restlichen, in 20ms an."
Relevant ist die Zeit, bis das gesamte Paket da ist.
 
@conan179: "Relevant ist die Zeit, bis das gesamte Paket da ist."

What? Nein. Das hat mit Latenz nix zu tun.
 
@Minty_Insurrect: "What? Nein. Das hat mit Latenz nix zu tun."
Natürlich hat es das. Die Eingabelatenz ist die Zeit, bis zum Verarbeiten der Eingabe. Die Eingabe wird im Paket an den Server geschickt. Wenn das Paket länger braucht ist die Latenz höher.
 
@conan179: Ich gebs auf. Hast gewonnen.
 
@Minty_Insurrect: Aber verstanden hast du es nicht. Schade. Ich wäre qualifiziert es dir beizubringen. Mit dieser Einstellung wirst du im Leben wohl nicht weit kommen.
 
@conan179: Was für eine Qualifikation hast du denn?
 
@Minty_Insurrect: Hab Informatik gelernt und Elektrotechnik studiert. Ich weiß wohl besser wovon ich rede als du.
 
@conan179: Wenn du tatsächlich eine Ausbildung oder gar Studium im Informatikbereich genossen hast, dann ist das sehr sehr traurig.
 
@Minty_Insurrect: "Wenn du tatsächlich eine Ausbildung oder gar Studium im Informatikbereich genossen hast, dann ist das sehr sehr traurig."
Nein, ich hab ja recht. Teste es doch einfach. Hast du zufällig noch nen alten 10 MBit Hub/Switch rumliegen? Mit Wireshark kannst du dir ansehen, wie lang die Pakete brauchen. Schick mal was von einem Rechner zum anderen mit 10 MBit und dann mit 1 GBit. Du wirst sehen, dass die Paketlaufzeit unterschiedlich ist.

Du hast so gar keine Ausbildung in dem Bereich, oder?
 
@conan179: In einem lokalem Netz? Was soll da überhaupt für eine Latenz auftreten? Du weisst wie sich ein (optimaler) Ping berechnet? 2*Entfernung/Lichtgeschwindigkeit. Unter diese Latenz kommst du niemals. Egal wieviel Bandbreite du zur Verfügung hast, solange dauert es IMMER.

Edit: Bin übrigens Informationstechnischer Assistent.
 
@Minty_Insurrect: "Du weisst wie sich ein Ping berechnet?" DU jedenfalls nicht. Der Ping ist doch die Zeit, die vergeht vom Beginn des Ping bis zum Ende vom Pong.

"2*Entfernung/Lichtgeschwindigkeit."
Würde mindestens voraussetzen, dass
1. ALLE Bits GLEICHZEITIG gesendet werden und
2. alle beteiligten Netzwerkgeräte komplett ohne Zeitverlust arbeiten

Beides ist ja nicht der Fall.

Deine Formel kannst du nehmen, wenn du einen Lichtimpuls im Vakuum auf einen Spiegel gibst und berechnen willst, wie lange es dauert, bis der Lichtimpuls wieder an der Quelle ist. Das hat aber so gar nichts mit Paketen zu tun.

Selbst die Elektronen in Kupfer erreichen nicht Lichtgeschwindigkeit. Wie kommst du darauf?
 
@Minty_Insurrect: "Bin übrigens Informationstechnischer Assistent." Ah, das erklärt einiges. Dann will ich mal nicht so sein. Du hast also nach der Schule keinen Studien- bzw. Ausbildungsplatz bekommen und willst für nächstes Jahr deine Chancen verbessern irgendwo genommen zu werden. Durchaus legitim. Find ich auf jeden Fall besser als zu hartzen. Ich wünsch dir viel Erfolg, aber ändere deine Einstellung. NOCH kannst du dir diese Überheblichkeit nicht leisten.
 
@conan179: Optimal (wie reineditiert). Der absolute Mindestwert eben. Der ist natürlich je nach Übertragunsmedium unterschiedlich, ABER: innerhalb dieses Mediums nicht durch mehr Bandbreite zu verkleinern, wenn das Paket komplett durch diese Bandbreite passt.
 
@conan179: Ich bin 33, besten Dank. Und unter Leuten wie dir würde ich gar nicht arbeiten wollen, keine Angst.
 
@Minty_Insurrect: "Der absolute Mindestwert eben."
Du kannst auf keinen Fall UNTER diesen Wert kommen, soweit stimme ich dir zu. Das ist die physikalische Untergrenze. Praktisch wirst du diesen Wert NIEMALS erreichen können. Die echte Untergrenze liegt noch weit darüber.
 
@Minty_Insurrect: 33 und nur Assi? Echt jetzt? Hast du nicht weitergemacht?
 
@conan179: Warum sollte ich. Ich bin Anwendungsentwickler und ab und an als Systemintegrator unterwegs, mehr will ich nicht.
 
@Minty_Insurrect: Nun gut, hat auch Vorteile, wenn man sich seine Ziele so niedrig setzt.

Du hast aber jetzt verstanden, dass und warum die Paketlaufzeit in der Praxis von der Übertragungsgeschwindigkeit abhängt, oder?
 
@conan179: Nö. Weil das immer noch nicht so ist. Wenn das Paket nicht zu breit ist, ist die Übertragungsgeschwindigkeit egal, die Latenz bleibt auf dem gleichen Niveau.
 
@conan179: Da fällt mir auch noch ein Beispiel ein. Wenn du nämlich gleiche Bandbreite, aber unterschiedliches Medium nimmst. Sagen wir 2MBit/s DSL und 2MBit/s Satellit, dann wird sich die dauer der Dateiübertragung an sich nicht unterscheiden, per Satellit wird der Download nur später beginnen, weil die Strecke die vom ersten Paket zurückgelegt wird erheblich größer ist.
 
@Minty_Insurrect: Dann versuch ich es noch mal: ein Paket hat ja ca 1500 Bit. Die Paketlaufzeit ist die Zeit vom Absenden des ersten Bis bis zum Empfang des letzte Bits des Paketes. Die 1500 Bit werden nicht alle parallel übertragen. Also ist der Empfang des ersten Bits nicht zeitgleich mit dem Empfang des letzten Bits. Je höher die Übertragungsgeschwindigkeit, desto geringer die Zeitdifferenz vom Empfang des ersten bis zum letzten Bit und somit die Paketlaufzeit.

Deine Annahme, dass die Übertragungsgeschwindigkeit keine Auswirkung auf die Paketlaufzeit hat, würde voraussetzen, dass ALLE Bits parallel übertragen werden. Das ist ja offensichtlich nicht der Fall.
 
@Minty_Insurrect: "weil die Strecke die vom ersten Paket zurückgelegt wird erheblich größer ist."
Damit zeigst du, dass die Paketlaufzeit vom Medium abhängig ist.

Das steht aber in keinem Zusammenhang mit deiner Aussage, dass die Paketlaufzeit von der Übertragungsgeschwindigkeit unabhängig ist.
 
@conan179: Na weil die Latenz ja auch vom Medium abhängig ist und eben nicht von der reinen Übertragungsgeschwindigkeit. Das sag ich doch die ganze Zeit. Innerhalb eines Mediums ist die Latenz immer gleich, unabhängig der Übertragungsgeschwindigkeit. Es ist egal ob ich Google.de mit 2, 8 oder 16 MBit/s DSL anpinge, das wird bei gleicher Route den gleichen Wert ergeben. Wenn das 2 MBit/s DSL natürlich komplett durch Kupferkabel gejagt wird und bei 16 MBit/s komplett durch Glasfaser, dann hätte die 16 MBit/s Variante durchaus weniger Latenz.

Umgekehrt allerdings genauso.
 
@Minty_Insurrect: "Es ist egal ob ich Google.de mit 2, 8 oder 16 MBit/s DSL anpinge, das wird bei gleicher Route den gleichen Wert ergeben."
Das ist eine andere Aussage als zuvor. Der Ping-Befehl gibt ja nur ganze ms aus. Um eine Änderung im ms-Bereich zu sehen brauchst du schon größere Sprünge als von 2 auf 16 MBit/s. Was Ping dir ausgibt ist auch gar nicht die Paketlaufzeit. Es ist näherungsweise die doppelte Paketlaufzeit + sämtliche Verarbeitungszeiten. Je mehr Router o.ä. der Paket passiert, desto länger die Paketlaufzeit.

Denk mal ganz extrem, dann fällt es dir vielleicht leichter das zu verstehen.
Angenommen wir haben eine Übertragungsgeschwindigkeit von 1 Bit/s. Ein Paket mit 1500 Bits braucht also 1500 s. Jetzt verzehnfachen wir die Übertragungsgeschwindigkeit indem wir 10 Bits parallel übertragen. Das Paket braucht jetzt nur noch 150 s. Durch die zehnfache Übertragungsgeschwindigkeit haben wir die Paketlaufzeit auf ein Zehntel verkürzt.

Dieses Beispiel gilt natürlich nur für die direkte Kommunikation zweier Netzwerkgeräte. Jeder Switch o.ä. der dazwischen ist muss ja warten, bis das gesamte Paket angekommen ist, bevor er es weiter verarbeitet. Somit wird die Paketlaufzeit noch stärker von der Übertragungsgeschwindigkeit beeinflusst. (In der Realität hast du aber verschiedene Strecken mit verschiedenen Geschwindigkeiten. Ob du einen 2 oder 16 MBit-Anschluss hast beeinflusst natürlich nur die Strecke von dir bis zum DSLAM)

Wenn du statt 1 Bit/s ein Vielfaches nimmst bleibt ändert es nichts am grundlegenden Prinzip.

War das einigermaßen verständlich?
 
@conan179: Das holst du jetzt aber echt sehr weit her. Andererseits wäre das eine Bit bei der 1 Bit/s Leitung aber genauso schnell da wie 1500 Bit bei einer 1500 Bit/s Leitung, wenn man alles andere mal rausrechnet. Das ist für mich Latenz.

Wenn die Bandbreite nicht mal im entferntesten ausreicht ein Paket komplett zu verschicken ist schon klar das es länger dauert, aber das liegt dann doch an der Bandbreite und nicht an der Latenz (also der Strecke). Jedes der Bits würde mit der Latenz ankommen, weil die Bandbreite nicht reicht, während ansonsten praktisch alle Bits gleichzeitig in der Latenz ankommen.

Praktisch

1500*Latenz
versus
1*Latenz

Aber die Latenz ist immer noch da. Sie verschwindet nicht aufgrund der höheren Bandbreite. Die niedrigere Bandbreite macht sie nur Spürbarer, weil sie die Latenz um ein vielfaches multipliziert. Dafür wird aber bei 3000 Bit/s ein 1500 Bit Paket nicht schneller übertragen als ein 3000 Bit Paket. Wenn man überhaupt von einer Abhängigkeit bei Bandbreite und Latenz sprechen kann, dann nur wenn die Bandbreite zu gering ist um ein einzelnes Paket zu übertragen. Ansonsten ist die Latenz für jedes Paket die gleiche.

Und das ein Paket zu groß für die Bandbreite ist, das wäre ein arger Designfehler, denn dann könnte man sich das verpacken in Pakete auch direkt sparen und Bit für Bit senden.
 
@Minty_Insurrect: "Das holst du jetzt aber echt sehr weit her. Andererseits wäre das eine Bit bei der 1 Bit/s Leitung aber genauso schnell da wie 1500 Bit bei einer 1500 Bit/s Leitung, wenn man alles andere mal rausrechnet. Das ist für mich Latenz."
Du sprachst von Paketlaufzeit! Die Latenz setzt sich aus verschiedenen Zeiten zusammen, die Paketlaufzeit ist eine davon.

"Wenn man überhaupt von einer Abhängigkeit bei Bandbreite und Latenz sprechen kann, dann nur wenn die Bandbreite zu gering ist um ein einzelnes Paket zu übertragen. Ansonsten ist die Latenz für jedes Paket die gleiche."
Du hast offensichtlich ein paar Schwierigkeiten mit den Begriffen.
Dass die Anzahl der GLEICHZEITIG (also parallel) übertragenen Bits die Anzahl der Bits in einem TCP-Paket übersteigt ist absolut normal. Wenn du das mit einer 'normalen' Übertragung parallel machen wolltest, bräuchtest du 1500 Leitungen. Wenn du das mit einer Leitung machen wolltest, dann müsstest du 1500 Frequenzen GLEICHZEITIG nutzen. Das ist bei deiner Internetverbindung nicht der Fall.

"Und das ein Paket zu groß für die Bandbreite ist, das wäre ein arger Designfehler, denn dann könnte man sich das verpacken in Pakete auch direkt sparen und Bit für Bit senden."
Wie schon gesagt: Bits und Pakete befinden sich auf unterschiedlichen OSI-Layern. Das ist nun mal so wie es gemacht wird.

So langsam merkste, dass dein überhebliches Verhalten deplatziert war, oder? Dir fehlt ja sogar das grundlegende Verständnis für Nachrichtentechnik.
 
@conan179: "Du sprachst von Paketlaufzeit! Die Latenz setzt sich aus verschiedenen Zeiten zusammen, die Paketlaufzeit ist eine davon."

Ich hab die ganze Zeit von Latenz gesprochen. Du hast Paketlaufzeit plötzlich eingebracht, daher dachte ich du meinst damit das gleiche.
Edit: Genauer gesagt dachte ich du meinst RTT, also Paketumlaufzeit.

"Du hast offensichtlich ein paar Schwierigkeiten mit den Begriffen.
Dass die Anzahl der GLEICHZEITIG (also parallel) übertragenen Bits die Anzahl der Bits in einem TCP-Paket übersteigt ist absolut normal. Wenn du das mit einer 'normalen' Übertragung parallel machen wolltest, bräuchtest du 1500 Leitungen. Wenn du das mit einer Leitung machen wolltest, dann müsstest du 1500 Frequenzen GLEICHZEITIG nutzen. Das ist bei deiner Internetverbindung nicht der Fall."

Man benutzt höhere Frequenzen. Da kann man in die gleiche Zeit mehr Daten hineinpacken. 1500 Hz zu verwenden würde nicht mehr Daten übertragen können als 1500 x 1 Hz (gleichzeitig über verschiedene Kabel natürlich) zu verwenden. Das macht die ganze Sache erheblich kompakter, aber nicht schneller als wenn man das mit Einzelleitungen machen würde.

"Wie schon gesagt: Bits und Pakete befinden sich auf unterschiedlichen OSI-Layern. Das ist nun mal so wie es gemacht wird."
Öhm, die Layer wären aber witz- und nutzlos wenn man nur 1 Bit/s übertragen könnte und haben somit keinerlei Relevanz für dein Extrembeispiel.

"So langsam merkste, dass dein überhebliches Verhalten deplatziert war, oder? Dir fehlt ja sogar das grundlegende Verständnis für Nachrichtentechnik."
Ich merk gar nix, außer das du immer noch Unsinn schreibst.
 
@Minty_Insurrect: Nein, DU hast mit der Paketlaufzeit angefangen: ""Ne, du hast nur keine Ahnung, das ist alles. Ob mein DSL 10kb/s Upload hat oder 5000Kb/s, an der Paketlaufzeit ändert sich 0.""

"Man benutzt höhere Frequenzen. Da kann man in die gleiche Zeit mehr Daten hineinpacken. 1500 Hz zu verwenden würde nicht mehr Daten übertragen können als 1500 x 1 Hz (gleichzeitig über verschiedene Kabel natürlich) zu verwenden. Das macht die ganze Sache erheblich kompakter, aber nicht schneller als wenn man das mit Einzelleitungen machen würde."
Die einzelnen Bits sind natürlich schneller.

"Öhm, die Layer wären aber witz- und nutzlos wenn man nur 1 Bit/s übertragen könnte und haben somit keinerlei Relevanz für dein Extrembeispiel."
Wenn du meinst, dass OSI-Layer nur ab einer bestimmten Übertragungsgeschwindigkeit sinnvoll wären, dann hast du absolut NICHTS vom ISO/OSI-Modell verstanden.

"Ich merk gar nix, außer das du immer noch Unsinn schreibst."
DU schreibst doch den Unsinn. Du verstehst ja noch nicht einmal, dass OSI nichts mit der Übertragungsgeschwindigkeit zu tun hat. Selbst als Assi solltest du das wissen.

Um zu zeigen, dass das was du denkst zu wissen völliger Blödsinn ist: erklär doch bitte, WARUM "die Layer [..] witz- und nutzlos [wären]" und ab welcher Geschwindigkeit sie es nicht mehr wären.
 
@conan179: "Nein, DU hast mit der Paketlaufzeit angefangen"
Nein, du hast das als erstes erwähnt. Ist nur nicht mehr da, wegen Doppelpost. Ist aber auch egal.

"Die einzelnen Bits sind natürlich schneller."
Hmm? Du meinst 1500 Bit über verschiedene Leitungen jeweils 1 Bit zu übertragen wäre schneller als 1500 Bit über eine Leitung mit 1500 Bit?

"Wenn du meinst, dass OSI-Layer nur ab einer bestimmten Übertragungsgeschwindigkeit sinnvoll wären, dann hast du absolut NICHTS vom ISO/OSI-Modell verstanden."
Natürlich macht das nicht erst ab einer bestimmten Übertragungsgeschwindigkeit Sinn, sondern erst bei mindestens zwei verschiedenen. Bei 1 Bit/s machen extra definierte Protokolle null Sinn, weil man ohnehin nur Bit für Bit übertragen könnte. Es gäbe nur 2 Zustände, 1 & 0, eine Schnittstelle, ein Protokoll. Es gäbe schlicht keinen Nutzen für unterschiedliche Schnittstellen, weil immer nur 1 Bit zur gleichen Zeit übertragen werden könnte. Da OSI nur ein konzeptionelles Model ist das die Aufgabe hat Kommunikation unter vielen Technischen Systemen übersichtlich zu halten, wäre es unnütz wenn es nicht mindestens 2 verschiedene Übertragungsgeschwindigkeiten gäbe. Man könnte erst gar nicht Abstrahieren, weil das eine Bit schon das Abstrakteste im IT-Wesen ist.
 
@Minty_Insurrect:
""Die einzelnen Bits sind natürlich schneller."
Hmm? Du meinst 1500 Bit über verschiedene Leitungen jeweils 1 Bit zu übertragen wäre schneller als 1500 Bit über eine Leitung mit 1500 Bit?"

bei 10 KBit ist ein Bit schneller übertragen, als bei 1 KBit.
Stell dir ein Zeitliniendiagramm vor:

010 bei niedriger Geschwindigkeit: __________----------__________
010 bei hoher Geschwindigkeit:_-_

Du siehst deutlich, dass das obere Diagramm viel länger ist als das untere.

"Natürlich macht das nicht erst ab einer bestimmten Übertragungsgeschwindigkeit Sinn, sondern erst bei mindestens zwei verschiedenen"
Tu dir selbst einen Gefallen und lern mal, wofür ISO/OSI da ist. Die Geschwindigkeit ist doch nur auf der untersten Schicht relevant. Die darüberliegenden Schichten haben damit gar nichts zu tun und wissen auch nichts davon. Auch bei einer Geschwindigkeit ist es sinnvoll.

"Bei 1 Bit/s machen extra definierte Protokolle null Sinn, weil man ohnehin nur Bit für Bit übertragen könnte."
Man kann auch 2 Bits parallel mit jeweils 0,5 Bit/s übertragen und kommt dann auf 1 Bit/s. Das einzige was hier keinen Sinn ergibt ist deine Aussage.

"Es gäbe nur 2 Zustände, 1 & 0, eine Schnittstelle, ein Protokoll." Es gibt doch immer nur diese zwei Zustände. Eine 2 oder so wirst du nicht finden...
Die unterste Schicht hat was mit der Hardware zu tun. Weiter oben hast du z.B. TCP/IP. Ganz oben ist die Anwendungsschicht. Das sind alles Dinge, die nichts miteinander zu tun habe. Weil es bei den Schichten jeweils um unterschiedliche Dinge geht ist es sinnvoll, das so zu machen - absolut unabhängig von der Übertragungsrate.

"Da OSI nur ein konzeptionelles Model ist das die Aufgabe hat Kommunikation unter vielen Technischen Systemen übersichtlich zu halten, wäre es unnütz wenn es nicht mindestens 2 verschiedene Übertragungsgeschwindigkeiten gäbe. Man könnte erst gar nicht Abstrahieren, weil das eine Bit schon das Abstrakteste im IT-Wesen ist."
Sorry, diese Aussage ist sowas von falsch und unsinnig, da kann selbst ich dir nicht helfen. Wie kommst du auf sowas?!
 
Uj geil. Gleich angemeldet. Bin gespannt, wie es läuft.
die USA Beta lief überraschend gut.
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles