dwarfs the one required by video.

This disproportion makes intuitive sense: while streaming a video requires little more than reading a file from disk and feeding it into a network stream, game and map servers have to perform complex operations such as keeping track of the game status or rendering the maps. However, its scale is somehow unexpected, and serves as a clear reminder that designing and deploying the [*computation*]{} part of a network, i.e., where and how to place its computational power, using only the traffic demand as a guideline is likely to result in poor performance and low efficiency.

The vastly different relationships between served traffic and CPU load are also evident from the linear fit we obtain from the two sets of experiments, represented by red lines in [Fig. \[fig:scatter\]]{}. The fitted relationships are as follows: $$\label{eq:model}
\text{CPU}_{[\text{ticks}]}=\begin{cases}
0.25\times\text{traffic}_{[\text{Mbit}]}+6.76 & \text{for video,} \\
161.38\times\text{traffic}_{[\text{Mbit}]}+1675.03 & \text{for gaming,} \\
67.44\times\text{traffic}_{[\text{Mbit}]}-7.53 & \text{for maps.} \\
\end{cases}$$ Looking at [Fig. \[fig:scatter\]]{}, it also important to observe how the fit is much better for maps traffic than for gaming: the root mean square error (RMSE) for maps is 2% while it is equal to 6% for gaming. The reason is that 