Performance estimation is used to find out bandwidth requirements for the protocol on the specification phase as we assume that the simulation performance is bandwidth limited instead of cpu,io or memory limited:

Performance Requirements

• 50 kbits / second bandwidth usage
• tracking of 1000 moving objects at once
• user experiences smooth movement

Current Situation

Assumption: Object movement observations dominate the bandwidth usage.

• Obsevation Frame Length: 64 bytes
• Dynamic object observation frequence: 4 / second
• Dynamic object count on client observation range: 1000
• Bandwidth per client: 64 * 4 * 1000 / second = 256 kbytes/second = 2 560 kbits/second

> Observations need to be compressed better.

Examples

Sending observation once a second on average and tracking 1000 objects with 50kbytes/second (500 kbits/second) would give 50 bytes observation message length.

Sending observation once a second on average and tracking 1000 objects with 50kbits/second would give 5 bytes observation message length.

> Observation signal compression is crucial. Performance requirements need to be tuned down as well.

• Is it enough to update only every 10 seconds if velocity data has not changed?
• What kind of compression algorithms can be used and what kind of compression ratio can be expected?
  • Good binary file compression can shrink the data size to 25% of the original size. Are similar results possible when compressing frame stream into packets of ~5000 bytes?

Compromise Proposal

• bandwidth per client: 25 kbytes / second (250 kbits / second)
• effective bandwidth with compression: 50 kbytes / second
• frame size: 64 bytes
• frames per second per object: 1 (including observations and actions)

• dynamic objects inside client observation radius: 800
• required total bandwidth for server with 1000 clients: 250 Mbits/second

> Total server bandwidth is still too high.

Compromise Proposal 2

• bandwidth per client: 10 kbytes / second (100 kbits / second)
• effective bandwidth with compression: 25 kbytes / second
• frame size: 64 bytes
• frames per second per object: 1 (including observations and actions)

• dynamic objects inside client observation radius: 400
• required total bandwidth for server with 1000 clients: 100 Mbits/second

Summary

If client movement prediction algorithms can provide smooth movement experience with observation updates of ~1 per second, frame size is 64 bytes, average dynamic object count inside each clients radius is under 400 and there is maximum of 1000 clients connected to the server then good operation is achievable with servers having 100 Mbits/second link to the internet backbone. If observed object count of a client raises then bandwidth throttling should gracefully drop non quaranteed packets and degrade the observed end user quality. If client amount is allowed to raise over 1000 then bandwidth throttling should lower the allowed bandwidth per client appropriately. 20% safety margin is recommended to avoid network congestion.

Compression efficiency raises linearly the amount of observable objects per client.

For fairness reasons bandwidth throttling limits each clients bandwidth to a preset value. => Client maximum bandwidth divided by server maximum bandwidth gives the maximum supported clients. Advanced networking implementation may give temporarily more bandwidth to clients at busy locations.

Note

Without compression support for 400 observed objects and 400 clients can be achieved with client bandwidth of 25 kbytes/second (250 kbits/second) and server bandwidth of 10Mbytes/second (100Mbits/second).