Real-Time Load Balancing of an Interactive Mutliplayer Game Server
14
QUAKEWORLD: REAL-TIME LOAD BALANCING James Munro & Dr. Patrick Dickinson University of Lincoln EUROSIS GAME-ON 2010 17 th – 19 th November
-
Upload
james-munro -
Category
Technology
-
view
545 -
download
0
description
Transcript of Real-Time Load Balancing of an Interactive Mutliplayer Game Server
QUAKEWORLD: REAL-TIME LOAD BALANCING
James Munro & Dr. Patrick DickinsonUniversity of Lincoln
EUROSIS GAME-ON 201017th – 19th November
INTRODUCTION
Parallel/multi-threaded programming: Emerging trend of game development. Crucial to leverage power of modern
hardware. Can be difficult: we’re still learning!
Two approaches in research: Client-side (directly effects end-user). Server-side (indirectly effects end-user).
AN EXISTING SYSTEM
Multi-threaded QuakeWorld: Exploits COW semantics of Linux kernel. Entity pre-processing allows lockless
execution. Dynamic load balancing strategy. Improved performance over previous work.
We used this as the starting point for our work.
Cordeiroet al
PARALLEL QUAKEWORLD FRAME
Update world state
Wait for client input
Entity pre-processing
Load balancing
Launch child
threads
Process client
requests (parallel)
Send responses (parallel)
Synchronise with main
thread
We’re mostly interested in this step
EXPERIMENTAL SETUP
Seven quad-core PCs. One server (32-bit Linux). Six clients (32-bit Windows).
Using headless automated player “bot”. Up to 32 bots per-machine.
Four load balancing algorithms: Longest Processing Time First (LPTF) – good performance. Shortest Processing Time First (SPTF) – worse performance. Round-Robin (RR) - unsure. Sorted Round-Robin (SRR) - unsure.
METRICS / INITIAL RESULTS
We use the following set of metrics: FPS. Workload distribution. Server throughput. Intra-frame wait time.
Performed an initial benchmark: Serial, 2, 3, 4 threads. Discovered that 4 threads is best. Cordeiro et al needed to consider further metrics. Had to artificially limit performance due to bandwidth. Uncapped, could support 400-600 players.
WORKLOAD DISTRIBUTION (LPTF)
1 2 3 40
200,000
400,000
600,000
800,000
1,000,000
1,200,000
1,400,000
Thread ID
Accu
mu
late
d W
ork
gro
up
W
eig
ht
WORKLOAD DISTRIBUTION (SPTF)
1 2 3 40
200,000
400,000
600,000
800,000
1,000,000
1,200,000
1,400,000
Thread ID
Accu
mu
late
d W
ork
gro
up
W
eig
ht
WORKLOAD DISTRIBUTION (RR)
1 2 3 40
200,000
400,000
600,000
800,000
1,000,000
1,200,000
1,400,000
Thread ID
Accu
mu
late
d W
ork
gro
up
W
eig
ht
WORKLOAD DISTRIBUTION (SRR)
1 2 3 40
200,000
400,000
600,000
800,000
1,000,000
1,200,000
1,400,000
Thread ID
Accu
mu
late
d W
ork
gro
up
W
eig
ht
SERVER THROUGHPUT – ALL ALGORITHMS
96 112 128 144 160 1762,750
3,250
3,750
4,250
4,750
5,250
LPTFSPTFRRSRR
Number of Clients
Th
rou
gh
pu
t (R
PP
/s)
IFWT– ALL ALGORITHMS
96 112 128 144 160 1760
0.5
1
1.5
2
2.5
3
3.5
4
LPTFSPTFRRSRR
Number of Clients
Wait
Tim
e (
ms)
STANDARD DEVIATION (LPTF, SPTF, SRR)
1 2 3 40
2
4
6
8
10
12
14
LPTFSPTFSRR
Thread ID
Std
.Dev o
f P
rocessed
En
tity
G
rou
ps
CONCLUSIONS
Concurrency will be crucial in game development.
A full set of metrics is required to quantify performance.
Best load balance is a trade-off: Consistently producing a decent
distribution. Reducing IFWT, less time spent waiting.
