{"id":75970,"date":"2020-03-30T01:42:37","date_gmt":"2020-03-29T23:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/oblachnye-igry-stress-test-5-oblachnyh-igrovyh-servisov-plohim-internetom"},"modified":"2020-03-30T01:42:37","modified_gmt":"2020-03-29T23:42:37","slug":"oblachnye-igry-stress-test-5-oblachnyh-igrovyh-servisov-plohim-internetom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/oblachnye-igry-stress-test-5-oblachnyh-igrovyh-servisov-plohim-internetom","title":{"rendered":"Giochi in cloud: stress test di 5 servizi di gioco in cloud con una connessione internet scadente","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Giochi
\n
\nCirca un anno fa ho pubblicato un articolo \u00abGiochi in cloud: valutazione delle opportunit\u00e0 dei servizi per giocare su PC poco potenti tramite esperienze dirette\u00bb<\/a><\/noindex>. In esso sono stati analizzati i pro e i contro di diversi servizi per il cloud gaming su PC poco potenti. Durante il gioco ho testato ogni servizio e alla fine ho condiviso un'impressione generale.<\/p>\n

Nei commenti a quell'articolo e ad altri simili, i lettori spesso condividevano le loro esperienze su vari servizi di gioco. Spesso si trovavano opinioni opposte sullo stesso servizio. Per alcuni tutto funzionava alla perfezione, mentre altri non riuscivano a giocare a causa di lag e freeze. Da qui \u00e8 nata l'idea di valutare la qualit\u00e0 di questi servizi in diverse condizioni, dalle migliori alle peggiori. Si parla della qualit\u00e0 delle reti, perch\u00e9 non sempre l'utente pu\u00f2 vantare una connessione veloce e affidabile, giusto? In sintesi, di seguito troverete una valutazione dei servizi simulando diverse qualit\u00e0 di rete.
\n<\/a><\/noindex><\/p>\n

Qual \u00e8 il problema?<\/h3>\n

\nCome accennato in precedenza, si tratta della connessione. Pi\u00f9 precisamente, della perdita di pacchetti durante il gioco. Maggiore \u00e8 la perdita, pi\u00f9 problemi ha il giocatore e minore \u00e8 la sua soddisfazione con il gioco. E pochi hanno un perfetto canale di connessione come la fibra ottica fino al dispositivo, specialmente con una connessione dedicata e non condivisa con tutti gli abitanti di un condominio.<\/p>\n

Per riferimento, a una velocit\u00e0 di connessione di 25 Mbps, per trasmettere un singolo frame deve essere inviato un totale di 40-50 pacchetti di dati. Maggiore \u00e8 la perdita di pacchetti, pi\u00f9 scadente diventa la qualit\u00e0 dell'immagine, e pi\u00f9 evidenti diventano lag e freeze. In casi particolarmente gravi, diventa semplicemente impossibile giocare.<\/p>\n

Naturalmente, il servizio cloud non pu\u00f2 influire sulla larghezza e stabilit\u00e0 del canale dell'utente (anche se sarebbe fantastico). Tuttavia, \u00e8 possibile prevedere diversi modi per mitigare i problemi di connettivit\u00e0. Quali servizi affrontano meglio il problema lo scopriremo qui di seguito.<\/p>\n

Cosa stiamo confrontando precisamente?<\/h3>\n

\nUn normale PC (Intel i3-8100, GTX 1060 6 GB, 8 GB di RAM), GeForce Now (la sua versione russa GFN<\/a><\/noindex> con server a Mosca), Loudplay<\/a><\/noindex>, Vortex<\/a><\/noindex>, Playkey<\/a><\/noindex>, Stadia<\/a><\/noindex>. Su tutti i servizi, tranne Stadia, analizziamo la qualit\u00e0 del gioco in \u2018The Witcher\u2019. Su Google Stadia, al momento della scrittura di questo articolo, questo gioco non era disponibile, quindi abbiamo dovuto testare un altro gioco: \u2018Odyssey\u2019. <\/p>\n

Quali sono le condizioni e la metodologia di testing?<\/h3>\n

\nTestiamo da Mosca. Fornitore: MGTS, piano da 500 Mbit\/s, connessione cablata, non WiFi. Le impostazioni della qualit\u00e0 grafica sui servizi vengono prese come predefinite, risoluzione: FullHD. <\/p>\n

Utilizzando il programma Clumsy<\/a><\/noindex> simuliamo problemi di rete, in particolare, perdite di pacchetti di vari tipi e dimensioni. <\/p>\n

Perdite singole uniformi. <\/b>Questo \u00e8 quando si perde solo 1 pacchetto e le perdite sono distribuite abbastanza uniformemente. Pertanto, perdite uniformi del 10% significano che su 100 pacchetti ciascun 10\u00b0 viene perso, ma sempre solo 1 pacchetto. Il problema di solito si manifesta in caso di distorsioni (schermature) sul canale dal client al server. <\/p>\n

Testiamo perdite uniformi del 5%, 10%, 25%.<\/p>\n

Perdite di massa disomogenee<\/b>, quando, in un certo momento, si perdono immediatamente 40-70 pacchetti di seguito. Queste perdite si verificano pi\u00f9 spesso a causa di problemi con l'hardware di rete (router, ecc.) dell'utente o del provider. Possono essere collegati a un sovraccarico della memoria buffer dell'hardware di rete nella connessione \"utente - server\". Il WiFi con pareti spesse pu\u00f2 anche causare tali perdite. Il sovraccarico della rete wireless dovuto alla presenza di un gran numero di dispositivi \u00e8 un'altra causa, molto comune negli uffici e nei condomini.<\/p>\n

Testiamo perdite irregolari dello 0,01%, 0,1%, 0,5%.<\/p>\n

Di seguito analizzo tutti questi casi e aggiungo un confronto video per chiarezza. Alla fine dell'articolo fornisco un link ai video grezzi, non montati, del gameplay di tutti i servizi e casi - l\u00ec \u00e8 possibile esaminare pi\u00f9 dettagliatamente gli artefatti, cos\u00ec come le informazioni tecniche (in tutti i servizi, tranne Stadia, sono stati registrati i dati della console tecnica; per Stadia non ne ho trovati). <\/p>\n

Andiamo!<\/h3>\n

\nDi seguito sono riportati 7 scenari di stress test e video con timestamp (il video \u00e8 lo stesso, per comodit\u00e0 in ogni punto la visione inizia dal momento giusto). Alla fine del post ci sono i video originali per ciascuno dei servizi. Un buon amico mi ha aiutato a realizzare il video, grazie a lui!<\/p>\n

Scenario n. 1. Condizioni ideali. Perdite di rete pari a zero<\/h4>\n

\nTutto, come dovrebbe essere in un mondo perfetto. Non ci sono problemi di connessione, nessun'interruzione, nessuna interferenza, il tuo hotspot \u00e8 il faro di internet. In queste condizioni ottimali, quasi tutti i partecipanti al test si comportano in modo degno.<\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nPC<\/b><\/p>\n

In ogni scenario abbiamo utilizzato frame di gioco su PC come riferimento. \u00c8 chiaro che la qualit\u00e0 della rete non influisce su di esso, il gioco viene eseguito localmente sul PC. La presenza di questi frame risponde alla domanda \"si sente la differenza quando si gioca nel cloud rispetto a giocare sul proprio PC\". In condizioni ideali, nel nostro caso, la maggior parte dei servizi non mostra differenze. Non scriveremo altro sul PC, basta ricordare che esiste.<\/p>\n

GeForce Now<\/b><\/p>\n

Va tutto bene, l'immagine \u00e8 nitida, il processo \u00e8 fluido, senza lag. <\/p>\n

Vortex<\/b><\/p>\n

Vortex rovina il nostro mondo ideale. Ha immediatamente cominciato a mostrare problemi: la qualit\u00e0 dell'immagine \u00e8 inferiore rispetto a tutte le altre, e i \"lag\" sono ben evidenti. Un possibile problema \u00e8 che i server di gioco si trovano lontano da Mosca, e l'hardware su questi server sembra pi\u00f9 debole, il che compromette il FullHD. In tutti i test, Vortex ha mostrato prestazioni scadenti. Se qualcuno ha avuto un'esperienza positiva di gioco con Vortex, vi prego di scrivere nei commenti, condividete da dove giocavate e quanto sia andata bene.<\/p>\n

Playkey<\/b><\/p>\n

Tutto ottimo, proprio come su un PC locale. Non ci sono problemi visibili come freeze, lag, ecc.<\/p>\n

Loudplay<\/b><\/p>\n

Il servizio offre un'ottima qualit\u00e0 video, senza problemi visibili.<\/p>\n

Stadia<\/b><\/p>\n

Il servizio di gioco di Google funziona perfettamente, nonostante non abbia server in RF e Stadia non operi ufficialmente in Russia. Tuttavia, va tutto bene. \u00c8 un peccato che \"The Witcher\" non fosse disponibile su Stadia al momento del gioco, ma che ci possiamo fare, abbiamo preso \"Odyssey\", anche essa abbastanza esigente, riguardante un uomo che affronta persone e animali. <\/p>\n

Scenario n. 2. Perdite uniformi del 5%<\/h4>\n

\nIn questo test, si perde circa un pacchetto ogni 20, su 100 pacchetti. Ricordo che per renderizzare un fotogramma sono necessari 40-50 pacchetti.<\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nGeForce Now<\/b><\/p>\n

Il servizio di Nvidia funziona bene, senza problemi. L'immagine \u00e8 leggermente pi\u00f9 sfocata rispetto a Playkey, ma \"The Witcher\" \u00e8 ancora giocabile.<\/p>\n

Vortex<\/b><\/p>\n

Qui la situazione \u00e8 ulteriormente peggiorata. Perch\u00e9 non \u00e8 del tutto chiaro, probabilmente non \u00e8 prevista ridondanza o \u00e8 minima. La ridondanza \u00e8 la codifica a prova di errore dei dati trasmessi (FEC - Forward Error Correction). Questa tecnologia recupera i dati in caso di perdita parziale a causa di problemi di rete. Pu\u00f2 essere implementata e configurata in diversi modi e, a giudicare dai risultati, i creatori di Vortex non ci sono riusciti. Anche con perdite uniformi minime, non si pu\u00f2 giocare. Durante i test successivi, Vortex \u00e8 semplicemente \"morto\".<\/p>\n

Playkey<\/b><\/p>\n

Tutto funziona bene, non c'\u00e8 una differenza significativa rispetto alle condizioni ideali. Potrebbe aiutare il fatto che i server dell'azienda siano situati anche a Mosca, da dove sono stati effettuati i test. Inoltre, forse la suddetta ridondanza \u00e8 meglio configurata. <\/p>\n

Loudplay<\/b><\/p>\n

Il servizio \u00e8 diventato improvvisamente ingiocabile, nonostante le perdite di pacchetti relativamente contenute. Quale potrebbe essere il problema? Presumo che Loudplay utilizzi il protocollo TCP. In questo caso, finch\u00e9 non viene ricevuta la conferma di ricezione di un pacchetto, gli altri pacchetti non vengono inviati; il sistema attende la conferma di consegna. Pertanto, se un pacchetto si perde, non ci sar\u00e0 alcuna conferma della sua consegna, nuovi pacchetti non verranno inviati e l'immagine si blocc\u00e0, fine della storia. <\/p>\n

Se invece si utilizza UDP, non sar\u00e0 necessaria alcuna conferma di ricezione del pacchetto. Da quanto si pu\u00f2 dedurre, tutti gli altri servizi, a parte Loudplay, utilizzano il protocollo UDP. Se non \u00e8 cos\u00ec, per favore correggetemi nei commenti.<\/p>\n

Stadia<\/b><\/p>\n

\u00c8 tutto giocabile. A volte l'immagine si pixelizza, ci sono minime latenze di risposta. Potrebbe non funzionare perfettamente la codifica resistente alle interferenze, da qui i lievi artefatti in un flusso complessivamente giocabile.<\/p>\n

Scenario n. 3. Perdite uniformi del 10%<\/h4>\n

\nPerdiamo ogni 10\u00b0 pacchetto su cento. Questo rappresenta gi\u00e0 una sfida per i servizi. Per gestire efficacemente tali perdite, sono necessari tecnici esperti nel recupero e\/o nella ritrasmissione dei dati persi.<\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nGeForce Now<\/b><\/p>\n

Su Geforce si osservano lievi cali nella qualit\u00e0 del flusso video. Da quanto si pu\u00f2 capire, GFN reagisce ai problemi di rete cercando di ridurli. Il servizio abbassa il bitrate, ovvero la quantit\u00e0 di bit per la trasmissione dei dati. In questo modo cerca di ridurre il carico su una rete ritenuta non sufficientemente di qualit\u00e0 e mantenere una connessione stabile. E sulla stabilit\u00e0 non ci sono realmente dubbi, ma la qualit\u00e0 video ne risente notevolmente. Si osserva una significativa pixelizzazione dell'immagine. Inoltre, poich\u00e9 la simulazione prevede una perdita costante del 10% di pacchetti, la diminuzione del bitrate non aiuta molto, e la situazione non migliora. <\/p>\n

Nella vita reale, l'immagine sar\u00e0 probabilmente non costantemente scadente, ma altalenante. Le perdite aumentano \u2014 l'immagine si sfoca; le perdite diminuiscono \u2014 l'immagine torna alla normalit\u00e0 e cos\u00ec via. Questo, ovviamente, non giova all'esperienza di gioco. <\/p>\n

Playkey<\/b><\/p>\n

Non ci sono problemi particolari. Probabilmente, l'algoritmo rileva i problemi di rete, determina il livello delle perdite e punta di pi\u00f9 sulla ridondanza piuttosto che sulla riduzione del bitrate. Cos\u00ec, con una perdita uniforme del 10%, la qualit\u00e0 dell'immagine non cambia praticamente, l'utente difficilmente noter\u00e0 tali perdite.<\/p>\n

Loudplay<\/b><\/p>\n

Non funziona, non si \u00e8 avviato affatto. Durante ulteriori test, la situazione si \u00e8 ripetuta. Da quanto si pu\u00f2 giudicare, questo servizio non si adatta ai problemi di rete. Potrebbe essere colpa del protocollo TCP. Anche le minime perdite paralizzano completamente il servizio. Certo, non \u00e8 molto pratico per la vita reale.<\/p>\n

Vortex<\/b><\/p>\n

Ci sono anche grossi problemi. Non si pu\u00f2 giocare in queste condizioni, anche se l'immagine c'\u00e8 e il personaggio continua a correre, ma a scatti. Penso che la questione sia sempre la stessa: una ridondanza mal implementata o assente. I pacchetti vengono persi frequentemente e non vengono recuperati in alcun modo. Alla fine, la qualit\u00e0 dell'immagine degrada a un livello ingiocabile.<\/p>\n

Stadia<\/b><\/p>\n

Purtroppo, qui la situazione \u00e8 pessima. Si verifica un'interruzione del flusso, a causa della quale gli eventi sullo schermo si verificano con scatti rendendo il gioco estremamente difficile. Si potrebbe ipotizzare che il problema sia sorto, come nel caso di Vortex, a causa di una minima ridondanza o della sua assenza. Ho consultato un paio di amici che sono 'nel settore' e hanno dichiarato che Stadia probabilmente aspetta il completamento del frame. A differenza di GFN, non cerca di rimediare abbassando drasticamente il bitrate. Alla fine, non ci sono artefatti, ma si verificano freeze e lag (mentre in GFN ci sono meno freeze\/lag, ma a causa del basso bitrate l'immagine risulta poco attraente). <\/p>\n

Anche gli altri servizi, a quanto pare, non aspettano il completamento del frame, sostituendo la parte mancante con un frammento di un vecchio frame. Questa \u00e8 una buona soluzione, nella maggior parte dei casi l'utente non noter\u00e0 alcun inganno (cambiando oltre 30 frame al secondo), anche se a volte possono verificarsi artefatti.<\/p>\n

Scenario n. 4. Perdite uniformi del 25%<\/h4>\n

\nSi perde ogni quarto pacchetto. La situazione diventa sempre pi\u00f9 preoccupante. Con una connessione cos\u00ec \u201cprotocollo\u201d, \u00e8 difficile immaginare di giocare normalmente nel cloud. Anche se alcuni partecipanti alla comparazione ne vengono a capo, non in modo perfetto. <\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\n GFN<\/b><\/p>\n

I problemi sono gi\u00e0 molto evidenti. L'immagine \u00e8 pixelata e sfocata. Si pu\u00f2 ancora giocare, ma non \u00e8 affatto ci\u00f2 che GFN offriva all'inizio. E sicuramente non \u00e8 il modo giusto di giocare a giochi di bellezza. Non si pu\u00f2 pi\u00f9 apprezzare la bellezza. <\/p>\n

Playkey<\/b><\/p>\n

Il gameplay procede abbastanza bene. C'\u00e8 fluidit\u00e0, anche se l'immagine ne risente un po'. A proposito, in alto a sinistra ci sono i numeri che mostrano quanti pacchetti persi vengono recuperati. Come possiamo vedere, il 96% dei pacchetti viene recuperato.<\/p>\n

Loudplay<\/b><\/p>\n

Non si \u00e8 avviato.<\/p>\n

Vortex<\/b><\/p>\n

Non si pu\u00f2 giocare nemmeno con una grande voglia, i freeze (interruzione dell'immagine, ripresa del flusso video da un nuovo frammento) sono ancora pi\u00f9 evidenti. <\/p>\n

Stadia<\/b><\/p>\n

Il servizio \u00e8 praticamente inutilizzabile. Le ragioni sono state gi\u00e0 menzionate sopra. Aspetta l'assemblaggio del fotogramma, l'eccesso \u00e8 minimo; con tali perdite, non \u00e8 sufficiente. <\/p>\n

Scenario n. 5. Perdite irregolari 0,01%.<\/h4>\n

\nSu 10.000 pacchetti, 1 volta si perdono 40-70 pacchetti consecutivi. Significa che perdiamo circa 1 fotogramma su 200. Questo accade se il buffer del dispositivo di rete \u00e8 pieno e tutti i nuovi pacchetti vengono semplicemente scartati (dropped) fino a quando il buffer non si libera. Tutti gli partecipanti al confronto, tranne Loudplay, hanno gestito tali perdite in un modo o nell'altro. <\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nGFN<\/b><\/p>\n

L'immagine ha perso leggermente qualit\u00e0, \u00e8 diventata un po' sfocata, ma \u00e8 comunque giocabile.<\/p>\n

Playkey<\/b><\/p>\n

Tutto va molto bene. L'immagine \u00e8 fluida e la qualit\u00e0 \u00e8 buona. Si pu\u00f2 giocare senza problemi.<\/p>\n

Loudplay<\/b><\/p>\n

Nei primi secondi l'immagine era presente, il personaggio ha persino corso. Ma la connessione con il server \u00e8 stata persa quasi subito. Oh, quel protocollo TCP. La prima perdita ha bloccato il servizio all'istante. <\/p>\n

Vortex<\/b><\/p>\n

Si manifestano problemi comuni. Freeze, lag e tutto il resto. Giocare sarebbe molto difficile in tali condizioni.<\/p>\n

Stadia<\/b><\/p>\n

Giocabile. Si notano lievi cali, ogni tanto l'immagine si pixelizza.<\/p>\n

Scenario n. 6. Perdite irregolari 0,1%<\/h4>\n

\nSu 10.000 pacchetti, 10 volte si perdono 40-70 pacchetti consecutivi. Risultato: perdiamo 10 fotogrammi su 200.<\/p>\n

Vorrei subito dire che i problemi evidenti sono emersi nella maggior parte dei servizi. Ad esempio, l'immagine presenta dei salti, quindi la ridondanza non \u00e8 di aiuto. Questo significa che c'\u00e8 un effetto positivo nell'uso di tecnologie di ridondanza, ma \u00e8 limitato.<\/p>\n

Il fatto \u00e8 che il tempo di risposta alle azioni dell'utente e del gioco stesso \u00e8 limitato; il flusso video deve essere continuo. Ripristinare il flusso a una qualit\u00e0 accettabile \u00e8 impossibile, nonostante gli sforzi dei servizi. <\/p>\n

Compaiono artefatti (tentativo di compensare la perdita di pacchetti, i dati sono insufficienti) e ci sono salti nell'immagine.<\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nGFN<\/b><\/p>\n

La qualit\u00e0 dell'immagine \u00e8 diminuita notevolmente, con il bitrate chiaramente ridotto, e ci\u00f2 in modo significativo.<\/p>\n

Playkey<\/b><\/p>\n

Si comporta meglio \u2013 probabilmente perch\u00e9 la ridondanza \u00e8 ben configurata, inoltre l'algoritmo del bitrate considera le perdite non molto elevate e non trasforma l'immagine in una zuppa pixelizzata.<\/p>\n

Loudplay<\/b><\/p>\n

Non si \u00e8 avviato.<\/p>\n

Vortex<\/b><\/p>\n

\u00c8 partito, ma con una qualit\u00e0 dell'immagine terribile. Sono molto evidenti i salti e le cadute. Giocare in tali condizioni \u00e8 quasi impossibile.<\/p>\n

Stadia<\/b><\/p>\n

Le interruzioni sono ben visibili, un chiaro segnale che manca la ridondanza. L'immagine si interrompe, poi appaiono altri fotogrammi, ci sono interruzioni nel flusso video. \u00c8 possibile giocare, se si ha veramente voglia e una certa inclinazione al masochismo.<\/p>\n

Scenario n. 7. Perdite irregolari del 0,5%.<\/h4>\n

\nSu 10.000 pacchetti, si perdono consecutivamente 40-70 pacchetti per 50 volte. Perdiamo 50 fotogrammi su 200.<\/p>\n

Situazione da \u201cdisastro totale\u201d. Il tuo router fa scintille, il provider ha un guasto, i cavi sono stati rosicchiati dai topi, ma vuoi comunque giocare in cloud. Quale servizio dovresti scegliere? <\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nGFN<\/b><\/p>\n

Giocare \u00e8 gi\u00e0 molto difficile, se non impossibile: il bitrate \u00e8 notevolmente ridotto. I fotogrammi vanno persi, invece di un'immagine normale vediamo solo \u00absfocato\u00bb. I fotogrammi non vengono recuperati: non c'\u00e8 abbastanza informazione per il ripristino. Se GFN prevede un recupero, la maniera aggressiva con cui il servizio cerca di salvare la situazione tramite il bitrate solleva dubbi sulla sua capacit\u00e0 di gestire la ridondanza. <\/p>\n

Playkey<\/b><\/p>\n

C'\u00e8 una distorsione dell'immagine, l'immagine tremola, cio\u00e8 ci sono ripetizioni di elementi di fotogrammi singoli. \u00c8 evidente che gran parte del 'fotogramma danneggiato' \u00e8 stata ripristinata da pezzi precedenti. Quindi, nei nuovi fotogrammi ci sono parti di fotogrammi vecchi. Ma l'immagine \u00e8 comunque abbastanza nitida. \u00c8 possibile controllare, ma in scene dinamiche, ad esempio in una lotta, dove \u00e8 necessaria una buona reattivit\u00e0, \u00e8 difficile.<\/p>\n

Loudplay<\/b><\/p>\n

Non si \u00e8 avviato.<\/p>\n

Vortex<\/b><\/p>\n

\u00c8 partito, ma sarebbe stato meglio non partire \u2014 non \u00e8 giocabile.<\/p>\n

Stadia<\/b><\/p>\n

Il servizio in queste condizioni non \u00e8 giocabile. Le ragioni sono l'obbligo di attendere la costruzione del fotogramma e la scarsa ridondanza. <\/p>\n

Chi \u00e8 il vincitore?<\/h3>\n

\nIl rating, ovviamente, \u00e8 soggettivo. Nei commenti si pu\u00f2 discutere. E il primo posto, naturalmente, va al PC locale. Proprio perch\u00e9 i servizi cloud sono estremamente sensibili alla qualit\u00e0 della rete, e questa qualit\u00e0 \u00e8 piuttosto instabile nel mondo reale, il proprio PC da gioco rimane insuperabile. Ma se per qualche motivo non lo si possiede, consultate il rating.<\/p>\n

    \n
  1. PC locale. Prevedibile.<\/li>\n
  2. Playkey<\/li>\n
  3. GeForce Now<\/li>\n
  4. Google Stadia<\/li>\n
  5. Vortex<\/li>\n
  6. Loudplay<\/li>\n<\/ol>\n

    \nCome conclusione, ricordo ancora una volta che gioca un ruolo principale nel gaming in cloud per quanto riguarda la resilienza ai problemi di rete:<\/p>\n