Measurement and characterization of Internet gaming traffic
Jani Lakkakorpia, Andreas Heinerb, Jussi Ruutuc Nokia Research Center, P.O. Box 407, FIN-00045 NOKIA GROUP, Finland
ABSTRACT
Most of the recent computer game releases support multiplayer options over Internet connections. The amount of Internet traffic generated by computer games can be expected to increase fast, especially when the new wave of players enters the Internet with the next generation game consoles that support Internet connections. In order to provide insight into this new but already significant part of Internet traffic, we have conducted a study of a number of popular Internet games. We defined four different classes of games: action games, simulators, real time strategy games, and turn based strategy games. Traffic generated by the representatives of these four different classes was measured and analyzed in terms of packet size distribution and packet interarrival time distribution. One of the main results of this study was that the amount of traffic generated by different games could vary heavily. For example, an action game could generate almost 15 kbps on average, while a turn based strategy game generated less than 1 kbps of traffic. In general, we observed small packets of a few distinct sizes rather than continuous packet size distributions. In most cases, interarrival times could be modeled by multimodal distributions consisting of extreme, normal or exponential distributions. Keywords: traffic measurements, traffic modeling, network games
1. INTRODUCTION
Internet gaming is a fast growing business. Currently every major game release is equipped with multiplayer support using a modem connection between two computers, a TCP/IP connection over the Internet, or a LAN connection. There exist no publicly available, standardized protocols for exchanging network gaming data. This means that different game software manufacturers utilize either their own or licensed protocols for network gaming. In practice, the details of network gaming traffic are not available. There exist several different types of network games with varying requirements for network support. Especially real time gaming traffic will most probably be highly sensitive to the Quality of Service of the network layer. In order to understand the nature of current computer games with network gaming support we performed measurements of traffic generated by four popular games. Here we present an analysis of traffic between two players in a LAN segment. There are not too many papers written about multiplayer game traffic modeling. A thorough analysis of Quake1-2 is one of the few works in this field. We have used similar modeling methodology in our work.
2. GAME CLASSIFICATION
There exist a wide range of network games. For practical purposes the following classification is used: 1. 2. 3. 4. Action games. These games usually contain virtual persons moving (and probably shooting at each other) in real time virtual environment. Example: Quake II (id Software, 1997).3 Simulators. Typically either flight or driving simulators. Main emphasis is on fast moving environment. Example: Grand Prix 3 (MicroProse, 2000).4 Real time strategy games. These games typically involve 2D or 3D terrain that contains several units moving and performing tasks in real time. Example: Age of Kings (Microsoft, 1999).5 Turn based strategy games. In these games, two or more participants (computer or real players) make their moves sequentially in turns. Example: Panzer General 3D: Assault (SSI, 1999).6
a
jani.lakkakorpi@nokia.com; phone +358 7180 08000; fax +358 7180 36851 andreas.heiner@nokia.com; phone +358 7180 37437; fax +358 7180 36851 c jussi.ruutu@nokia.com; phone +358 7180 37283; fax +358 7180 36851
b
The following general features of network games can be distinguished: • • • Network connection type. Most of the network games have a support for modem, TCP/IP, and LAN (Ethernet) connections. Null-modem (serial port) support is provided in some cases, too. Number of players. Naturally, two players are the minimum. In some cases more than ten players can share the same game. Client-server association. Usually one of the IP hosts acts as the server while the rest of the hosts log in to the game as clients. In some cases, a separate network gaming server – maintained by the game manufacturer or a third party – is used.
3. METHODOLOGY
3.1. Measurement methodology The goal of the measurements was to define the characteristics of the above-mentioned game types. Strong emphasis was on generating enough understanding for modeling network games as IP traffic sources. Measurements were performed in the environment described in Figure 1.
Workstation Measurement Device Ethernet Hub
Workstation
Figure 1: Measurement setup
Two workstations (with Pentium II processors and 128Mb of RAM) were used with Windows 98 operating system. The workstations were connected using 10/100 Ethernet connection to a 10/100 Ethernet hub. A Shomiti Advanced Test System (ATS)7 measurement device was also connected to the hub. The measurement device was used for making full trace of each measurement session, i.e. all traffic between the hosts involved in the game session. The traces include full IP(v4) headers and payloads. The hosts were configured so that no other network application was used at the time of the measurements. Each measurement session consisted of two players playing a particular game (see the example games in section 2) for five to ten minutes. Results presented in this paper are the averages of ten independent sessions. Different players were used in order to eliminate the effect of a single playing style. The selected connection type was always TCP/IP connection over the Internet. In addition to the actual gaming traffic, the measurement traces contain the game initialization phases, too. 3.2. Characterization methodology Traffic characterization methodology of this study follows closely the algorithm described in Refs. 2, 8-9: 1. The probability distribution of the data set is visually examined and an appropriate analytical distribution is chosen. One suitable distribution, in addition to the usual ones, seems to be the extreme distribution:
f ( x) =
x − a . x − a 1 exp− exp− exp − b b b
(1)
A good technique for binning a continuous distribution is introduced in Ref. 10. This method chooses an optimal number of fixed-size bins. Bin width is given by
w = 3.49σn −1 / 3 ,
where σ is an estimate of the standard deviation and n is the sample size. 2.
(2)
The data set is fitted to the analytical distribution. Method of least squares is used to determine the distribution parameters. If the fit deviates for a particular part of the distribution (can be seen from quantile-quantile plot), it should be considered modeling the data set with a split distribution. The λ2 discrepancy measure of the fit11 returns a non-negative value for the discrepancy between the actual and the ˆ assumed statistical model. The smaller the discrepancy, the better the model. An estimator λ 2 is developed for the case where data are grouped:
3.
4.
X 2 − K − df ˆ . λ2 = n −1
(3)
Here n is the number of observations in the data set and df is the number of degrees of freedom of the test. df is the number of bins minus one minus the number of parameters that were used to estimate the analytical distribution. X2 and K are given by the following equations:
X2 =∑
i =1
N
(Yi − npi ) 2 , npi
(4)
K =∑
Yi − npi . npi i =1
N
(5)
Yi is the number of items in bin i of the empirical data and npi is the number of items in bin i of the analytical distribution. To solve the possible divide-by-zero problem with deterministic distributions, the following alternative equations2 are used:
X2 =∑
i =1
N
( np i − Yi ) 2 , Yi
(6)
K =∑
i =1
N
np i − Yi . Yi
(7)
These equations are evaluated only where the empirical data set is non-zero. 5. The upper tail is examined for deviations using8-9
ξ = log 2
a . b
(8)
When the model is tested against a data set, a is the number of instances predicted to lie in a given tail, and b is the number of instances that actually lay in this tail. (In the case where b is zero, it is replaced by 0.5.) Positive values of ξ indicate that the model overestimates the tail, and negative values that it underestimates the tail. For both the packet interarrival and size statistics, extreme upper tails were found. However, they are not heavy. In most cases, the extreme tail has been ignored when constructing the model. In Section 4, it is explicitly noted when tail truncation has been performed. The magnitude of the truncation is expressed as the number of discarded items and their share of total items. An indication when the model underestimates (-) or overestimates (+) the tail (after the outliers have been removed) is also included. 6. The autocorrelation of the traffic trace is calculated. We are mostly interested in short-term autocorrelation, especially at lag 1. The mean for this value, ACF(1), is calculated from different traces. Autocorrelation plots are stored in Appendix A. Dotted lines denote the individual autocorrelation functions while the solid line denotes their average.
4. RESULTS AND DISCUSSION
4.1. Measurement results Packet size contains payload and UDP header. Mean bit rate, however, is calculated with full IPv4 overhead (20 bytes added). Since the packets were generally small, the use of IPv6 (overhead of 40 bytes) would have resulted into considerably higher bit rates. Momentary bit rates for the first traces of each game were also calculated. The Exponential Moving Average Meter12 was used with the following parameters: Delta = 25ms, Gain = 1/16. These graphs are not included in this paper due to space constraints.
Table 1: Measurement results
Game Quake II (10 traces)
Client/Server Client Server
Grand Prix 3 (10 traces)
Client Server
Age of Kings (10 traces)
Client Server
Panzer General (2 traces)
Client Server
Data Interarrivals Packet Sizes Interarrivals Packet Sizes Interarrivals Packet Sizes Interarrivals Packet Sizes Interarrivals Packet Sizes Interarrivals Packet Sizes Interarrivals Packet Sizes Interarrivals Packet Sizes
Packets 76635 76645 31006 31016 52157 52167 52173 52183 24135 24145 24293 24303 462 464 453 455
Mean 40.6ms 45B 102ms 77.9B 80.2ms 26.3B 80.2ms 26.3B 136ms 32.0B 132ms 33.3B 4660ms 30.0B 4360ms 44.2B
Standard Deviation 22.5ms 4.74B 105ms 52.5B 109ms 8.35B 108ms 8.12B 296ms 8.92B 230ms 13.5B 6600ms 9.31B 5250ms 67.9B
Mean Bit Rate 12.8kbps 7.69kbps 4.62kbps 4.62kbps 3.06kbps 3.24kbps 0.0859kbps 0.118kbps
4.2. Suggested models All games studied in this paper used UDP for carrying the gaming data. However, a few observations of TCP packets were experienced before the actual game had started. TCP is most probably used to transfer non-real time player information. 4.2.1. Quake II
The Probability Distribution of Server Packet Sizes (Payload + UDP) 0.15
P{Packet Size = x}
0.1
0.05
0
50
100
150 200 Packet Size [Bytes]
250
300
Figure 2: Quake II – server packet sizes
The number of packets sent by the client was approximately 2.5 times larger than the number of packets received. Client packet sizes can be modeled with a distribution consisting of a number of distinct packet sizes. For the server packet size distribution we suggest a bimodal extreme distribution. It seems that both client and server packet sizes are strongly correlated; autocorrelation at lag 1 is more than 0.96 in both cases. Autocorrelation plots (Appendix A) also indicate this. The interarrival times of client-generated traffic can be modeled with two extreme distributions. For the server interarrival time distribution we suggest a combination of extreme and normal distributions. Client and server interarrival times are also correlated. However, these autocorrelations are not as strong as the autocorrelations of packet sizes. Since both packet sizes and interarrival times are correlated, the assumption of data independence should be discarded – at least in the case of client packet sizes. A simple way to implement Quake II client and server as IP traffic sources in simulator environment would be to assume data independence for client & server interarrival times and for server packet sizes. Client packet sizes could be realized with a Markov chain, where different states would represent different packet sizes.13 To find out all possible state transition probabilities definitely requires some further studies.
Table 2: Models for Quake II
Data Client Interarrivals Client Packet Sizes
Model Lower 4.5%, x < 18: Extreme Upper 95.5%, x ≥ 18: Extreme Seven distinct values
Parameters a=6.57, b=0.517 a=37.9, b=7.22 10.6%: 36, 26.4%: 42, 6.26%: 44, 13.9%: 45, 4.95%: 46, 16.3%: 48, 21.5%: 51 a=58.2, b=7.47 a=100, b=17.7 a=46.7, b=4.39 a=79.7, b=11.3
ˆ λ2
0.924 0.0294 0.11
Tail 15 (0.020%)/0/0
ACF(1) 0.837 0.999
Server Interarrivals Server Packet Sizes
Lower 4.8%, x < 60: Extreme Upper 95.2%, x ≥ 60: Normal Lower 27.6%, x < 55: Extreme Upper 72.4%, x ≥ 55: Extreme
0.855 0.0572 0.729 0.132
27 (0.087%)/0/-
0.647 0.969
The Probability Distribution of Client Interarrival Times
The Probability Distribution of Server Interarrival Times
0.05 0.04
P{Interarrival Time = x}
0.03
P{Interarrival Time = x}
0.04
0.03
0.02
0.02
0.01 0.01
0
20
40
60 80 100 Interarrival Time [ms]
120
140
0
50
100 150 Interarrival Time [ms]
200
Figure 3: Quake II – client interarrivals
Figure 4: Quake II – server interarrivals
4.2.2. Grand Prix 3 In Grand Prix 3, the client sends and receives equal amounts of packets. The size of the packets received is also about as large as the size of packets sent. Packet size distributions consist of two distinct values. It should be noted that during the actual gaming phase, the packet size remains the same. The smaller packet size is used only in the beginning and end of a session. This behavior creates a very strong autocorrelation for packet sizes. For client and server generated traffic, interarrival time can be modeled by a mixture of extreme, deterministic and exponential distributions. The "lowest part" of the distribution should be used only when modeling the beginning or end of a gaming session. Since autocorrelation is only moderate, we can assume data independence. A simple simulation model for Grand Prix 3 client and server can be implemented as follows: • • In the beginning and end of a session, use the smaller packet size. For interarrivals: use the whole distribution. In the actual gaming phase, use the larger packet size. For interarrivals: use the two "upper" parts of the distribution.
Table 3: Models for Grand Prix 3
Data Client Interarrivals Client Packet Sizes Server Interarrivals Server Packet Sizes
Model Lower 6%, x < 35: Extreme Middle 28.1%, 35 ≤ x < 70.5: Deterministic Upper 65.9%, x ≥ 70.5: Exponential Two distinct values Lower 6.1%, x < 35: Extreme Middle 31.1%, 35 ≤ x < 70.5: Deterministic Upper 62.8%, x ≥ 70.5: Exponential Two distinct values
Parameters a=4.91, b=0.677 a=70 a=0.0569 10.6%: 18, 89.4%: 27 a=10.4, b=-0.373 a=69 a=0.0479 10.3%: 18, 89.7%: 27
ˆ λ2
0.916 0.972 0.0923 0.00259 0.934 0.480 0.181 0.00483
Tail 97 (0.19%)/0/0 81 (0.16%)/0/0
ACF(1) 0.630
0.995 0.482
0.995
The Probability Distribution of Client Interarrival Times 0.25 0.35
The Probability Distribution of Server Interarrival Times
0.3 0.2 0.25
P{Interarrival Time = x}
0.15
P{Interarrival Time = x}
50 100 150 200 Interarrival Time [ms] 250 300
0.2
0.1
0.15
0.1 0.05 0.05
0 0
0 0
50
100
150 200 Interarrival Time [ms]
250
300
Figure 5: Grand Prix 3 – client interarrivals
Figure 6: Grand Prix 3 – server interarrivals
4.2.3. Age of Empires II: Age of Kings Both client and server packet size distributions can be modeled by distributions with two dominating values. Since autocorrelation is strong for packet sizes, data independence should not be assumed. The sequence of packet sizes could be realized with a Markov chain in the same manner as with Quake II client packet sizes. The interarrival time distributions can be modeled reasonably well with mixtures of exponential and normal distributions. Since autocorrelation is moderate, we can assume data independence.
Table 4: Models for Age of Kings
Data Client Interarrivals Client Packet Sizes Server Interarrivals Server Packet Sizes
Model Lower 81.5%, x < 210: Exponential Upper 18.5%, x ≥ 210: Normal Four distinct values Lower 82.1%, x < 210: Exponential Upper 17.9%, x ≥ 210: Normal Four distinct values
Parameters a=0.00681 a=227, b=17.5 53.5%: 24, 43.5%: 40, 1.9%: 48, 1.1%: 64 a=0.00680 a=228, b=18.6 50.4%: 24, 43.6%: 40, 4.9%: 48, 1.1%: 64
ˆ λ2
0.0589 0.753 0.0119 0.0644 0.709 0.0204
Tail 188 (0.78%)/0/0 176 (0.72%)/0/0
ACF(1) 0.375 0.954 0.327 0.924
4.2.4. Panzer General 3D: Assault The fact that the transmission protocol used in Panzer General is UDP, is somewhat surprising, as there are no real time restraints in this game. Even though the overhead of the TCP protocol is larger, the nature of this game demands that the moves are registered accurately by the other player. We therefore speculate that reliability is introduced at the application level. Both client and server packet sizes can be modeled with distributions consisting of a number of distinct packet sizes. Autocorrelation is once again strong, and data independence cannot be assumed. The sequence of packet sizes should be realized with a Markov chain. The interarrival time distributions for client and server can both be modeled by a simple exponential distribution. Autocorrelation is fairly low, and data independence can be assumed. The small data sets prevent the fitting of more detailed models. The nature of the game (turn based) is likely to account for the long interarrival times.
The Probability Distribution of Client Interarrival Times
The Probability Distribution of Server Interarrival Times
0.1
0.1
P{Interarrival Time = x}
0.06
P{Interarrival Time = x}
0.08
0.08
0.06
0.04
0.04
0.02
0.02
0
50
100
150
200 250 300 Interarrival Time [ms]
350
400
450
0
50
100
150
200 250 300 Interarrival Time [ms]
350
400
450
Figure 7: Age of Kings – client interarrivals
The Probability Distribution of Client Interarrival Times 0.7 0.5
Figure 8: Age of Kings – server interarrivals
The Probability Distribution of Server Interarrival Times
0.6 0.4 0.5
P{Interarrival Time = x} P{Interarrival Time = x}
0.4
0.3
0.3
0.2
0.2 0.1 0.1
0 0
1
2
3 4 Interarrival Time [ms]
5
6 x 10
7
4
0 0
0.2
0.4
0.6
0.8 1 1.2 Interarrival Time [ms]
1.4
1.6
1.8 x 10
2
4
Figure 9: Panzer General – client interarrivals
Figure 10: Panzer General – server interarrivals
Table 5. Models for Panzer General
Data Client Interarrivals Client Packet Sizes
Model Exponential Seven distinct values
Parameters a=0.000323 50.2%: 22, 10.1%: 30, 11.6%: 34, 4.96%: 38, 19.8%: 42, 1.29%: 46, 1.94%: 60 a=0.000344 49.9%: 22, 10.1%: 30, 12.8%: 34, 1.57%: 38, 17.5%: 42, 1.35%: 46, 6.74%: 130
ˆ λ2
0.0637 0.0216
Tail 0/0/0
ACF(1) 0.240 0.963
Server Interarrivals Server Packet Sizes
Exponential Seven distinct values
0.104 0.0244
0/0/0
0.302 0.490
5. CONCLUSIONS AND FUTURE WORK
Traffic generated by four different PC games has been measured, and models for the packet interarrival times and packet sizes have been created. The use of a dedicated line between game server and client guarantees that the actual source characteristics were measured. The observed traffic characteristics are sufficiently simple to permit implementation in network simulators such as ns-2 or OpNet. 14-15 One of the main conclusions of this study is that traffic characteristics of the four games studied are different from each other. In general, action games, simulators and real time strategy games produce real time traffic (the order of magnitude for interarrival times is tens of milliseconds) while turn based strategy games clearly produce non-real time traffic (the order of magnitude for interarrival times is a few seconds). We also observed that all games used UDP for transmitting the actual user commands. This is quite natural, since most games have some sort of real time demands, and we probably would not benefit from retransmitting the lost packets. However, TCP was used in the beginning of the gaming sessions, when the actual game had not started yet. This behavior has not been modeled. Since UDP traffic generation is independent of the network state, it can be modeled by simple models. An important conclusion is that all the measured games can be supported by many existing or future wireless technologies – at least in terms of required data rates. However, the end-to-end transfer delay may become critical for some games, because some wireless networks can introduce a delay of several hundreds of milliseconds even for real time traffic. It can also be expected that in the near future, with increasing residential bit rates (with cable modems and xDSL lines) the network games will start to support and/or require higher bit rates than at present. It is therefore essential to follow closely the developments in this segment of network applications. Based on the results described in this study, following things could be studied in the future: • • • The effect of increasing the number of users. The effect of reduced QoS (i.e. packet loss, delay) on the performance of games. Comparison of different connection types. In our preliminary studies, we have found out that the bit rates (and packet sizes) can be much higher when the game is played in LAN mode.
REFERENCES
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. M. S. Borella, "Source Models of Network Game Traffic", Computer Communications 23(4), pp. 403-410, Feb. 2000. M. S. Borella, "Source Models of Network Game Traffic", Proceedings of NetWorld+Interop 99: Engineer’s Conference, Las Vegas, May 1999. id Software, Quake II, http://www.idsoftware.com/quake2/index.html, May 2001. MicroProse, Grand Prix 3, http://www.grandprixgames.com/grandprix3/english/index.html, May 2001. Microsoft, Age of Kings, http://www.microsoft.com/Games/age2/, May 2001. SSI, Panzer General 3D, Assault, http://www.panzergeneral3.com/, May 2001. Shomiti Advanced Test System, http://www.shomiti.com/products/, May 2001. V. Paxson, "Empirically-Derived Analytic Models of Wide-Area TCP Connections: Extended Report", Report LBL34086, Lawrence Berkeley Laboratory, Aug. 1993. Available at ftp://ftp.ee.lbl.gov. V. Paxson, "Empirically-Derived Analytic Models of Wide-Area TCP Connections", IEEE/ACM Transactions on Networking 2(2), pp. 316-336, Aug. 1994. D. W. Scott, "On Optimal and Data-Based Histograms", Biometrika 66, pp. 605-610, 1979. S. P. Pederson and M. E. Johnson, "Estimating Model Discrepancy", Technometrics 32(3), pp. 305-314, Aug. 1990. Y. Bernet, S. Blake, D. Grossman, A. Smith, "An Informal Management Model for Diffserv Routers", Internet Draft (Expires in August 2001), Feb. 2001. V. S. Frost and B. Melamed, "Traffic Modeling for Telecommunications Networks", IEEE Communications Magazine, pp. 70-81, Mar. 1994. UCB/LBNL/VINT Network Simulator – ns (version 2), http://www.isi.edu/nsnam/ns/index.html, May 2001. OpNet Modeler, http://www.mil3.com/products/modeler/home.html, May 2001.
A. AUTOCORRELATION PLOTS
A.1. Quake II
The Autocorrelation of Client Packet Sizes 1
1 The Autocorrelation of Client Interarrival Times
0.95
0.996
0.9
Correlation Coefficient
Correlation Coefficient
0.992
0.85
0.8
0.988
0.75
0.7
0.984
0.65
0.98 0
10
20
30
40
50 Lag
60
70
80
90
100
0.6 0
10
20
30
40
50 Lag
60
70
80
90
100
The Autocorrelation of Server Packet Sizes 1 1
The Autocorrelation of Server Interarrival Times
0.95
0.9
0.9
Correlation Coefficient
0.8
0.85
Correlation Coefficient
10 20 30 40 50 Lag 60 70 80 90 100
0.7
0.8
0.6
0.75
0.5
0.7
0.4
0.65
0.3
0.6 0
0.2 0
10
20
30
40
50 Lag
60
70
80
90
100
A.2. Grand Prix 3
1 The Autocorrelation of Client Packet Sizes
1
The Autocorrelation of Client Interarrival Times
0.95
0.99
0.9
0.85
Correlation Coefficient
Correlation Coefficient
0.98
0.8
0.97
0.75
0.7
0.96
0.65
0.95
0.6
0.55
0.94 0
10
20
30
40
50 Lag
60
70
80
90
100
0.5
0
10
20
30
40
50
60
70
80
90
100
Lag
The Autocorrelation of Server Packet Sizes 1 1
The Autocorrelation of Server Interarrival Times
0.99
0.9
0.8
Correlation Coefficient
Correlation Coefficient
10 20 30 40 50 Lag 60 70 80 90 100
0.98
0.7
0.97
0.6
0.96
0.5
0.95
0.4
0.94 0
0.3 0
10
20
30
40
50 Lag
60
70
80
90
100
A.3. Age of Kings
The Autocorrelation of Client Packet Sizes 1 0.99 0.98 0.8 0.97
Correlation Coefficient
The Autocorrelation of Client Interarrival Times 1
0.9
Correlation Coefficient
10 20 30 40 50 Lag 60 70 80 90 100
0.7
0.96 0.95 0.94 0.93 0.92 0.91
0.6
0.5
0.4
0.3
0.2 0.9 0 0 10 20 30 40 50 Lag 60 70 80 90 100
The Autocorrelation of Server Packet Sizes 1 0.99 0.98
1
The Autocorrelation of Server Interarrival Times
0.9
0.8
0.97
Correlation Coefficient
Correlation Coefficient
0.96 0.95 0.94 0.93 0.92 0.91
0.7
0.6
0.5
0.4
0.3
0.9 0 10 20 30 40 50 Lag 60 70 80 90 100
0
10
20
30
40
50 Lag
60
70
80
90
100
A.4. Panzer General
The Autocorrelation of Client Packet Sizes 1
The Autocorrelation of Client Interarrival Times 1
0.9
0.9
0.8
0.8
Correlation Coefficient
0.7
Correlation Coefficient
10 20 30 40 50 Lag 60 70 80 90 100
0.7
0.6
0.6
0.5
0.5
0.4
0.4
0.3
0.3
0.2 0
0.2 0
10
20
30
40
50 Lag
60
70
80
90
100
The Autocorrelation of Server Packet Sizes 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 1
The Autocorrelation of Server Interarrival Times
0.9
0.8
Correlation Coefficient
Correlation Coefficient
10 20 30 40 50 Lag 60 70 80 90 100
0.7
0.6
0.5
0.4
0.3
0.2 0
10
20
30
40
50 Lag
60
70
80
90
100