Google glaubt: Stadia hat in zwei Jahren weniger Latenz als ein PC

[cryptochrome]

Ob sie gesondert stehen oder integriert werden ist unabhängig von der Frage nach der Existenz. Aktuell hat Google aber keinen Bedarf an 3D-Beschleuniger in den öffentlichen Serverfarmen und eine Stadia-Entwicklungsumgebung am Hauptsitz hätte viel zu lange Latenzen in andere Teile der Welt. Also gilt für Großtests wie Stadia auf der Gamescom sowieso: Es müssen extra Racks in Betrieb genommen. Das machen sie garantiert nicht an einem entfernten Standort, der den Durschnitts- oder gar Worst-Case-Fall des späteren Roll-Outs entspricht, sondern idealerweise auf dem gleichen Gelände. Warum sollte ich für eine global übertragene Live-Demo einen kölner Internet-Anschluss anbieten und die extra herbeigekarte Hardware in einem externen Rechenzentrum installieren, wenn sich auch in Ethernet-Reichweite aufbauen kann?

Im Best Case stand der Server direkt hinter der Bühne

Und genau hier liegt deine wirklich krasse Fehleinschätzung. Es gibt nicht "den" Stadia Server. Erst recht nicht den einen, den man schnell mal irgendwo hinter einer Bühne verstaut. Stadia ist ein extrem komplexes Gebilde aus unterschiedlichsten Diensten, die allesamt verteilt laufen und nicht auf einzelnen Servern konzentriert sind. An der Stelle nochmal der Hinweise auf die GDC Breakout Sessions mit der detaillierten Erklärung der Architektur.

Google hätte ein halbes RZ auf die Gamescom schaffen und installieren müssen, um Dein skizziertes Szenario zu verwirklichen.

Nix für Ungut, aber das geht jetzt echt alles ziemlich in Richtung Aluhut.

Aktuell hat Google aber keinen Bedarf an 3D-Beschleuniger in den öffentlichen Serverfarmen

Doch, haben sie. Seit Jahren. Die Google Datacenters stehen voll mit nVidia GPUs, die für Machine Learning eingesetzt werden. Übrigens ein Service, den man auch den Geschäftskunden auf der Google Cloud Platform anbietet. Google entwickelt zwar seit ein paar Jahren schon eigene Hardware dafür (Tensor Processing Units), das ändert aber nichts an der Tatsache, dass bereits heute regelrechte GPU Farmen in den GCP Pods sitzen:

NVIDIA und Google Cloud Platform | Google Cloud
Grafikprozessorbeschleunigte Google Cloud Platform

Für Stadia werden zusätzlich GPUs von AMD (auf Basis Vega 56) eingesetzt. Und auch das in Massen. Und da Google bereits seit rund 5 Jahren an Stadia baut, kannst Du davon ausgehen, dass diese auch in den Deutschen Rechenzentren bereits ausgerollt sind - erst recht so kurz vor dem Marktstart. Hatten sie auf der Gamescon einen eigenen Internet Uplink? Vielleicht. Aber dass sie Stadia Ressourcen direkt auf der Messe aufgebaut haben, ist - mit Verlaub - ziemlicher Mumpitz.

 

[Master_Bytez]

Du wieder sprichst dich doch gerade selbst cryptochrome. Im ersten Teil sagst du Stadia ist nicht ein bestimmter Typ Server, sondern eine Art "Programm/Technik" welche auf dem schon bestehenden Google Netzwerk läuft.
Im zweiten Teil schafft Google für Stadia AMD GPUs an...….
Auf der Gamescon über das Hausnetz Cloud Spiele zu Zocken halte ich für Aluhut.

 

[PCGH_Torsten]

Und genau hier liegt deine wirklich krasse Fehleinschätzung. Es gibt nicht "den" Stadia Server. Erst recht nicht den einen, den man schnell mal irgendwo hinter einer Bühne verstaut. Stadia ist ein extrem komplexes Gebilde aus unterschiedlichsten Diensten, die allesamt verteilt laufen und nicht auf einzelnen Servern konzentriert sind. An der Stelle nochmal der Hinweise auf die GDC Breakout Sessions mit der detaillierten Erklärung der Architektur.

Google hätte ein halbes RZ auf die Gamescom schaffen und installieren müssen, um Dein skizziertes Szenario zu verwirklichen.

Nix für Ungut, aber das geht jetzt echt alles ziemlich in Richtung Aluhut.


Doch, haben sie. Seit Jahren. Die Google Datacenters stehen voll mit nVidia GPUs, die für Machine Learning eingesetzt werden. Übrigens ein Service, den man auch den Geschäftskunden auf der Google Cloud Platform anbietet. Google entwickelt zwar seit ein paar Jahren schon eigene Hardware dafür (Tensor Processing Units), das ändert aber nichts an der Tatsache, dass bereits heute regelrechte GPU Farmen in den GCP Pods sitzen:

NVIDIA und Google Cloud Platform | Google Cloud
Grafikprozessorbeschleunigte Google Cloud Platform

Für Stadia werden zusätzlich GPUs von AMD (auf Basis Vega 56) eingesetzt. Und auch das in Massen. Und da Google bereits seit rund 5 Jahren an Stadia baut, kannst Du davon ausgehen, dass diese auch in den Deutschen Rechenzentren bereits ausgerollt sind - erst recht so kurz vor dem Marktstart. Hatten sie auf der Gamescon einen eigenen Internet Uplink? Vielleicht. Aber dass sie Stadia Ressourcen direkt auf der Messe aufgebaut haben, ist - mit Verlaub - ziemlicher Mumpitz.

Wenn du Bezug auf eine bestimmte Session nehmen möchtest, würde ein Link das Verständnis deutlich erleichtern. Eine "Breakout Session" zu Stadia konnte ich mit Google jedenfalls nicht finden. Ich kenne den GDC Deep Dive, aber der enthält keine Angaben zur technischen Basis für Stadia (nur Werbung für das Google-Netzwerk allgemein) und trotz sehr detaillierter Angaben zum Software-Konzept keinen einzigen Hinweis auf ein aus "unterschiedlichsten [bekannten] Diensten [bestehendes] komplexes Gebilde". Und Google braucht garantiert kein "halbes Rechenzentrum", um die beschränkte Client-Zahl der Gamescom zu bewältigen. Weder von der Gesamtleistung her, die mit bezahlbaren Aufwand auf Millionen von Nutzer skalieren soll, noch von der Minimalausstattung her, die für Entwicklungs- und Testzwecken auch auf wesentlich kleineren Systemen bei entsprechend reduzierter Client-Zahl laufen muss. Der Aufbau von Spiele-Engines und der Inhalt von Spielen schließen es quasi aus, dass überhaupt mehrere Rechner an einem Prozess arbeiten; auf alle Fälle sollte man es zugunsten der Latenz möglichst vermeiden. Falls Google die Client-Verwaltung und die Streaming-Kompression auslagert, braucht eine Stadia-Minimal-Konfiguration vielleicht drei Rack-Einschübe; wenn das vom Host-System der Grafikkarten respektiven getrennten Add-Ins erledigt wird, reicht ein einzelner. Für die Zahl der Gamescom-Terminals würde ich maximal ein Rack erwarten, eher deutlich weniger, und Hardware für die älteren Einzel-Demos hätte man im µATX-Format, ggf. noch kleiner realisieren können.

Was dagegen deutlich schlechter geht: Die bestehenden Cloud-Angebote mit Kepler-, Pascal- und Volta-Teslas (sowie einigen 75-W-Turings) für Gaming-Berechnungen zu nutzen. Weder sind die Beschleuniger dafür übermäßig gut geeignet, noch mit dem Fokus auf Low-Latency in Rechenzentren verbaut worden, wohl kaum mit dedizierten Hardware-Encodern für flottes Streaming ausgestattet worden und vermutlich sind sie auch nicht die optimale Grundlage für die Radeon-optimierte Stadia-Software, die an mehreren Stellen sehr tief in die Spiele-Engines eingreifen möchte und somit zumindest langfristig nicht auf normale Windows/DirectX-HALs aufbauen kann.
Wofür sich die bestehende Infrastruktur dagegen gut geeignet: Teuer vermieten. Was man nicht mehr könnte, wenn man große Teile des Parks für Gaming frei halten muss.

Das Teile der neu aufzubauenenden AMD-Infrastruktur schon drei Monate vor dem bislang genannten Starttermin in Deutschland einsatzbereit wären, ist aber in der Tat denkbar. Wie die mit der Messehalle verbunden wurde, wäre zu klären. Aber nicht mit Gamescom-(W)LAN.

 

[cryptochrome]

Du wieder sprichst dich doch gerade selbst cryptochrome. Im ersten Teil sagst du Stadia ist nicht ein bestimmter Typ Server, sondern eine Art "Programm/Technik" welche auf dem schon bestehenden Google Netzwerk läuft.
Im zweiten Teil schafft Google für Stadia AMD GPUs an...….

Das ist kein Widerspruch. Ich kann Dir nur empfehlen, Dich mal etwas mit Cloud Architekturen auseinander zu setzen, sonst reden wir weiterhin aneinander vorbei. Und mit Cloud ist an der Stelle kein Dropbox und Konsorten gemeint. Jedenfall ist nichts von dem, was ich sagte, ein Widerspruch.

Wenn du Bezug auf eine bestimmte Session nehmen möchtest, würde ein Link das Verständnis deutlich erleichtern. Eine "Breakout Session" zu Stadia konnte ich mit Google jedenfalls nicht finden.

Ich habe spontan noch das hier in meinen Bookmarks gefunden:
YouTube YouTube
YouTube

Hier findest Du noch mehr:
GDC | Stadia

Ich kenne den GDC Deep Dive, aber der enthält keine Angaben zur technischen Basis für Stadia (nur Werbung für das Google-Netzwerk allgemein) und trotz sehr detaillierter Angaben zum Software-Konzept keinen einzigen Hinweis auf ein aus "unterschiedlichsten [bekannten] Diensten [bestehendes] komplexes Gebilde".

Dir (und einigen anderen hier) fehlt offensichtlich das Verständnis dafür, wie "Cloud" funktioniert. Und wie große, verteilte Compute Systeme funktionieren. Ihr seid mit Euren Gedanken viel zu sehr auf das fixiert, womit Ihr Euch täglich beschäftig: PCs. Dass Stadia ein komplexes Gebilde ist, das auf verteilten Systemen läuft, ergibt sich nicht nur aus dem Video, das Du verlinkt hast, sondern schon alleine daraus, wie Cloud funktioniert. Es ist nicht so, dass es "den" Stadia Server gibt, der dann einfach 10.000 mal repliziert wird. Die Sache ist wesentlich komplexer als das. Wir reden über separate Encoder Maschinen, über mit Kubernetes virtualisierte Applikationen, die on demand gestartet werden, über Loadbalancer, Web Server, Rendering Maschinen (GPU), Proxies, Router, TPU Farmen für KI, Integration in Youtube, und und und. Dazu kommen zusätzliche Dienste wie Crowd Play, Crowd Choice, State Share und Stream Connect. Es ist völlig abwegig anzunehmen, man könne ein solch komplexes System mal eben auf drei Server packen und hinter einer Messebühne verstecken.

Und Google braucht garantiert kein "halbes Rechenzentrum", um die beschränkte Client-Zahl der Gamescom zu bewältigen.

Es geht nicht darum, eine beschränkte Client Anzahl zu bewältigen. Sondern darum, dass das System, das Stadia in Summe ausmacht, nicht einfach mal auf drei Servern hinter die Bühne gepackt werden kann. Siehe oben. Dafür wäre ein weit höherer Aufwand nötig.

Du gehst davon aus, dass es nicht gut funktioniert. Und ziehst Dir mögliche Begründungen dafür an den Haaren herbei. Dass Google auf der Messe mit einem getürkten Setup auftaucht, nur um zu verschleiern, dass das Produkt eigentlich nicht "at scale" funktioniert, ist schon *sehr* weit hergeholt.

Der Aufbau von Spiele-Engines und der Inhalt von Spielen schließen es quasi aus, dass überhaupt mehrere Rechner an einem Prozess arbeiten;

Das weißt Du doch gar nicht. Stadia ist eine komplett neue Plattform. Spiele Engines müssen an Stadia angepasst werden. Spiele müssen komplett neu für Stadia entwickelt oder portiert werden. Es ist doch auch heute schon so - so ganz ohne Stadia - das Multiplayer Games zu großen Teilen in der "Cloud" berechnet werden - auf verteilten Systemen. Apex Legends z.B. läuft komplett in der Google Cloud. Auf verteilten Systemen.

Was dagegen deutlich schlechter geht: Die bestehenden Cloud-Angebote mit Kepler-, Pascal- und Volta-Teslas (sowie einigen 75-W-Turings) für Gaming-Berechnungen zu nutzen.

Das habe ich auch gar nicht behauptet. Ich wollte nur aufzeigen, dass es durchaus Bedarf für GPUs in Googles Cloud (und nebenbei, selbstverständlich auch in Azure und AWS) gibt. Dein Einwand, es gäbe kein Bedarf und deshalb müsse man die Existenz in Frage stellen, stimmt einfach nicht. Dass Stadia diese GPUs nicht für das Game Rendering verwendet, ist klar. Daher auch mein Hinweis auf die AMD GPUs.

Weder sind die Beschleuniger dafür übermäßig gut geeignet, noch mit dem Fokus auf Low-Latency in Rechenzentren verbaut worden, wohl kaum mit dedizierten Hardware-Encodern für flottes Streaming ausgestattet worden und vermutlich sind sie auch nicht die optimale Grundlage für die Radeon-optimierte Stadia-Software, die an mehreren Stellen sehr tief in die Spiele-Engines eingreifen möchte und somit zumindest langfristig nicht auf normale Windows/DirectX-HALs aufbauen kann.

Windows spielt bei Stadia keine Rolle. Stadia basiert auf Debian Linux und Vulkan. Es gibt wohl eine DirectX Schnittstelle, ich habe aber bisher noch nicht genau verstanden, wie die implementiert ist. Fakt ist jedenfalls, dass Stadia linuxbasiert ist und was auch immer auf Stadia laufen soll, nicht ohne tief greifende Veränderungen vonstatten geht. Siehe unter anderem das Video von id, wie sie Doom auf Stadia entwickelt haben (Link siehe oben).

 

[Cheytac]

Ist ja alles schön und gut, ABER: Selbst wenn eine Vorausberechnung gelingen würde, müsste er ja noch auf die tatsächliche Eingabe warten, um zu schauen, ob die Vorausberechnung passt. Wenn die eben nicht passt, wird mit dem eigentlichen Befehl überschrieben.
Mir ist an der Stelle nicht klar, wo hier eine Zeitersparnis erfolgen soll.

Wenn die Voraussage passt ist das Frame bereits vorbereitet (oder zumindest bereits im Zusammenbau) und kann gleich zurückgegeben werden. Hier spart man sich die Zeit für einen Durchlauf der Rendering-Pipeline.

Wenn die Voraussage nicht passt wird das vorausberechnete Frame verworfen und ein "reguläres" Frame aus der normalen Rendering-Pipeline zurückgegeben. In diesem Fall habe ich keinen Vorteil und muss wie bisher warten bis ein Frame mit dem neuen Input komplett berechnet wurde, damit ich die Reaktionen auf meine Eingabe sehen kann.

 

[Master_Bytez]

…………………………………………..

Bauernfängerei
Beschreibung:
Bauernfängerei bezeichnet eine Art von Täuschung bis hin zum Betrug, bei der davon ausgegangen wird, dass ein Vertragspartner die Modalitäten entweder nicht versteht oder relevante Passagen überliest.

 

[SIR_Thomas_TMC]

Warum fühltest Du Dich eigentlich angesprochen?

Weil du deine Aussage verallgemeinert hattest. Und weil ich die Überschrift Fanboy für die Argumentation nachvollziehen kann. Er hat ja im selben Post als er Fanboy gesagt hatte, auch noch erklärt warum er das so sieht, sprich die Argumente, die du im nächsten Post eingefordert hast, schon vorab mitgeliefert. Du hast dir aber den Begriff rausgezogen, und dann die Aussage nur darauf reduziert. Das Spiel hab ich mitgespielt und deine Aussage nur an zwei kleinen Stellen umformuliert, damit du siehst, dass man in dem Stil genauso auch das Gegenteil behaupten kann.

Dass der Umgangston hier im Forum ziemlich häufig ziemlich heftig entgleist, ist doch nichts Neues.

Würde ich nicht so pauschal zustimmen. Allenfalls, dass es durchaus passiert. War aber insbesondere in diesem Thread nicht so, trotzdem hast du es ein wenig so dargestellt.

Zum einen habe ich nicht nach Quellen bzgl. Latenz auf der Messe gefragt.

Ne, nach Quellen bezüglich der Behauptung, es gäbe extra lokal aufgebaute Server. Wozu du das Gegenteil behauptet hattest. Aber auch ohne jegliche Quelle.

Zum anderen hast Du mit Deiner Aussage, dass man das auch über Microsoft und deren gescheitertes Smartphone Business hätte sagen können, natürlich vollkommen recht. Da muss ich nichts abwehren.

Genau, könnte man so sagen, wäre da aber genauso falsch. Es gibt nun mal nicht den too-big-too-fail Masterplan.

Zumal es mühsam ist, mit jemandem zu diskutieren, der auf Krawall gebürstet ist und dem es offensichtlich nur um Konfrontation geht.

Falls du mich meinst, bin ich eigentlich nicht. Falls es so ankommt, ist nicht so gemeint. Aber in der Sache bin ich schon hartnäckig.

Mir gehts hier nicht darum, unbedingt recht zu haben, sondern eine sachliche Diskussion zu führen - bei der man was lernen kann und weil es mich interessiert.

Find ich gut. Halte aber, Argumente habe ich ja schon zuhauf gebracht, eine deiner Kernaussagen (ist Unternehmen XYZ, die machen das nur wenn es was taugt) so pauschal für Unsinn. Ein, die haben sich sicher Gedanken gemacht und gehen sehr stark davon aus, dass sie damit Erfolg haben, ist dagegen nichts abzusprechen. Denn der, die denken also wird es so werden Teil ist darin eben nicht enthalten.

Auch da stimme ich Dir zu. Ich finde aber, dass hier viel Wind um nichts gemacht wird. Immerhin handelt es sich nicht um irgendwelche großen Ankündigungen von Google, die irgendwo von einer Marketingabteilung aufbereitet auf der Stadia Website prangen würde, sondern um einen Nebensatz, der in einem Interview mit einem Google Mitarbeiter gefallen ist.

Ok, der Teil ist für mich auch tatsächlich absolut nachvollziehbar und auch ein gutes Argument. Bei mir hat das halt ob der physikalischen Unmöglichkeit für Gelächter und Kopfschütteln gesorgt.

Das wird nun von den Medien ausgeschlachtet - auch von der PCGH. Dabei ist das doch völlig unerheblich.

Für dich. Falls mal wer sagt, natürlich gibt es keine negative latenz, das hatten wir falsch ausgedrückt. Dann wäre für mich die Relevanz auch weg. So bin ich noch der Meinung, dass man das auch gerne so bezeichnen möchte.

Unterm Strich gehts nur darum, ob Stadia gut genug funktioniert, um eine große Anzahl Spieler zufrieden stellen zu können. Und bisher habe ich nichts gesehen, das wirklich fundamental dagegen sprechen würde. Stadia wird seinen Markt finden - sicher nicht bei den PCGH Lesern, aber durchaus in einer breiten Masse. Das ist absehbar. Schließlich sind Google nicht die einzigen, die sowas machen. Microsoft, Amazon, Sony, EA, Nvidia... alles, was Rang und Name hat, arbeitet an Game Streaming Diensten.

Und bis hier hin hast du meine absolute Zustimmung.

Experimente kann sich kein börsennotiertes Unternehmen wirklich leisten. Also ist davon auszugehen, dass das alles schon irgendwie Hand und Fuß haben wird.

Und hier schaue ich ob der schon gebrachten Beispiele und Erklärungen fassungslos zu, wie du das weiter einfach so behauptest. Ich meine, ich muss (und werde anscheinend) dich auch nicht überzeugen können, dass genau der Part halt Unfug ist. Aber es verblüfft mich immer wieder, wie man so über die Argumente dazu drüber weg gehen kann. Da fühle ich mich als diskussionsfreudiger Mensch einfach zu einer weiteren sachlichen Antwort herausgefordert.

 

[4thVariety]

Cloud ist nur ein PR Schlagword für netzwerkbasierenden Dienste die immer noch einen Server irgendwo brauchen. Cloud ist kein technischer Prozess der irgendwie Normiert ist, im Gegensatz zu Technologien wie VDSL. Im Falle von Stadia wird ein einzelnes Stadia ca. die Größe einer 270 mit Kühlkörper haben, minus die individuelle Ventilation. Egal was ist, man wird vielleicht nicht wissen welches Stadia mit welcher Seriennummer man gerade spielt, aber eines davon wird man spielen.

Es wird auch ständig das Wort Rechenzentrum benutzt, dabei ist das so präzise als würde man zu allem Auto sagen, angefangen von einem VW Polo, über einen Reisebus, bis hin zu einem 40 Tonner.

Aber bei Autos sieht man sich ja auch an, was deren Spezialität ist und danach benutzt man speziellere Begriffe. Ein Rennauto ist auf Rennen getrimmt, ein Transporter auf Paketauslieferung.

Die meisten Rechenzentren sind auf Datendichte getrimmt. Exabytes an Daten die hin oder hergeschoben werden. So gut der Internetanschluss auch immer sein mag, es ist würde man den Bodensee über einen kleinen Bach aufstauen. Das dauert. Solche Rechenzentren bestehen auf Jahrzehnten von Know-How in Sachen Stomlast, Hitzeverteilung, Hitzemanagement, Notfallströme, Stromspitzen, etc. Wenn man erst einmal eine monatliche Stromrechnung im Millionenbereich an der Backe kleben hat, dann richtet sich der Preis vor allem nach der Spitzenlast. Zu einem effizienten Rechenzentrum gehört vor allem also, dass man nicht groß im Verbrauch schwankt.

Die Stadia Rechenzentren, oder auch die von Nvidia, sind mit diesen herkömmlichen Datenbatterien im Amazon Web Service Stil nicht zu vergleichen. Völlig andere Anforderungen. Viel mehr Hitze konzentriert auf viel weniger Raum, dadurch viel höhere Anforderungen an das Kaltluftmanagement. Krass höhere Anforderung an die Bandbreite, weil jeder Schluckauf ein Nadelstich gegen das Produkt. Wenn Netflix mal eine Minute Weg ist, bekommt man das gar nicht mit. Dann der Stromverbraucht der ständig Schwankungen haben wird pro Stadia (Standby-> Connect -> Titelschirm -> im Spiel -> Pause ->Fortsetzen). Das sind Brot und Butter Operationen die ständig passieren und pro Gerät für Schwankungen sorgen, die man auf ein ganzes Computezentrum betrachtet erst einmal abgefangen werden müssen. Sowas hat man nicht, wenn einfach nur ein Exabyte an Daten irgendwo rumschimmelt.

Fragt nicht Google, fragt nicht Hetzner, fragt einen Supercomputerbetreiber, was der so für Probleme hat die ein normaler Datenhoster nicht hat. So ein Datenzentrum zu einem Produkt zu entwickeln, das wirklich einen Massenmarkt erreicht und nicht nur ein Prrof of Concept für 10.000 Leute ist, das ist die Herausforderung.

 

[cryptochrome]

Cloud ist nur ein PR Schlagword für netzwerkbasierenden Dienste die immer noch einen Server irgendwo brauchen. Cloud ist kein technischer Prozess der irgendwie Normiert ist, im Gegensatz zu Technologien wie VDSL.

Im Grunde richtig, allerdings ist man sich heute schon so ziemlich darüber einig, was Cloud eigentlich ist (und nein, es sind nicht die Online Speicher Dienste wir Dropbox, die der Konsument üblicherweise als Cloud bezeichnet). Dienste wie Google's GCP, Amazon's AWS und Microsoft's Azure. Und es gibt durchaus "Normen" in Form von eingesetzter Software und den Diensten, die innerhalb einer Cloud laufen. Kubernetes, OpenStack, KVM, Ceph, Xen, Istio, Envoy, Apache Mesos, Docker Swarm...

Und selbstverständlich werden auch noch Server benötigt, das steht doch überhaupt nicht in Abrede. Der Unterschied zu "konventionellen" Architekturen ist aber, dass "der Server" nicht mehr als Einzelmaschine herhält, auf der ein bestimmter Dienst läuft, sondern dass Server gepoolt werden, also viele Server zu einer Einheit verwachsen, um es mal simpel auszudrücken, auf der dann verteilte Compute und Storage Workloads laufen. Die meisten Server in Cloud Architekturen sind nur noch Hypervisoren, der rest ist komplett virtualisiert - und eben verteilt. Applikationen laufen nicht mehr auf einem einzelnen Server, sondern auf vielen.

Im Falle von Stadia wird ein einzelnes Stadia ca. die Größe einer 270 mit Kühlkörper haben, minus die individuelle Ventilation. Egal was ist, man wird vielleicht nicht wissen welches Stadia mit welcher Seriennummer man gerade spielt, aber eines davon wird man spielen.

Das ist fast richtig. Bei Stadia gibt es Instanzen, denen Spieler zugeteilt werden. Der Spieler bekommt aber nicht eine komplette physische Einheit zugeteilt, sondern eine virtuelle, von denen mehrer auf einer physischen Einheit parallel laufen. Die virtuellen Instanzen können von Server zu Server wandern, je nach Auslastung. Und zwar live. Selbes Prinzip wie VMware Motion. Abgesehen von den Instanzen, auf denen Spieler unterwegs sind, gibt es aber eine Vielzahl von zusätzlichen Komponenten, die eben nicht auf diesen Instanzen beheimatet sind, sondern auf anderen Teilen der Infrastruktur laufen. Google hat das am Beispiel der TPUs festgemacht, die in separaten Server Farmen stecken und von den Gaming Instanzen angesprochen werden, wenn KI-Berechnungen im Spiel benötigt werden. Google hat auch beschrieben, dass es separate Rendering Maschinen gibt, in denen mehrere GPUs stecken, die ebenfalls virtualisiert werden und separat für Multi-GPU Rendering angesprochen werden können.

Die Stadia Rechenzentren...

...sind die vorhandenen GCP Rechenzentren. Es gibt keine separaten Stadia Rechenzentren.

, oder auch die von Nvidia, sind mit diesen herkömmlichen Datenbatterien im Amazon Web Service Stil nicht zu vergleichen.

Selbstverständlich sind die Google GCP RZs mit denen von Amazon AWS vergleichbar. Es handelt sich um nahezu identische Dienstleistungen, die beide Unternehmen da anbieten.

Google Cloud Platform | UEberblick
| Google Cloud

Völlig andere Anforderungen. Viel mehr Hitze konzentriert auf viel weniger Raum, dadurch viel höhere Anforderungen an das Kaltluftmanagement. Krass höhere Anforderung an die Bandbreite, weil jeder Schluckauf ein Nadelstich gegen das Produkt. Wenn Netflix mal eine Minute Weg ist, bekommt man das gar nicht mit. Dann der Stromverbraucht der ständig Schwankungen haben wird pro Stadia (Standby-> Connect -> Titelschirm -> im Spiel -> Pause ->Fortsetzen). Das sind Brot und Butter Operationen die ständig passieren und pro Gerät für Schwankungen sorgen, die man auf ein ganzes Computezentrum betrachtet erst einmal abgefangen werden müssen. Sowas hat man nicht, wenn einfach nur ein Exabyte an Daten irgendwo rumschimmelt.

Die Workloads sind ähnlich. Es geht immer auch um Compute, nicht nur um Storage. Moderne Rechenzentren arbeiten deutlich mehr Compute Workloads ab, als einfach nur Daten zu speichern. Dein Hinweis, dass es nur um "Datendichte" geht, stimmt schon lange nicht mehr.

Fragt nicht Google, fragt nicht Hetzner, fragt einen Supercomputerbetreiber, was der so für Probleme hat die ein normaler Datenhoster nicht hat. So ein Datenzentrum zu einem Produkt zu entwickeln, das wirklich einen Massenmarkt erreicht und nicht nur ein Prrof of Concept für 10.000 Leute ist, das ist die Herausforderung.

Ehm... Es ist bereits so, dass GCP - ähnlich wie AWS - von einem Massenmarkt verwendet wird. Und zwar nicht nur zum Daten speichern. Das halbe Internet mit all seinen Applikationen läuft auf AWS. Netflix mit seinen Video Encodern läuft auf AWS. Twitter läuft auf der Google Cloud Platform. Paypal läuft auf GCP. Ebay läuft auf GCP. Um nur mal ein paar Beispiele zu nennen. Und nein, die speichern da nicht einfach nur ihre Daten, der komplette Dienst läuft dort.

 

[PCGH_Torsten]

Ich habe spontan noch das hier in meinen Bookmarks gefunden:
YouTube YouTube
YouTube

Hier findest Du noch mehr:
GDC | Stadia

Vielen Dank für die Links. Sobald ich zwei volle Stunden Zeit übrig habe, um nach Belegen für diffuse Andeutungen zu suchen, werde ich gucken wo sich darin etwas zu Stadias physischen Aufbau findet.

Dir (und einigen anderen hier) fehlt offensichtlich das Verständnis dafür, wie "Cloud" funktioniert. Und wie große, verteilte Compute Systeme funktionieren. Ihr seid mit Euren Gedanken viel zu sehr auf das fixiert, womit Ihr Euch täglich beschäftig: PCs.

Ich persönlich bin auf Low-Latency-Rendering-Systeme für aktuelle Game-Engines fixiert. Das mag durch den alltäglichen Umgang mit PCs, die ein Paradebeispiel dafür darstellen, bedingt sein, erscheint mir bei Fragen nach einem remote-Low-Latency-Rendering-System für aktuelle Game-Engines aber ein guter Ausgangspunkt zu sein. Jedenfalls geeigneter als Vergleiche mit Azure oder AWS, die feingranulare Instanzen und/oder Anwendungen mit hoher Latenztolleranz berechnen.

Dass Stadia ein komplexes Gebilde ist, das auf verteilten Systemen läuft, ergibt sich nicht nur aus dem Video, das Du verlinkt hast, sondern schon alleine daraus, wie Cloud funktioniert. Es ist nicht so, dass es "den" Stadia Server gibt, der dann einfach 10.000 mal repliziert wird. Die Sache ist wesentlich komplexer als das. Wir reden über separate Encoder Maschinen, über mit Kubernetes virtualisierte Applikationen, die on demand gestartet werden, über Loadbalancer, Web Server, Rendering Maschinen (GPU), Proxies, Router, TPU Farmen für KI, Integration in Youtube, und und und. Dazu kommen zusätzliche Dienste wie Crowd Play, Crowd Choice, State Share und Stream Connect. Es ist völlig abwegig anzunehmen, man könne ein solch komplexes System mal eben auf drei Server packen und hinter einer Messebühne verstecken.

Man kann jedes korrekt virtualisierte System auf drei Server packen. Oder auf einen, solange er genug Leistung enthält. Virtualisierung dient dazu die Ausführung von der Hardware zu trennen und eine Skalierung in Richtung "weniger" ist immer leicht. Jedes Java-fähige Feature-Phone kann multiple anforderungslose Systeme parallel laufen lassen. Schwierig ist die Gegenrichtung: Rechenlast einer fordernden Anwendung auf mehrere Systeme zu verteilen, ohne die Anwendung in unabhängige Abschnitte aufzuteilen.

Genau vor diesem Problem steht Stadia: Aktuelle Spiele-Engines können weder KI-Subsysteme ansprechen noch ihre Threads ohne stark abnehmenden Ertrag auf mehr als 4-6, selten auch 8 Kerne verteilen. Sie kriegen bereits große Probleme, wenn sich diese Kerne in einem anderen Die im gleichen Threadripper-Package befinden geschweige denn in einem anderen Server oder gar Rechenzentrum der Cloud. Und die GPU mögen sie bitte direkt ansprechen, in der Annahme eines min. 8-GiB/s-Links zwischen dieser und den gerade verwenden CPU-/-RAM-Controller-Einheiten, was nahezu zwingend die Vereinigung der gesamten Hardware in einem Rechner erforder, schließlich gilt die Transferratenanforderung pro laufender Instanz. Wenn selbige die maximal versprochenen 60 Fps UHD ausspuckt, kommt am Ende übrigens immer noch ein 12-GBit/s-Datenstream heraus der selbst eine Auslagerung des Encoding-Prozesses auf einen anderen Raum geschweige denn ein anderes Rechenzentrum unmöglich und höchstens innerhalb eines Racks ökonomisch macht.

Das weißt Du doch gar nicht. Stadia ist eine komplett neue Plattform. Spiele Engines müssen an Stadia angepasst werden. Spiele müssen komplett neu für Stadia entwickelt oder portiert werden. Es ist doch auch heute schon so - so ganz ohne Stadia - das Multiplayer Games zu großen Teilen in der "Cloud" berechnet werden - auf verteilten Systemen. Apex Legends z.B. läuft komplett in der Google Cloud. Auf verteilten Systemen.

Letzteres wusste ich tatsächlich nicht. Meinem Wissensstand nach rendert Apex Legends mit der definitiv nicht Cloud-tauglichen Source-Engine, verlangt nach einer GTX 970 für gute Performance in FHD und bleibt in UHD selbst mit einer 2080 Ti nicht durchgängig über 60 Fps. Klingt nicht nach einem Stream aus der Cloud. Und das Stadia das breitgefächerte Line-Up von Triple-AAA-Titeln mit komplett neuen Cloud-Engines ausstattet ist mir ebenfalls neu. Distributed Computeing würde statt einer einfachen Linux-Portation mit Schnittstellen- und Controller-Anpassungen ein Remake noch nicht einmal fertiggestellter Spiele mit anderem technischem Unterbau erfordern.

Das habe ich auch gar nicht behauptet. Ich wollte nur aufzeigen, dass es durchaus Bedarf für GPUs in Googles Cloud (und nebenbei, selbstverständlich auch in Azure und AWS) gibt. Dein Einwand, es gäbe kein Bedarf und deshalb müsse man die Existenz in Frage stellen, stimmt einfach nicht. Dass Stadia diese GPUs nicht für das Game Rendering verwendet, ist klar. Daher auch mein Hinweis auf die AMD GPUs.

Ok, da lag ein Missverständnis vor. Meine gewollte Aussage war: Aktuell läuft in Googles Rechenzentren keine [nenneswerte] 3D-Beschleunigung. Um den massiven Bedarf von Stadia zu decken, müssen sie also definitiv neue Systeme aufbauen und können das Ganze nicht "in Software" auf bestehenden Systemen starten. Das unabhängig davon GPGPU-Kapazitäten in der Cloud stecken wollte ich nicht in Frage stellen.

 

[cryptochrome]

Man kann jedes korrekt virtualisierte System auf drei Server packen. Oder auf einen, solange er genug Leistung enthält. Virtualisierung dient dazu die Ausführung von der Hardware zu trennen und eine Skalierung in Richtung "weniger" ist immer leicht. Jedes Java-fähige Feature-Phone kann multiple anforderungslose Systeme parallel laufen lassen. Schwierig ist die Gegenrichtung: Rechenlast einer fordernden Anwendung auf mehrere Systeme zu verteilen, ohne die Anwendung in unabhängige Abschnitte aufzuteilen.

Wir reden komplett aneinander vorbei. Es geht nicht um einzelne Programme oder Prozesse, sondern um verteilte Dienste, die in der Summe Stadia ergeben. Du bist fixiert auf das Rendering und die Berechnung von Game Inhalten, aber Stadia ist viel mehr als das. Es geht um Komponenten wie z.B. die Integration in Youtube (Streamer kann Zuschauer in seine Game Session einladen und dann mit ihm zusammen spielen), es geht um so Dinge wie das Multicam Feature, über das man die Kameraansicht anderer Mitspieler "Picture in Picture" in sein eigenes Bild einblenden kann, es geht um Dinge wie Loadbalancing von Network Traffic, um REST APIs, um DNS Dienste, das Pausieren von Game States, damit man es zu einem späteren Zeitpunkt auf einem anderen Device fortsetzen kann, und vieles mehr. Alles, was notwendig ist, damit Stadia als Gesamtprodukt funktioniert. Und diese Dinge laufen nicht alle auf einer "Stadia Instanz". Das ist, was ich mit verteilt meine. Und warum ich sagte, Google hätte ein halbes RZ auf die Messe schleppen müssen, um das alles abbilden zu können.

Genau vor diesem Problem steht Stadia: Aktuelle Spiele-Engines können weder KI-Subsysteme ansprechen noch ihre Threads ohne stark abnehmenden Ertrag auf mehr als 4-6, selten auch 8 Kerne verteilen.

Wie gesagt, die Engines müssen an Stadia angepasst werden. Sowohl Unity als auch Unreal haben hier bereits erste Schritte unternommen. Erfahrungsgemäß hat es noch nie besonders lange gedauert, bis sich Engines neuen Technologien annehmen. Schau nur mal, wie schnell die Engines Raytracing implementiert haben. Trotzdem wird das nicht alles ab Tag 1 so sein. Google spricht selbst davon, dass es einige Jahre dauern wird, bis das Potenzial von Stadia voll genutzt wird. Deswegen hat man ja auch ein eigenes Studio aus dem Boden gestampft (inkl. eigener Engine, übrigens).

Sie kriegen bereits große Probleme, wenn sich diese Kerne in einem anderen Die im gleichen Threadripper-Package befinden geschweige denn in einem anderen Server oder gar Rechenzentrum der Cloud. Und die GPU mögen sie bitte direkt ansprechen, in der Annahme eines min. 8-GiB/s-Links zwischen dieser und den gerade verwenden CPU-/-RAM-Controller-Einheiten, was nahezu zwingend die Vereinigung der gesamten Hardware in einem Rechner erforder, schließlich gilt die Transferratenanforderung pro laufender Instanz. Wenn selbige die maximal versprochenen 60 Fps UHD ausspuckt, kommt am Ende übrigens immer noch ein 12-GBit/s-Datenstream heraus der selbst eine Auslagerung des Encoding-Prozesses auf einen anderen Raum geschweige denn ein anderes Rechenzentrum unmöglich und höchstens innerhalb eines Racks ökonomisch macht.

Nochmal, es geht gar nicht so sehr um verteiltes Rendering oder verteiltes Rechnen (obwohl das laut Google bei Stadia möglich ist), sondern um verteilte Dienste. Davon abgesehen: 12 gbit in einem RZ sind nichts. Ich arbeite hier täglich mit Cisco Nexus Switchen, die 16 Terrabit pro Chassis verarbeiten und wo Server und andere Komponenten mit 100 gbit pro Interface angebunden werden - neuerdings auf Nexus 9000'er an auch 400 gbit. Da werden dann auch gerne noch Bonds gebaut, um n * 100 gbit zu realisieren. Das sind heutzutage absolute Basics. Bandbreite und Durchsatz sind in Rechenzentren mit Google Ausmaßen sicher das kleinste Problem.

Letzteres wusste ich tatsächlich nicht. Meinem Wissensstand nach rendert Apex Legends mit der definitiv nicht Cloud-tauglichen Source-Engine

Es geht nicht ums Rendering Torsten. Das findet natürlich bei Apex auf dem Client statt. Es geht um all die anderen Dinge, die notwendig sind, um solch ein riesiges Multiplayer Game möglich zu machen. Global. At Scale. Für Millionen von Spielern, die potenziell gleichzeitig spielen. Und das läuft in dem Fall (Apex) auf GCP.

Ein anderes Beispiel, was mir noch einfällt, ist The Division. Da gabs mal ein sehr interessantes Video von Ubisoft zu, fand glaub ich im Rahmen einer GDC statt. Finde es leider nicht mehr. Dort haben sie beschrieben, wie das Spiel in der Cloud läuft - inkl. Berechnung von Explosionen, die bei allen Mitspielern eines Squads gleich aussehen müssen und zum gleichen Zeitpunkt stattfinden müssen. Das sind alles Dinge, die heute schon mit Cloud realisiert werden. Stadia verlagert an der Stelle letztlich nur noch das eigentliche Rendering mit ins RZ. Alles andere gibt es quasi schon und wird in der breiten Masse bereits verwendet.

 

[PCGH_Torsten]

Wir reden komplett aneinander vorbei.

Das ist, denke ich, eine gute Zusammenfassung. Ich, die News und die meisten Kommentatoren beschäftigen sich mit dem bislang ungelösten latenzarmen remote-Rendering zahlreicher leistungsintensiver Spielinstanzen innerhalb heutiger technischer und ökonomischer Rahmen. Du interessierst dich für die Integration alter low-power-Features wie Streaming-Overlays, einfrieren virtueller Maschinen, grundlegenden Social-Media-Funktionen und natürlich Netzwerktechnik, wenn man all diese sekundären Prozessen dezentral laufen lassen möchte. Abgesehen davon, dass Stadia sowohl das neue als auch das alte integriert und für beides ein komfortables Benutzerinterface braucht, also zwei weitestgehend getrennte Themenbereiche.


Danke an dieser Stelle für den Hinweis auf die 400er Links. Ich kannte 40er und 100er, was ohne Kombination eine Limitierung auf drei respektive acht Streams vor der Komprimierung erzwungen hätte. Solange Google sich auf die heute üblichen Dual-CPU-Nodes beschränkt, wären auf Skylake-/Cascade-Lake-Basis aber trotzdem nur unwesentlich mehr Clients möglich, denn mit 9 Grafikkarten @×8 und knapp bemessenen geteilten Speichermedien @×8 im System reichen die Lanes nur noch für einen 128er Uplink. Bei maximaler Qualität geht einem dann bei 10 Clients genauso die Rechen- wie die Transferleistung aus. Sinnvoller wäre es, das Encoding nicht in getrennte Systeme auszulagern, sondern direkt auf den Beschleunigern auszuführen. Das spart reichlich Netzwerkinfrastruktur und dürfte 1-2 Clients mehr pro Node ermöglichen.