Technical Notes - Bandwidth Footprint Analysis
Results of analysis conducted averaging all forms of the spring 2005 field test on July 20 & 21, 2005
| Communications during the test | Packets |
Bytes |
| https received | 954 |
145597 |
| https sent | 1052 |
179560 |
| https total | 2006 |
325157 |
| http received | 6 |
545 |
| http sent | 6 |
457 |
| http total | 12 |
1002 |
| Total received | 960 |
146142 |
| Total sent | 1058 |
180017 |
| Total sent and received | 2018 |
326159 |
| Total Footprint | 326.16 |
Kb |
| Total data rate (send and receive) over 90 minutes | .48 |
Kbps |
Almost as much data is transferred to the server as received from the server. Averaging out the data transmitted over 90 minutes, results in a data rate of .27 Kbps, sent upstream. Since most ISPs bias traffic flow against traffic going upstream, this should be the rate we are most concerned about. This is a very small data rate. Overall, the test requires transmition of a minimal amount of data.
The graph below shows that traffic tends to burst up to 10,000 Bytes/10 secs, or 8 Kbps, when
bandwidth is freely available in the network. Bursts half that size are more common. The largest packets
are those containing encrypted application data.
To get an idea how many users may take the test at once, given no other applications traffic on the network, assume the baseline is the 56K modem. While the paragraph above implies that seven users should be able to take the test at once on a 56K modem, in practice this is an unreasonable expectation. This is due to the fact that computers generate overhead traffic, and ISP's tend to overbook bandwidth. From practical experience, only one or two users may take the test over a 56K modem.
Extrapolating support for concurrent test takers assuming no other network traffic on the following connections:Connection |
Users |
Notes |
| ISDN | 4-8 |
|
| DSL | 13-26 |
( if the pipe is symmetric) |
| Cable Modem | 6-12 |
(based on an asymmetric pipe biased in favor of downloads) |
| T1 | 18-36 |
Please note that keeping to the minimum limits above will yield very good performance in general. As you start to approach the upper limit, performance will degrade, such that the test will be slow at the upper limits. Also, if other applications run at the same time as the test on the network, performance will be negatively impacted.
This file was modified on Wednesday, August 29, 2007; at 1:36:41 PM