1 / 32

Performance Analysis of the OnLive Thin Client Game System

Performance Analysis of the OnLive Thin Client Game System . Mark Claypool, David Finkel , Alexander Grant and Michael Solano In  Proceedings of the 11th ACM Network and System Support for Games ( NetGames ), Venice, Italy, November 22-23, 2012

yana
Télécharger la présentation

Performance Analysis of the OnLive Thin Client Game System

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. Performance Analysis of the OnLive Thin Client Game System Mark Claypool, David Finkel, Alexander Grant and Michael Solano In Proceedings of the 11th ACM Network and System Support for Games (NetGames), Venice, Italy, November 22-23, 2012 Springer's Multimedia Systems Journal (MMSJ), special issue on Network and Systems Support for Games, submitted March 31, 2013

  2. What is OnLive and Why is it Important? • Gaming in the cloud • Thin client, no special hardware requirements • OnLive: PC, Mac, mini-console • Game video streamed to client • “Games as video” • Importance: • Allows playing AAA games on simple devices • Provide access to legacy games on next-gen consoles without hardware compatibility

  3. Goal of Our Study • How does the magic of OnLive work? • Study network traffic turbulence of games on OnLive • Packet size • Inter-packet time • Overall bitrate up and down • Controlled variation of network parameters • Different genres of games • Compare to traditional games, traditional video

  4. Motivation • Network operators and end users for planning for capacity   • Building traffic models for simulators • Traffic classification to identify thin-client game flows, up and downstream • Can allow for treatments that help performance

  5. Outline • Introduction (done) • Methodology (next) • Results • Conclusions

  6. Methodology • Select games • Setup testbed • Gather data • Analyze results

  7. Select Games • Available on OnLive (about 200) • Similar release data (suggests similar graphics)

  8. Unreal Tournament III (2007)First-person shooter

  9. Batman: Arkham Asylum (2009)Third-person action-adventure

  10. Grand Ages: Rome (2009)Real-time strategy, omnipresent

  11. Experimental Set-Up

  12. Design of Experiments • All traffic measured UDP • Varied capacity, loss and latency • Parameters: • Game genre: UT, Batman, and Rome. • Streaming: Game, Real-time video (Skype), Pre-recorded video (YouTube) • Capacity (downstream:upstream): 1 to 10 Mb/s and no restriction • Latency (round-trip): 0 milliseconds to 1000 milliseconds • Loss (downstream): 0% to 18% loss • Iterations: 2½ minute runs, 3 runs for each experiment condition, ex ceptwhere noted • Performance: • Network: packet sizes (bytes), inter packet times (msec), bitrates (Kb/s Mb/s) • Application: frame rates (f/s)

  13. Outline • Introduction (done) • Methodology (done) • Results (next) • OnLive Turbulence • TCP-Friendly • Frame rate • Comparison with other apps • Conclusions

  14. Downstream Bitrateunrestricted

  15. Upstream Bitrateunrestricted

  16. Downstream Packet Sizeunrestricted

  17. Downstream BitrateCapacity restriction

  18. Outline • Introduction (done) • Methodology (done) • Results (done) • OnLive Turbulence (done) • TCP-Friendly (next) • Frame rate • Comparison with other apps • Conclusions

  19. TCP-Friendly? • Use no more network capacity than would a conformant TCP flow under the same network conditions • Same loss, same latency (same packet size) • Run with: 0-20% loss, 0-1000 msec latency [16]

  20. TCP-(Un)Friendly

  21. Outline • Introduction (done) • Methodology (done) • Results (done) • OnLive Turbulence (done) • TCP-Friendly (done) • Frame rate (next) • Comparison with other apps • Conclusions

  22. Frame Rate

  23. Frame Rate

  24. Performance PredictionFrame Rate [9]

  25. Performance PredictionCapacity

  26. Outline • Introduction (done) • Methodology (done) • Results (done) • OnLive Turbulence (done) • TCP-Friendly (done) • Frame rate (done) • Comparison with other apps (next) • Conclusions

  27. Streaming Application Comparisonunrestricted

  28. Traditional Game Comparison

  29. Summary Comparison

  30. Conclusions • OnLive games have high downstream bitrates, moderate upstream bitrates • Characteristics of game traffic are similar for all genres tested • Bitrates do not adapt to loss or latency, do adapt to capacity limits • Not TCP-Friendly • Frame rates adapt to both capacity limits and loss, but not to latency • OnLive downstream most like real-time video, upstream still much more than traditional games • Traces, slides available on-line at http://perform.wpi.edu/downloads/#onlive

  31. Future Work • OnLive Desktop • OnLive for Tablets (iOS and Android)

  32. Future Work • Comprehensive study of additional OnLive games Comparison of OnLive, GaiKai, other thin client systems

More Related