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

2. 2 Outline Background Data Sources Problem statement Model Evaluation

3. 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. 4 Background: On-line gamers Population has a daily/weekly cycle Average daily variation between minimum and maximum: 50%

5. 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. 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. 7 Steam: players and servers

8. 8 Steam: content servers

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

10. 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. 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. 12 Example patch

13. 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. 14 Players fall into three categories Continuing Unpatched Returning Initially entire population is unpatched

15. 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. 16 Evaluation

17. 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. 18 Predicted vs. observed load

19. 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. 20 Predicted vs. observed (more shorter sessions)

21. 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. 22 Cumulative bandwidth per hour of release

23. 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. 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. 25 Constant scaling ineffective S = Steam bandwidth P = Number of players k = Constant scaling factor (bandwidth / player) S – kP = patch impact?

26. 26 Constant scaling ineffective

27. 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. 28 Hourly scaling

29. 29 Steam – scaled player data

30. 30 Minimized cumulative load per hour of release