{"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 possibilit\u00e0 dei servizi per giocare su PC poco potenti\u00bb<\/a><\/noindex>. In esso analizzavo i pro e i contro di diversi servizi per giochi in cloud su PC poco potenti. Durante il gioco ho testato ogni servizio e alla fine ho condiviso le mie impressioni generali.<\/p>\n

Nei commenti a quell'articolo e ad altri simili, i lettori spesso condividevano le loro impressioni su diversi servizi di gioco. Non di rado si trovavano opinioni opposte sullo stesso servizio. Per alcuni tutto \u00e8 perfetto, mentre altri non possono giocare a causa di lag e freeze. Allora mi \u00e8 venuta l'idea di valutare la qualit\u00e0 del funzionamento di questi servizi in diverse condizioni \u2014 da quelle ideali a quelle terribili. Si parla della qualit\u00e0 delle reti, poich\u00e9 non sempre l'utente pu\u00f2 vantare una connessione veloce e senza problemi, giusto? In generale, qui sotto troverete una valutazione dei servizi con simulazione di diverse qualit\u00e0 della rete.
\n<\/a><\/noindex><\/p>\n

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

\nCome gi\u00e0 detto, riguarda la qualit\u00e0 della connessione. E pi\u00f9 precisamente, la perdita di pacchetti durante il gioco. Maggiore \u00e8 la perdita, maggiori sono i problemi per il gamer, minore \u00e8 la soddisfazione nel gioco. \u00c8 raro infatti trovare qualcuno con una connessione perfetta come quella in fibra ottica fino al dispositivo, e con internet dedicato, non condiviso con tutti gli abitanti di un condominio.<\/p>\n

Per riferimento, a una velocit\u00e0 di connessione di 25 Mbps, per inviare 1 frame\/ fotogramma servono 40-50 pacchetti di dati. Maggiore \u00e8 la perdita di pacchetti, meno qualitativa diventa l'immagine e pi\u00f9 evidenti sono i lag e i freeze. In casi particolarmente gravi, giocare diventa semplicemente impossibile.<\/p>\n

Naturalmente, il servizio cloud stesso non pu\u00f2 influenzare la larghezza e la stabilit\u00e0 della connessione dell'utente (anche se sarebbe fantastico, ovviamente). Ma si possono prevedere vari modi per mitigare i problemi di connessione. Quali servizi si comportano meglio riguardo a questo problema \u2014 lo scopriremo pi\u00f9 avanti.<\/p>\n

Cosa stiamo confrontando?<\/h3>\n

\nUn PC normale (Intel i3-8100, GTX 1060 6 GB, 8GB 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, esaminiamo la qualit\u00e0 del gioco in \u00abThe Witcher\u00bb. Google Stadia, al momento della scrittura di questo articolo, non aveva questo gioco, quindi \u00e8 stato necessario testare un altro \u2014 \u00abOdyssey\u00bb. <\/p>\n

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

\nStiamo testando da Mosca. Fornitore \u2014 MGTs, piano 500 Mbit\/s, connessione via cavo, non WiFi. Prendiamo le impostazioni di qualit\u00e0 grafica nei servizi per impostazione predefinita, risoluzione \u2014 FullHD. <\/p>\n

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

Perdite singole uniformi. <\/b>Questo \u00e8 quando si perde solo 1 pacchetto e le perdite sono distribuite in modo pi\u00f9 o meno uniforme. Quindi, una perdita uniforme del 10% significa che su 100 pacchetti, ogni 10\u00b0 si perde, ma sempre solo 1 pacchetto. Il problema di solito si manifesta con distorsioni (schermatura) nel canale dal client al server. <\/p>\n

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

Perdite di massa non uniformi<\/b>, quando in un certo momento si perdono immediatamente 40-70 pacchetti consecutivamente. Queste perdite si verificano pi\u00f9 frequentemente a causa di problemi con l\u2019hardware di rete (router, ecc.) dell'utente o del fornitore. Possono essere legate al sovraccarico del buffer dell'hardware di rete sulla linea di comunicazione \"utente \u2014 server\". Anche il WiFi con pareti spesse pu\u00f2 causare tali perdite. Il sovraccarico della rete wireless a causa di un gran numero di dispositivi \u00e8 un\u2019altra causa che si riscontra frequentemente negli uffici e nei condomini.<\/p>\n

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

Di seguito analizzer\u00f2 tutti questi casi e allegher\u00f2 un confronto video per una maggiore chiarezza. Alla fine dell'articolo fornisco un link ai video grezzi e non montati del gameplay da tutti i servizi e casi \u2014 l\u00ec \u00e8 possibile esaminare in dettaglio gli artefatti, nonch\u00e9 le informazioni tecniche (in tutti i servizi, tranne Stadia, sono registrati i dati della console tecnica; per Stadia non ne ho trovati). <\/p>\n

Andiamo!<\/h3>\n

\nDi seguito \u2014 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 necessario). Alla fine del post \u2014 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. Nessuna perdita nella rete<\/h4>\n

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

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

In ogni scenario abbiamo preso frame dal gioco su PC come riferimento. \u00c8 chiaro che la qualit\u00e0 della rete non influisce su di esso, il gioco si avvia localmente su PC. La presenza di questi frame risponde alla domanda \"si percepisce la differenza giocando nel cloud rispetto a giocare sul proprio PC\". In condizioni ideali, nel nostro caso \u2014 non si percepisce per la maggior parte dei servizi. Di seguito non parleremo pi\u00f9 di PC, basta ricordare che esiste.<\/p>\n

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

Tutto bene, l'immagine \u00e8 nitida, il processo procede senza intoppi, senza freeze. <\/p>\n

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

Ecco che Vortex rovina il nostro mondo ideale. Ha subito avuto problemi: l'immagine \u00e8 peggiore rispetto a tutte le altre, inoltre si notano bene i \"lag\". Il possibile problema \u00e8 che i server di gioco si trovano lontano da Mosca e l'hardware sui server di gioco sembra pi\u00f9 debole e gestisce male il FullHD. In tutti i test Vortex ha mostrato prestazioni deludenti. Se qualcuno ha un'esperienza positiva di gioco con Vortex \u2014 scrivete nei commenti, condividete da dove avete giocato e come \u00e8 andata.<\/p>\n

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

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

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

Il servizio mostra un'immagine eccellente, non ci sono problemi visibili.<\/p>\n

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

Il servizio di gioco di Google funziona perfettamente nonostante non abbia server in RF, e in effetti Stadia non \u00e8 ufficialmente disponibile in Russia. Tuttavia, tutto va bene. \u00c8 un peccato che \"The Witcher\" non fosse disponibile su Stadia al momento del gioco, ma che ci posso fare, abbiamo preso \"Odyssey\" \u2014 anch'essa esigente, e parla di un uomo che taglia persone e animali. <\/p>\n

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

\nIn questo test circa ogni 20 pacchetti viene perso. Ricordo che per il rendering di un frame sono necessari 40-50 pacchetti.<\/p>\n

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

Il servizio di Nvidia va bene, non ci sono 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 diventata ancora peggiore. Perch\u00e9 \u2014 non \u00e8 del tutto chiaro, molto probabilmente non \u00e8 prevista ridondanza o \u00e8 minima. La ridondanza \u00e8 la codifica resistente agli errori dei dati trasmessi (FEC \u2014 Forward Error Correction). Questa tecnologia ripristina i dati parzialmente persi a causa di problemi di rete. Implementarla e configurarla pu\u00f2 essere fatto in modi diversi, e a giudicare dai risultati, i creatori di Vortex non sono riusciti in questo. Anche con perdite uniformi minime, non \u00e8 possibile giocare. Nei successivi test Vortex \u00e8 semplicemente \"morto\".<\/p>\n

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

Tutto va bene, non c'\u00e8 molta differenza rispetto alle condizioni ideali. Forse \u00e8 utile che i server dell'azienda siano situati anche a Mosca, da dove sono stati effettuati i test. E forse la ridondanza menzionata sopra \u00e8 meglio configurata. <\/p>\n

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

Il servizio \u00e8 diventato drasticamente non giocabile, nonostante le relativamente basse perdite di pacchetti. Qual \u00e8 il problema? Presumo che Loudplay utilizzi il protocollo TCP. In questo caso, finch\u00e9 non c'\u00e8 conferma di ricezione del pacchetto, altri pacchetti non vengono inviati, il sistema aspetta la conferma di consegna. Pertanto, se un pacchetto si \u00e8 perso, non ci sar\u00e0 conferma della sua consegna, nuovi pacchetti non verranno inviati, l'immagine si bloccher\u00e0, fine della storia. <\/p>\n

Ma se si utilizza UDP, non sar\u00e0 necessaria alcuna conferma di ricezione del pacchetto. A quanto pare, tutti gli altri servizi, tranne Loudplay, utilizzano il protocollo UDP. Se non \u00e8 cos\u00ec, correggetemi nei commenti, per favore.<\/p>\n

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

\u00c8 giocabile. A volte l'immagine \u00e8 pixelata, ci sono minime latenze di risposta. Forse la codifica per la resistenza ai disturbi non funziona perfettamente, da qui alcuni artefatti non significativi in un flusso complessivamente giocabile.<\/p>\n

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

\nPerdiamo ogni 10\u00b0 pacchetto su cento. Questa \u00e8 gi\u00e0 una sfida per i servizi. Per gestire efficacemente tali perdite, sono necessari tecnologi per il recupero e\/o la ritrasmissione dei dati persi.<\/p>\n

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

Con Geforce ci sono alcune piccole flessioni nella qualit\u00e0 del flusso video. A quanto pare, GFN reagisce ai problemi di rete cercando di ridurli. Il servizio diminuisce il bit rate, cio\u00e8 il numero di bit per la trasmissione dei dati. In questo modo cerca di ridurre il carico su una rete considerata non sufficientemente di qualit\u00e0 e mantenere una connessione stabile. E sulla stabilit\u00e0 non ci sono davvero domande, ma la qualit\u00e0 del video ne risente in modo significativo. Vediamo una notevole pixelazione dell'immagine. E poich\u00e9 la simulazione prevede una continua perdita del 10% dei pacchetti, la diminuzione del bit rate non aiuta molto, la situazione non torna alla normalit\u00e0. <\/p>\n

Nella vita reale, l'immagine sar\u00e0 probabilmente instabile e variabile. Aumentando le perdite, l'immagine si annebbi; riducendo le perdite, l'immagine torna alla normalit\u00e0 e cos\u00ec via. Questo non giova affatto all'esperienza di gioco. <\/p>\n

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

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

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

Non funziona, non \u00e8 semplicemente partito. Nel corso di ulteriori test, la situazione si \u00e8 ripetuta. Da quanto si pu\u00f2 dedurre, questo servizio non si adatta in alcun modo ai problemi di rete. Potrebbe essere colpa del protocollo TCP. Anche le minime perdite paralizzano completamente il servizio. Non \u00e8 molto pratico per la vita reale, ovviamente.<\/p>\n

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

Ci sono anche grossi problemi. Non si pu\u00f2 giocare in queste condizioni, anche se l'immagine \u00e8 ancora presente e il personaggio continua a correre, ma in modo discontinuo. Penso che sia tutto legato alla stessa mancanza di ridondanza o alla sua cattiva implementazione. I pacchetti si perdono frequentemente e non vengono recuperati. Di conseguenza, la qualit\u00e0 dell'immagine degrada a livelli ingiocabili.<\/p>\n

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

Sfortunatamente, qui la situazione \u00e8 critica. Si osservano interruzioni del flusso, per cui gli eventi sullo schermo si verificano a scatti, giocare \u00e8 estremamente difficile. Si pu\u00f2 ipotizzare che il problema sia sorto, come nel caso di Vortex, a causa della minima ridondanza o della sua assenza. Ho consultato un paio di persone che sono 'del settore' e hanno affermato che Stadia aspetta probabilmente la completa compilazione del fotogramma. A differenza di GFN, non cerca di rimediare abbassando drasticamente il bitrate. Di conseguenza, non ci sono artefatti, ma si verificano freeze e lag (al contrario di GFN, che presenta meno freeze\/lag, ma a causa del basso bitrate l'immagine risulta poco attraente). <\/p>\n

Anche gli altri servizi non sembrano aspettare la completa compilazione del fotogramma, sostituendo la parte mancante con un frammento di un vecchio fotogramma. Questa \u00e8 una buona soluzione, nella maggior parte dei casi l'utente non nota il tranello (si cambiano 30+ fotogrammi al secondo), anche se a volte possono comparire artefatti.<\/p>\n

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

\nSi perde ogni quarto pacchetto. La situazione diventa sempre pi\u00f9 preoccupante. In effetti, con una connessione cos\u00ec 'difettosa', \u00e8 difficilmente possibile giocare normalmente nel cloud. Anche se alcuni partecipanti al confronto si destreggiano, anche se non in modo perfetto. <\/p>\n

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

I problemi sono gi\u00e0 abbastanza evidenti. L'immagine \u00e8 pixelata e sfocata. Si pu\u00f2 ancora giocare, ma non \u00e8 pi\u00f9 quello che GFN offriva all'inizio. E non \u00e8 affatto il modo giusto di giocare a giochi belli. La bellezza non pu\u00f2 pi\u00f9 essere apprezzata. <\/p>\n

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

Il gameplay va abbastanza bene. La fluidit\u00e0 c'\u00e8, anche se l'immagine ne risente un po'. A proposito, in alto a sinistra ci sono i numeri che indicano quanti pacchetti persi vengono ripristinati. Come vediamo, il 96% dei pacchetti viene ripristinato.<\/p>\n

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

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

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

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

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

Il servizio \u00e8 praticamente ingiocabile. Le ragioni sono gi\u00e0 state descritte sopra. Aspetta il montaggio del fotogramma, l'eccesso \u00e8 minimo, con tali perdite non \u00e8 sufficiente. <\/p>\n

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

\nSu 10.000 pacchetti, 1 volta si perdono 40-70 pacchetti consecutivamente. Quindi perdiamo circa 1 fotogramma ogni 200. A volte succede che il buffer del dispositivo di rete \u00e8 pieno e tutti i nuovi pacchetti vengono semplicemente scartati (dropped) finch\u00e9 il buffer non si libera. Tutti i partecipanti al confronto, tranne Loudplay, hanno gestito queste perdite in un modo o nell'altro. <\/p>\n

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

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

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

Tutto molto bene. L'immagine \u00e8 fluida, 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 anche corso. Ma la connessione con il server \u00e8 stata presto persa. Ah, questo protocollo TCP. La prima perdita ha bloccato il servizio sul nascere. <\/p>\n

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

Si notano i problemi abituali. Freeze, lag e tutto il resto. Giocare sarebbe davvero molto difficile in tali condizioni.<\/p>\n

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

Giocabile. Si notano piccole flessioni, l'immagine a volte si pixelizza.<\/p>\n

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

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

Dico subito che problemi evidenti sono emersi nella maggior parte dei servizi. Ad esempio, l'immagine si blocca, quindi l'eccesso qui non aiuta pi\u00f9. C'\u00e8 un effetto positivo nell'uso della tecnologia di eccesso, ma \u00e8 ridotto.<\/p>\n

Il fatto \u00e8 che il tempo di reazione 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, mancano dati) e scatti nell'immagine.<\/p>\n

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

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

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

Gestisce meglio \u2014 probabilmente perch\u00e9 \u00e8 impostata correttamente la ridondanza, inoltre l'algoritmo del bitrate considera le perdite non molto elevate e non trasforma l'immagine in una zuppa pixelata.<\/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. Gli scatti e le cadute sono molto evidenti. Giocare in queste condizioni \u00e8 probabilmente impossibile.<\/p>\n

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

Gli scatti sono ben evidenti, \u00e8 un chiaro indicatore che la ridondanza non \u00e8 sufficiente. L'immagine si ferma, poi appaiono altri fotogrammi, si verifica un'interruzione del flusso video. Giocare, in linea di principio, \u00e8 possibile, se si ha una grande voglia e una tendenza clinica all'autoinflizione.<\/p>\n

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

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

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

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

Giocare \u00e8 gi\u00e0 molto difficile, se non del tutto possibile \u2014 il bitrate \u00e8 notevolmente abbassato. Si perdono fotogrammi, invece di un'immagine normale vediamo 'sfocato'. I fotogrammi non si ripristinano \u2014 manca l'informazione per il recupero. Se GFN prevede un recupero, la modalit\u00e0 con cui il servizio cerca di salvare la situazione con il bitrate solleva dubbi sulla sua capacit\u00e0 di gestire la ridondanza. <\/p>\n

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

C'\u00e8 una distorsione nel fotogramma, l'immagine salta, cio\u00e8 si ripetono elementi di fotogrammi singoli. Si vede che gran parte del 'fotogramma danneggiato' \u00e8 stata ripristinata da pezzi di quello precedente. Cio\u00e8 nei nuovi fotogrammi ci sono parti di fotogrammi vecchi. Ma l'immagine \u00e8 relativamente chiara. Si pu\u00f2 gestire, ma in scene dinamiche, ad esempio, in una rissa, dove \u00e8 necessaria una buona reazione \u2014 \u00e8 difficile.<\/p>\n

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

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

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

\u00c8 partito, ma sarebbe meglio non fosse mai partito \u2014 giocare a questo \u00e8 impossibile.<\/p>\n

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

Il servizio in queste condizioni \u00e8 ingiocabile. Le ragioni sono la necessit\u00e0 di attendere la costruzione del fotogramma e la scarsa ridondanza. <\/p>\n

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

\nIl punteggio \u00e8, ovviamente, soggettivo. Nei commenti si pu\u00f2 discutere. E il primo posto, naturalmente, spetta al PC locale. Questo 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 senza concorrenza. Ma se per qualche motivo non lo avete, allora consultate la classifica.<\/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 che il fattore principale nel cloud gaming in termini di resilienza ai problemi di rete \u00e8:<\/p>\n