Patch Scheduling for On-line
Games
Chris Chambers
Wu-chang Feng
Portland State University
Outline





Background
Data Sources
Problem statement
Model
Evaluation
2
Background

On-line games popular


On-line updates to games are expected





Bug fixes
New content
Performance improvements
Anti-cheating modules
Updates can be very large


World of Warcraft: > 4 million subscribers
WoW beta: 4GB download, 1GB updates
When a patch is released, players download at next
play session
3
Background: On-line gamers


Population has a
daily/weekly
cycle
Average daily
variation
between
minimum and
maximum: 50%
4
Background: Patching

Two main factors determine bandwidth
impact of a patch:



Size of patch
Number of downloads
Lesser factor:




Time of release
Release at peak player load: maximized peak
load
Release at trough: minimized peak load?
As players join in increasing numbers, what
happens?
5
Data Source 1: Steam



Content-delivery network for a number
of FPS games
Also performs authentication
Our trace is almost 1 year of Steam
data polled every 10 minutes


Aggregate Bandwidth
Number of players
6
Steam: players and servers
7
Steam: content servers
8
Data source 2: Mshmro.com


Popular counter-strike server
Our trace is one year of player data



Joins, leaves
Kills, deaths
Chat
9
Player session data

Distribution of player sessions:


19.35% of all players have session times
<= 10 minutes
Distribution of time between sessions


50% of players seen every 48 hours
90% of players seen every 18 days
10
Problem Statement


How can we model the release of a
patch?
As we vary the time of day of the patch
release, what happens to the
bandwidth?
11
Example patch
12
Model

Players fall into three categories





New
Continuing to play
Returning
Continuing players: those with session
times > 10 minutes
Returning players: those whose
interarrival times are up
13
Players fall into three
categories
Returning
Unpatched
Continuing
Initially entire population is unpatched
14
Model

Definitions





Pt = players at time t
C = percent of players with sessions > 10
minutes
ret(t) = percentage of returning players at time t
New(t) = players needing the patch at time t
Model
New(t) = Pt – C Pt-1 - ret(t) Pt
15
Evaluation
16
Evaluation

Observed patch


Subtract player bandwidth from Steam
bandwidth
Predicted patch


Using the model with the same time of
day as the observed
Scale starting point to the observed
starting point
17
Predicted vs. observed load
18
Evaluation


Model does not match observed very closely
Model predicts a very steep drop-off in players


If 80% of players have sessions > 10 minutes, drop-off is
expected
Two reasons for poor match


Inaccurate session times
Server updates not modeled



There are lots of these
They may be weighted towards first day
We alter one parameter


Suppose only 10% of sessions > 10 minutes
Modeling servers: future work!
19
Predicted vs. observed (more
shorter sessions)
20
Applying the model


Experiment with varying hours of release
What’s good, what’s bad at different hours?



Cumulative bandwidth equal
Peak bandwidth varies with the initial population
Look at minimizing cumulative bandwidth along
the way
21
Cumulative bandwidth per
hour of release
22
Conclusions


Modeling game updates is an interesting problem
Game updates are initially modeled given:



Results



Aggregate player behavior
Play characteristics: session times and interarrival times
Minimize peak bw: release at player valley
Minimize cumulative bw: release 5 hours after peak
Model is relatively inaccurate


More work
Better data
23
Predicted peak load

Peak load
predicted at
moment of release


Unless patches
take long to
download
Model minimizes
peak load at 22nd
hour
24
Constant scaling ineffective




S = Steam bandwidth
P = Number of players
k = Constant scaling factor (bandwidth /
player)
S – kP = patch impact?
25
Constant scaling ineffective
26
Constant scaling ineffective


Difference between the two should be
a flat line
Why not?




Server population
Daily maintenance
Reporting lag
Solution: make a different scaling
constant for each hour
27
Hourly scaling
28
Steam – scaled player data
29
Minimized cumulative load per
hour of release
30