Patch Scheduling for On-line Games Chris Chambers Wu-chang Feng Portland State University

2 Outline Background Data Sources Problem statement Model Evaluation

3 Background On-line games popular  World of Warcraft: > 4 million subscribers On-line updates to games are expected  Bug fixes  New content  Performance improvements  Anti-cheating modules Updates can be very large  WoW beta: 4GB download, 1GB updates When a patch is released, players download at next play session

4 Background: On-line gamers Population has a daily/weekly cycle Average daily variation between minimum and maximum: 50%

5 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?

6 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

7 Steam: players and servers

8 Steam: content servers

9 Data source 2: Mshmro.com Popular counter-strike server Our trace is one year of player data  Joins, leaves  Kills, deaths  Chat

10 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

11 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?

12 Example patch

13 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

14 Players fall into three categories Continuing Unpatched Returning Initially entire population is unpatched

15 Model Definitions  P t = 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) = P t – C P t-1 - ret(t) P t

16 Evaluation

17 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

18 Predicted vs. observed load

19 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!

20 Predicted vs. observed (more shorter sessions)

21 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

22 Cumulative bandwidth per hour of release

23 Conclusions Modeling game updates is an interesting problem Game updates are initially modeled given:  Aggregate player behavior  Play characteristics: session times and interarrival times Results  Minimize peak bw: release at player valley  Minimize cumulative bw: release 5 hours after peak Model is relatively inaccurate  More work  Better data

24 Predicted peak load Peak load predicted at moment of release  Unless patches take long to download Model minimizes peak load at 22 nd hour

25 Constant scaling ineffective S = Steam bandwidth P = Number of players k = Constant scaling factor (bandwidth / player) S – kP = patch impact?

26 Constant scaling ineffective

27 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

28 Hourly scaling

29 Steam – scaled player data

30 Minimized cumulative load per hour of release