This page highlights some of the interesting things we’ve observed while studying Roofnet. These are just a few graphs and tables from our papers. You can find more details and read about how the experiments were conducted in the publications.

Link Level Measurements

The graphs in this section are taken from our SIGCOMM 2004 link-level measurements paper. The full text includes a more thorough explaination of each graph, more measurements and explains why multi-path echoes may cause the sorts of packet loss we’ve observed. We’ve seen similar behavior on our indoor testbed.

The graphs are generated from 90 second broadcast packet traces collected over each of the 400+ links in Roofnet. Each node sent broadcast packets (no link level ACK) as fast as it could at each of the 1, 2, 5.5 and 11Mbit/s rates for 90s while the other nodes recorded received sequence numbers.

Lots of Intermediate Links

Link Delivery Ratios: Links with intermediate loss rates are common, with no sharp transition between high and low packet loss rates. This graph shows the packet delivery ratios for each link at 1Mbit/s, where the top and bottom of each bar represent the forward and reverse delivery rate along the link. Many of the links in the network are asymmetric.

Distance and SNR vs. Delivery Ratio

Distance versus Delivery Rate at 1 and 11Mbit/s : Inter-node distance is not strongly correlated with whether nodes can communicate. There are some links in Roofnet 2.2km links in Roofnet with low loss rates, but also many short 50m links with high loss rates. Almost all the nodes are using the same antennas and radios.

Signal strength versus Distance at 1 and 11Mbit/s: Signal strength attenuates with distance, but would be difficult to predict based on distance alone.

Signal to Noise

Signal strength versus Delivery Rate at 1 and 11Mbit/s: Links with high signal strengths are likely to have low loss rates, but in general that signal strength has low predictive value. Most links in Roofnet tend to operate with link margins of 20dB or less. However, the clear channel assesment mechanism in the Prism cards used for medium access control considers the channel clear at 40dBm above the noise floor, which potentially causes collisions.

Loss over Time

Delivery probability over time: The graphs above show four 1Mbit/s links, each with around a 50% delivery rate. In the test, 80 1500-byte packets are sent per second for 90s, and the graphs are averaged in 200ms intervals. Some links, such as the top one, are very bursty, while others are not. The paper examines how bursty links are in general.

Optimal transmit bit-rate: We also found a link is likely to have a significant loss rate at its optimum 802.11b bit-rate. For example, a link with a 50% loss rate a 11Mbit/s still has higher throughput than a 1Mbit/s link with no packet loss.

Receiver Variation

Spatial Delivery Probability: The two plots show delivery probabilities for two senders from adjacent houses. There is correlation with distance, but the set of receivers differs between the two houses.

Long-term measurements

Each of the Roofnet nodes sends out periodic broadcast probes every few seconds to generate link metrics for the routing protocol. These probes measure delivery rate at each of the bit rates, for 1500 byte data packets and smaller ACKs.

Historical traces and plots of periodic broadcast probes are available from May 2004, June 2004 and August 2004. The raw dataset is also available as tar.bz2 archives. They are around 50MB in size (~1GB uncompressed text): May 2004, June 2004, August 2004.

Weather data from May 2004 (and other months) can be found at wunderground.com.

Month-long probe data

Probe packet delivery ratios over one month: The graph above shows probe packet delivery rates for a specific link over the month of June. Delivery rates tend to change daily, often out of sync with one another. We found no correlation with weather patterns.

Overall System Performance

These are measurements of end-to-end TCP throughput, taken from an upcoming paper on overall system performance.

Gateway Throughput

Most Roofnet users are within three hops of the three Roofnet gateways. Users see throughput and latency similar to DSL. The routing protocol automatically chooses the gateway with the lowest metric when each TCP transfer is started.

Hops # Nodes Throughput (kbits/sec) Latency(ms)
1 12 2752 9
2 8 940 19
3 5 552 37
4 7 379 43
5 1 89 37
avg: 2.3 Total: 33 Avg: 1395 Avg: 22

All-pairs Throughput

Though Roofnet does not generally route traffic between arbitrary pairs of nodes, it is helpful to understand how throughput and latency are affected by the number of hops. These experiments were done with RTS/CTS turned off. We’ve measured similar results with it turned on.

Hops # Pairs Throughput (kbits/sec) Latency (ms)
1 158 2451 14
2 303 771 26
3 301 362 45
4 223 266 50
5 120 210 60
6 43 272 100
7 33 181 83
8 14 159 119
9 4 175 182
10 1 182 218
avg: 2.9 total: 1332 avg: 627 avg: 39

802.11 radios are half-duplex, meaning they can only send or receive at a given time. Under ideal conditions, throughput over two and three hop routes ought to be 1/2 and 1/3 that of a single hop route, and longer routes are expected to also achieve 1/3 of the maximum throughput. Surprisingly, the performance over a two hop route is less than 1/2 that of one hop routes, implying routes tend to interfere with themselves.

Below is a table of the theoretical, loss-free maximum UDP throughput (in kbits/sec) for 1500 byte packets:

Rate 1 Hop 2 Hops 3 Hops
1 890 445 297
2 1634 817 545
5.5 3435 1718 1145
11 5013 2506 1671

Usage

Some summary statistics collected from one of the four Roofnet gateways over a 24-hour period: the gateway forwarded an average of 160 kbits/sec between Roofnet and the Internet. Around 48% of the traffic was to or from nodes one hop from the gateway, 36% two hops and the rest, about 16% was forwarded over three hops or more. The gateway’s radio was busy for around 70% of the monitoring time.

Almost all the packets forwarded were TCP, less than 1% were UDP. Web requests comprised only 7% of the bytes traferred, and the biggest consumer of bandwith, accounting for 30% of the total data transferred were BitTorrent.

While web requests account for a minority of the data traferred, they did account for more connections than any other application (68%).

 
  interesting.txt
 
Recent changes RSS feed Driven by DokuWiki