• Leider ist es in letzter Zeit wiederholt vorgekommen, dass Newsartikel von anderen Seiten als Ganzes im Forum gepostet wurden. Weil dies in dieser Form gegen das Urheberrecht verstößt und uns als Seite rechtliche Probleme beschert, werden wir von nun an verstärkt dagegen vorgehen und die entsprechend Benutzer verwarnen. Bitte verzichtet fortan auf das Kopieren von ganzen Newsartikeln und meldet diese über die Report-Funktion, falls euch ein entsprechender Artikel auffallen sollte. Vielen Dank!

Stadia Stadia - Die Gaming-Plattform von Google

Eine ziemlich schwache Argumentationsbasis hast du da, meinst du nicht auch?
Während meine wunderbar mit den beobachteten Ergebnissen in Übereinklang ist. Mhmmm.

Es entspricht aber der Praxis.
Ich selbst arbeite mit AWS und IBM zusammen, bei denen ist das de facto so. Von Kollegen weiß ich das es MS bei der Azure Cloud ebenfalls so gehandhabt wird.

Bei google habe ich keine connections, es lassen sich aber nirgendwo dedizierte und verbindliche stats zu deren host Systemen finden was mich bestätigt das die das ebenfalls so handhaben.
 
Es entspricht aber der Praxis.
Ich selbst arbeite mit AWS und IBM zusammen, bei denen ist das de facto so. Von Kollegen weiß ich das es MS bei der Azure Cloud ebenfalls so gehandhabt wird.

Bei google habe ich keine connections, es lassen sich aber nirgendwo dedizierte und verbindliche stats zu deren host Systemen finden was mich bestätigt das die das ebenfalls so handhaben.
Ich habe dir vorhin die Specs von deren Dev-Seite aufgelistet. Wir haben hier Testergebnisse vorliegen, die dazu passen.
Was hast du? Nix, außer 'Connections'.

Das ist doch keine Argumentationsbasis.
 
Ich habe dir vorhin die Specs von deren Dev-Seite aufgelistet. Wir haben hier Testergebnisse vorliegen, die dazu passen.
Was hast du? Nix, außer 'Connections'.

Das ist doch keine Argumentationsbasis.

Glaubst mir oder glaubst mir nicht, ist mir scheiss egal.

Das ein virtueller Client in einer cloud Umgebung über keine "festen" speccs verfügt sondern skaluerbar sind, sollte eigentlich grundsätzlich klar sein.
Das ich überhaupt mit dir darüber diskutiere war schon ein Entgegenkommen von mir an dich.
 
Glaubst mir oder glaubst mir nicht, ist mir scheiss egal.

Das ein virtueller Client in einer cloud Umgebung über keine "festen" speccs verfügt sondern skaluerbar sind, sollte eigentlich grundsätzlich klar sein.
Das ich überhaupt mit dir darüber diskutiere war schon ein Entgegenkommen von mir an dich.
Auch ein virtueller Client muss auf echter Hardware laufen. :nix: Da kannst du dich winden wie du willst. Und bei Stadia ist diese echte Hardware wie von Google selber angegeben eine Vega56. Und wie das auf Linux mit AMDs-Linux-Treibern skaliert, sieht man an den Testergebnissen wunderbar.
 
Du windest dich mit so kruder Argumenten wie das jeder virtueller Client auch auf physikalischer HW laufen muss. Natürlich muss er das!

Aber ...

1) ändert das absolut nix an der Tatsache das ein virtueller client/Instanz keine festen Speccs hat.

2) du NICHT weißt wie diese physikalische HW aussieht

In der Stellenbeschreibung steht übrigens auch immer noch nichts von VEGA sondern custom AMD gpu. Kann sicherlich auf der vega Architektur basieren aber konkret steht da nix.
Mit jedem deiner posts wird mehr offensichtlich das du keinerlei Sachverstand und Ahnung hast wie so ein Cloud Data Center und Cloud Computing funktioniert.

Was die Tests momentan zeigennist lediglich, das die Stadia Instanzen nicht entsprechend skalieren. Warum die das tun und warum man sich auf dieses Projekt debekal einlässt kann nur google beantworten.
 
Eine virtuelle Instanz(Konsole) wie Stadia hat keine fixen stats und auch nicht fest eine vega GPU verbaut.
In der Theorie verliert man durch die Virtualisierung Leistung. Wird vermutlich bei übermäßige vielen Gleitkommaberechnungen womöglich sogar noch schlimmer.

Und wie schon mehrmals gesagt: Was in einem Blade ist, sagt nicht mal was aus für eine Instanz. Ein Blade kann auch "4 Sockets" haben. Nur kann man so ein Blade dann nicht einer Instanz zuweisen, sondern maximal nur 1 Socket von diesem Blade. Das heißt: Eine Instanz kann nicht von mehreren Sockets profitieren, da kann das Blade so potent wie möglich sein.

Letztendlich könnte also ein Blade sogar 4 GPUs haben, bringt aber für eine einzige Instanz nichts. Die Spezifikationen, die Google genannt hat, sind womöglich das Maximum für eine Instanz. Warum sollte man sonst diese nennen?
 
In der Theorie verliert man durch die Virtualisierung Leistung. Wird vermutlich bei übermäßige vielen Gleitkommaberechnungen womöglich sogar noch schlimmer.

Und wie schon mehrmals gesagt: Was in einem Blade ist, sagt nicht mal was aus für eine Instanz. Ein Blade kann auch "4 Sockets" haben. Nur kann man so ein Blade dann nicht einer Instanz zuweisen, sondern maximal nur 1 Socket von diesem Blade. Das heißt: Eine Instanz kann nicht von mehreren Sockets profitieren, da kann das Blade so potent wie möglich sein.

Letztendlich könnte also ein Blade sogar 4 GPUs haben, bringt aber für eine einzige Instanz nichts. Die Spezifikationen, die Google genannt hat, sind womöglich das Maximum für eine Instanz. Warum sollte man sonst diese nennen?

Ersteres ist eine Vermutung von dir weil auch du nicht weißt wie google seine blades bestückt und letzteres ist falsch da wir bei AWS Instanzen haben wo wir über autoscaling mehr oder andere GPUs pro Instanz und Bedarf zugeordnet bekommen.

Des Weiteren könnte es auch andere Möglichkeiten geben, das besonders resourcenhungrige Anwendungen wie zB RDR2 auf einer speziellen Stadia Instanz laufen die über eine andere gpu verfügt.

Ist aber auch alles völlig wayne und nicht unser Problem.
Wen google mit Stadia 4k/60fps für jedes Spiel verspricht dann ist es deren Problem wie sie das umsetzen. So einfach ist das.

:nix:
 
Ah, mangels Fakten und begründeten Argumente geht es wie so oft bei cw wieder in den Bereich der persönlichen Beleidigungen. Über meine Erfahrung und Sachverstand würdest du dich vermutlich wundern, tut hier aber nichts zur Sache.
1) ändert das absolut nix an der Tatsache das ein virtueller client/Instanz keine festen Speccs hat.
Das stimmt so nicht. Für Spieleentwicklung wäre so eine Tatsache extrem schlecht. Weshalb ja Google auf seinen Seiten auch Specs angibt.
2) du NICHT weißt wie diese physikalische HW aussieht
Klar weiss ich das. Gibt Google ja an. Eine AMD-Vega-GPU mit 56 compute units und 10.7 Teraflops.
 
Ersteres ist eine Vermutung von dir weil auch du nicht weißt wie google seine blades bestückt und letzteres ist falsch da wir bei AWS Instanzen haben wo wir über autoscaling mehr oder andere GPUs pro Instanz und Bedarf zugeordnet bekommen.

1. Du hast bei Virtualisierung Performance-Verlust. Das ist nicht änderbar. Wie es bei GPU-Berechnungen ist, weiß ich nicht. Wird aber wohl schlimmer sein, da diese ja am Schwersten sind. Klar, für die meisten Anwendungen im Virtualisierungsumfeld ist das nicht allzu schlimm, aber für Spiele wird das womöglich schon ein "deutlicherer Verlust".
2. Nein, das ist falsch. Amazon tituliert einen Thread übrigens als "eine CPU" (heißt, wenn du eine CPU von Amazon "mietest", ist das physikalisch nur ein Thread, also streng genommen die Hälfte eines CPU-Kerns). Ist das jetzt also richtig, weil Amazons Marketing das sagt? Eine Instanz kann keine Hardware von mehreren Sockets haben. Bei AWS kriegt man womöglich einfach nur "mehr Hardware" von der selben Instanz. Normalerweise gibt man auch nie die 100%-Leistung eines Sockets. Gibt sicherlich auch Blades, die pro Socket mehrere GPUs akzeptieren (SLI). Das ist aber was anderes als "1 Socket".
 
Die ersten Berichte sind ziemlich ernüchternd aber eben genau so wie man erwarten konnte. Derzeit verpuffen förmlich alle Stadia Argumente. Die jenigen mit ordentlichen Latenzen müssen sich mit durchschnittlicher Bildqualität, Artefakten und gelegentlich Lags rumschlagen. Das kann man einfach nicht schönreden.
 
1. Du hast bei Virtualisierung Performance-Verlust. Das ist nicht änderbar. Wie es bei GPU-Berechnungen ist, weiß ich nicht. Wird aber wohl schlimmer sein, da diese ja am Schwersten sind. Klar, für die meisten Anwendungen im Virtualisierungsumfeld ist das nicht allzu schlimm, aber für Spiele wird das womöglich schon ein "deutlicherer Verlust".
2. Nein, das ist falsch. Amazon tituliert einen Thread übrigens als "eine CPU" (heißt, wenn du eine CPU von Amazon "mietest", ist das physikalisch nur ein Thread, also streng genommen die Hälfte eines CPU-Kerns). Ist das jetzt also richtig, weil Amazons Marketing das sagt? Eine Instanz kann keine Hardware von mehreren Sockets haben. Bei AWS kriegt man womöglich einfach nur "mehr Hardware" von der selben Instanz. Normalerweise gibt man auch nie die 100%-Leistung eines Sockets. Gibt sicherlich auch Blades, die pro Socket mehrere GPUs akzeptieren (SLI). Das ist aber was anderes als "1 Socket".

Kannst du mir sagen was dich qualifiziert das als falsch zu bewerten wohingegen mir von AWS consultans nicht nur was anderes gesagt wird sondern was ich an unseren Instanzen live sehe.

Und natürlich ist eine vCPU nur ein thread des hypervisors und entspricht nicht einer physikalischen CPU des host. Was willst du mir mit deinem ständigen Virtualisierung Einmaleins erzählen?

Wie die GPUs virtualisieren und paralisieren ist sicher nicht über Desktop sli Lösungen sondern über eigens geschaffene Lösungen, custom halt.

Und natürlich läuft da alles über raw Power bei cloud Computing.
Weißt du wie die mitigation für einen DoS angriff bei AWS aussieht? Wen man die Attacke nicht anders abwehren kann werden einfach so lange neue Instanzen generiert bis die Attacke ins Leere läuft. Man hat einfach die Power jedes Bot Netzwerk dieser Welt zu outscalen

:nix:
 
Und natürlich ist eine vCPU nur ein thread des hypervisors und entspricht nicht einer physikalischen CPU des host.
Nein, das ist falsch. Allgemeingültig ist 1 vCPU = 1 CPU-Kern des Hosts. Amazon macht aber 1 vCPU = 0,5 CPU-Kerne des Hosts. Heißt, für Amazon hat ein Host mit 16 Kernen stolze 32 vCPUs, was aber "gefaked" ist. Klassisches Kleingedruckte. Man spart Geld und die Instanz sieht natürlich eine vollwertige CPU, obwohl nur ein halber Kern.

Also nichts mit "und natürlich". Du glaubst schlichtweg Amazons Marketing.
 
Nein, das ist falsch. Allgemeingültig ist 1 vCPU = 1 CPU-Kern des Hosts. Amazon macht aber 1 vCPU = 0,5 CPU-Kerne des Hosts. Heißt, für Amazon hat ein Host mit 16 Kernen stolze 32 vCPUs, was aber "gefaked" ist. Klassisches Kleingedruckte. Man spart Geld und die Instanz sieht natürlich eine vollwertige CPU, obwohl nur ein halber Kern.

Also nichts mit "und natürlich". Du glaubst schlichtweg Amazons Marketing.

Was du da von dir gibst ist völlig falsch
 
Maximal genauso falsch wie deine Aussage, dass eine "vCPU natürlich ein Thread ist".
 
Ich finde die Überschriften lesen sich vernichtend, nicht alle, aber viele. Und darauf schaut der Massenmarkt-Kunde.

Wie gesagt, eine Beta wäre die wesentlich bessere Option gewesen. In 5-6 Jahren mag die Internetlandschaft anders aussehen, heute ist die Zeit für so ein Produkt noch nicht reif. Mobile und on the go erst recht nicht bei den heute üblichen Datenvolumina. Und als Ersatz der Konsolen offensichtlich auch noch nicht. Als Ergänzung? Vielleicht. Stand heute aber launcht Google Stadia offiziell, dann müssen sie sich daran eben auch messen lassen, denn sie selbst sagen, dass 35 Mbit/s reichen würde für Stadia Pro.
Ein streamingdienst statt zweitkonsole ist aber definitiv überlegungswert. Next gen zum beispiel PS5 main + 1 monate Gamepass mit Xcloud. Brauche nur 10-20 euro mehr ausgeben statt zweimal 399 - 499 :nix:
 
Zurück
Top Bottom