Institutional Repository
This document is published in:
Annual Workshop on Network and Systems Support for Games (2012) pp.1-2
DOI: 10.1109/NetGames.2012.6404021
© 2012 IEEE. Personal use of this material is permitted. Permission from
IEEE must be obtained for all other uses, in any current or future media,
including reprinting/republishing
this
material
for
advertising
or
promotional purposes, creating new collective works, for resale or
redistribution to servers or lists, or reuse of any copyrighted component of
this work in other works.
An empirical study of Cloud Gaming
M. Manzano∗ , J. A. Hernández† , M. Urueña† , E. Calle∗
∗ Institute
of Informatics and Applications (IIiA), University of Girona, Spain
of Telematic Engineering, Universidad Carlos III de Madrid, Spain
∗ {mmanzano, eusebi}@eia.udg.edu, † {jahgutie, muruenya}@it.uc3m.es
† Dept.
Abstract—Online gaming connects players from all over the
world together for fun and entertainment, and has been regarded
as one of the most profitable and popular Internet services. Besides, there is a growing trend towards moving local applications
to remote data centers: this is often referred to as the cloud. With
the purpose of studying the impact of Cloud Gaming on the access
network load, in this paper we carry out an empirical network
traffic analysis of two well-known cloud gaming platforms: OnLive and Gaikai. Traffic traces have been collected and analysed
from five different games of both platforms. Cloud gaming has
been observed to be remarkably different from traditional online gaming in terms of network load and traffic characteristics.
Moreover, the traces have revealed similarities between the two
platforms regarding the packet size distribution, and differences
concerning the packet inter-arrival times. However, each platform
shows a similar traffic pattern for most of the games it serves.
Nonetheless, the racing and shooter games considered in this
work demand more bandwidth than other game-genres.
Cloud gaming platforms. OnLive and Gaikai are the two
cloud gaming platforms chosen for this study. Their main
features are:
a) OnLive: According to the official OnLive’s website [1],
for a good Quality of Experience (QoE) the platform requires
a minimum bandwidth connection of 2 Mbps to render content
at 1024 x 576 pixels, recommends 5 Mbps for 1280 x 720, and
is able to output at 1080p with a higher bandwidth connection.
OnLive requires a local installation of its own software client.
b) Gaikai: does not require any local installation since it
runs on any up-to-date web browser. As stated in its website
[2], Gaikai is playable from around 3 Mbps but offers a better
performance at 5 Mbps. This platform is also able to output
content at 1080p, yet with higher network requirements.
These cloud gaming platforms leverage a GPU on a server
to render content. OnLive uses an H.264 encoder chip on
a dedicated device to grab the video output of each GPU
running on their servers. Gaikai uses a CPU to encode H.264.
Both platforms have strong jitter requirements, and are highly
sensitive to packet loss and packet delay [3].
Measurement methodology. Traffic traces of around 100
seconds (wall clock) of playing time have been captured at
the local computer of the gamer. Each traffic trace records
the packet size and inter-arrival times of all captured packets.
Measurements have been carried out from two different access
network scenarios: (a) a wired University connection (100
Mbps Fast Ethernet), referred to as UNIV, with 94.17 Mbps of
downstream, 71.81 Mbps of upstream, 1 ms of jitter and 38.12
ms and 25.28 ms of RTT (Round-Trip Time) to the nearest
OnLive and Gaikai data center respectively; (b) and a wireless
home connection (802.11n + VDSL), referred to as HOME,
with 51.01 Mbps of downstream, 5.34 Mbps of upstream, 2
ms of jitter and 60.08 ms and 25.71 ms of RTT to the nearest
OnLive and Gaikai data center respectively.
Results overview. Fig. 1 shows a scatter plot of average
packet rate versus packet size for each game and platform,
both in the downstream (Fig. 1 (a)) and upstream (Fig. 1 (b))
directions. As observed in Fig. 1 (a), OnLive presents a higher
packet rate (in the range between 600 to 750 packet/sec) than
Gaikai (in the range of 350 to 550 packet/sec). This difference
is especially remarkable when considering the two racing
games (nfs and crazytaxy) and the shooter games (crysis2
and unreal3). It is also worth noting that the 4e game (the
OnLive 2D puzzle game) shows different values with respect
to the other games of OnLive. This might be due to the fact
that the OnLive platform adapts the bit rate and dedicates less
computational resources for a game that does not have high
graphic requirements, as studied in [4].
In the upstream direction (Fig. 1 (b)), packet rates range
between 35–65 packets/sec for OnLive and between 10–
40 packet/sec for Gaikai. It can be observed that OnLive
does not only have a higher packet rate, but also a higher
packet size. This means that OnLive requires a higher network
performance than Gaikai.
Server → Client. The measurements regarding the serveroriginated traffic (downstream) are analysed next. Fig. 2
depicts the packet size CDF for all games and platforms.
According to Fig. 1 (a), it can be observed that in general,
average packet size is smaller for Gaikai. However, in both
cases a bimodal distribution is observed: OnLive has the low
mode at about 250 bytes and the large mode around 1400
bytes while Gaikai shows its two modes at 150 and 1480 bytes
respectively. The packet size related with the large mode for
both platforms may be caused due to the MTU (Maximum
Transmission Unit) of the two considered access network
scenarios (i.e. Ethernet-based). The difference between both
platforms relies on the fact of which mode is the largest. For
Gaikai the largest mode is the one related with small packets
(150 bytes), whereas for OnLive the largest mode is for large
packets (1400 bytes). Obviously, this fact makes a difference
in the average packet size observed in Fig. 1.
Concerning inter-arrival times of both cloud gaming platforms, as observed in Fig. 3, in OnLive about 40% of packets
show inter-arrival times within microseconds (µs), which
are then uniformly distributed up to 5 ms. Moreover, it is
interesting to note that Gaikai shows three modes: 20% of
1
1100
1
OnLive−Uni
OnLive−Home
Gaikai−Uni
Gaikai−Home
1000
crazytaxy
unreal3
0.7
0.6
nfs
crysis2
4elements
700
fifa2012
nfs
CDF
Packet size (bytes)
0.8
pes2012
800
600
airconflicts
airconflicts
pes2012
900
0.9
crazytaxy
unreal3
4elements
Onlive−PES2012
Onlive−Unreal3
Onlive−Crazytaxy
Onlive−AirConflicts
Onlive−4elements
Gaikai−FIFA2012
Gaikai−Crysis2
Gaikai−NFS
Gaikai−Combatwings
Gaikai−CrazyMachines2
0.4
fifa2012
crysis2
crazymachines2
combatwings
combatwings
0.5
0.3
crazymachines2
0.2
500
0.1
400
300
0
350
400
450
500
550
Packets/sec
600
650
700
750
(a) Server → Client
Fig. 3.
0
1
2
3
4
5
6
Inter−arrival time (ms)
7
8
9
10
Server → Client: CDF of packet inter-arrival times (ms).
180
pes2012
pes2012
crazytaxy
1
airconflicts unreal3 airconflicts
4elements
160
0.9
crazytaxy
unreal3
4elements
0.8
140
0.6
CDF
Packet size (bytes)
0.7
120
crysis2
nfs
0.5
Onlive−PES2012
Onlive−Unreal3
Onlive−Crazytaxy
Onlive−AirConflicts
Onlive−4elements
Gaikai−FIFA2012
Gaikai−Crysis2
Gaikai−NFS
Gaikai−Combatwings
Gaikai−CrazyMachines2
0.4
crysis2
100
combatwings
crazymachines2
0.3
combatwings
crazymachines2
fifa2012
80
fifa2012
60
0
10
20
30
40
50
Packets/sec
0.2
OnLive−Uni
OnLive−Home
Gaikai−Uni
Gaikai−Home
nfs
60
70
80
90
0.1
0
0
50
100
100
150
200
250
Packet size (bytes)
300
350
400
(a) CDF of packet size (bytes)
(b) Client → Server
1
Fig. 1. Packets/sec vs average packet size for the downstream (a) and the
upstream (b) directions.
0.9
0.8
0.7
1
0.6
CDF
0.9
CDF
0.8
0.5
Onlive−PES2012
Onlive−Unreal3
Onlive−Crazytaxy
Onlive−AirConflicts
Onlive−4elements
Gaikai−FIFA2012
Gaikai−Crysis2
Gaikai−NFS
Gaikai−Combatwings
Gaikai−CrazyMachines2
0.4
0.7
0.3
0.6
0.2
0.1
0.5
0
0.4
Onlive−PES2012
Onlive−Unreal3
Onlive−Crazytaxy
Onlive−AirConflicts
Onlive−4elements
Gaikai−FIFA2012
Gaikai−Crysis2
Gaikai−NFS
Gaikai−Combatwings
Gaikai−CrazyMachines2
0.3
0.2
0.1
0
0
Fig. 2.
200
400
600
800
1000
Packet size (bytes)
1200
1400
1600
Server → Client: CDF of packet size (bytes).
packets arrive within few µs, 50% around 1 ms, and the
remaining 30% near 4 ms.
Client → Server. We have performed the same analysis
for the client-originated traffic (upstream). Fig. 4 (a) presents
the packet size CDF. Gaikai shows modes between 50 to 100
bytes, whereas OnLive shows modes in 100 bytes, 140 bytes
and 240 bytes approximately. To conclude, Fig. 4 (b) shows the
inter-departure times CDF. In this case, Gaikai shows a mode
below 1 ms and then uniformly distributed inter-departure
times up to 12 ms. On the contrary, OnLive shows uniformly
distributed inter-departure times from 0 to 8 ms and then a
mode at around 9 ms.
Future work. It could be interesting to further investigate
cloud gaming-generated traffic with the purpose of having a
0
2
4
6
8
Inter−arrival time (ms)
10
12
14
(b) CDF of packet inter-departure times (ms)
Fig. 4. Client → Server: CDF of packet size (a) and CDF of packet interdeparture times (b).
better understanding of the underlying protocols used by the
two platforms. Moreover, network conditions could be altered
(i.e. adding delay) in order to evaluate its consequences on the
Quality of Experience perceived by gamers.
Acknowledgment. This work is partly supported by the
projects TRION (TEC 2009-10724), FIERRO (TEC 201012250-E) and Medianet (S-2009/TIC-1468); and by the Generalitat de Catalunya through the research support program
project SGR-1202 and AGAUR FI-DGR 2012 grant.
R EFERENCES
[1] Onlive, http://www.onlive.com, [Online; accessed 25-July-2012].
[2] Gaikai, http://www.gaikai.com, [Online; accessed 25-July-2012].
[3] M. S. Borella, “Source models of network game traffic,” Computer
Communications, vol. 23, no. 4, pp. 403–410, 2000.
[4] K.-T. Chen, Y.-C. Chang, P.-H. Tseng, C.-Y. Huang, and C.-L. Lei,
“Measuring the latency of cloud gaming systems,” in Proceedings of ACM
Multimedia 2011, Nov 2011.
2