1 / 30

Patch Scheduling for On-line Games

This study explores the impact of patch releases on bandwidth in on-line games and proposes a model to optimize the scheduling of patches. The model takes into account player behavior and aims to minimize both peak and cumulative bandwidth.

psterling
Download Presentation

Patch Scheduling for On-line Games

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Returning Unpatched Continuing Initially entire population is unpatched

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

  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. Peak load predicted at moment of release Unless patches take long to download Model minimizes peak load at 22nd hour Predicted peak load

  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

More Related