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.