Networking for Physics Programmers @ GDC 2010
Author
Hey all, I've released the slides + demo for my GDC 2010 physics tutorial day talk "Networking for Physics Programmers"
A quick overview is that here is a technique for synchronizing a cooperative game P2P such that players feel no latency when interacting with physical objects (via authority scheme), plus a corrections scheme for streaming in changes made to the world before a player joined the game.
There is also a ton of previously unreleased upload/download bandwidth info from Sony, as well as some RTT and jitter analysis that you guys will probably find interesting!
You can download it from here:
gafferongames.com
Hope you guys like it!
Network measurement data is always great! Until now, the Halo 3 beta data has been one of the best sources, but it's starting to get old. As we say in California: Thanks for sharing!
One question about the sampled data. You said your server was on a low-cost VPS. This means that you were likely time-sliced. How much of the jitter spikes could have been caused by scheduling jitter on the VPS server?
Specifically, when we have measured kernel scheduler jitter on virtualized hardware, on some of the Amazon ECC instances, it would get as bad as 800 milliseconds, and none of them were better than 50 milliseconds. Even on our own hardware, just using virtualization gives us 30 ms scheduling jitter, instead of 3 ms scheduling jitter on a "bare metal" Linux system.
I agree with the conclusion that the Internet is jittery and lossy and generally a pain -- but your numbers would have significantly added weight if I knew that they were compensated for scheduler jitter. For example, you could have a timer that wakes up every 5 milliseconds if you don't get a packet, and measure jitter on that timer, and compare it to the jitter of the packets around that time.
Specifically, when we have measured kernel scheduler jitter on virtualized hardware, on some of the Amazon ECC instances, it would get as bad as 800 milliseconds, and none of them were better than 50 milliseconds. Even on our own hardware, just using virtualization gives us 30 ms scheduling jitter, instead of 3 ms scheduling jitter on a "bare metal" Linux system.
I agree with the conclusion that the Internet is jittery and lossy and generally a pain -- but your numbers would have significantly added weight if I knew that they were compensated for scheduler jitter. For example, you could have a timer that wakes up every 5 milliseconds if you don't get a packet, and measure jitter on that timer, and compare it to the jitter of the packets around that time.
Author
I agree that the VPS time slicing throws it off - the idea was not to make precise measurements, but to show that the amount of jitter may vary widely from connection to connection, and from day to day
I'll be following up with some actual dedicated server tests through Sony which should show "true" jitter without timeslice issues on the host
cheers
I'll be following up with some actual dedicated server tests through Sony which should show "true" jitter without timeslice issues on the host
cheers
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
