throughput)&snr)infreespace:) applied)to)thedesign)of...

Throughput & SNR in Free Space:

Applied to the Design of the Bobby Dodd Stadium Wireless Network

Jose Fundora Christopher Holmes

Professor Randal Abler

ECE 4902 eStadium Project Summer 2010

Georgia Institute of Technology School of Electrical and Computer Engineering

1

Table of Contents

Introduction............................................................................................................................ 2 Shannon’s Theorem ......................................................................................................................... 2 Results ............................................................................................................................................. 2

Design Specifications .............................................................................................................. 3 Battery Cart ..................................................................................................................................... 3 Linksys WRT160NL Access Point ....................................................................................................... 4

Methodology .......................................................................................................................... 8 Destructive Interference Equations and Analysis.............................................................................. 8 SNR Graph ......................................................................................................................................10

Results.................................................................................................................................. 11 SNR.................................................................................................................................................11 Throughput .....................................................................................................................................12 Rabps vs Tbps .................................................................................................................................15

Pkt/sec vs Tbps ...............................................................................................................................18

Conclusion ............................................................................................................................ 21 Shortcomings ..................................................................................................................................21

Future Improvements and Recommendations.................................................................................21

Appendix A: Step-‐by-‐Step Checklist To Flash DD-‐WRT Onto A Router.................................... 23

Appendix B: UDP Packet Transmission Test........................................................................... 31

2

Introduction

The eStadium project is presented with an intriguing situation that does not normally arise in 802.11 networks. The goal of our project includes reliably delivering video and data to 2000+ users over an 802.11 network deployed in Bobby Dodd Stadium at Georgia Tech. Users access the eStadium website via their personal smart phones and can request video replays, statistics and other infotainment. The wireless team is tasked with designing and deploying a network of access points (APs) and antennas to generate optimal network coverage and provide sufficient signal strength to support connection speeds of up to 11 Mbps. Moreover we will ensure good quality of service to a maximum number of users on the network.

The expected outcome is to successfully flash the APs with the DD-‐WRT firmware and to document this process so that future eStadium members can easily follow a step by step procedure. Also, we will successfully load our custom C code to control the transmission of the TCP and UDP datagrams. In the testbed network we will perform tests to verify that video can be streamed to a large number of users. By the end of the semester we will have a working testbed network in the VIP lab and a mobile testbed network to perform throughput, power and SNR measurements in free space.

Shannon’s Bandwidth Capacity Theorem

Claude Shannon proved that every physical channel has a capacity C, defined as the maximum possible rate that information can be transmitted with reliability over the channel. For example: sending data at X Mbps there is a Y noise; doubling the sending rate to 2X Mbps will result in 2Y noise. Shannon’s formula to calculate the expected capacity is as follows:

Equation 1. C = W * log2(1 + (Power/Noise))

C is in bits/sec (bps), W is the bandwidth of the channel in Hz, and the log term is in bits/cycle. To convert from dB to bits/cycle the formula is:

Equation 2. Power/Noisebits/cycle = 10(Signal/Noise in dB)/10

As wireless signals travel through the air power is lost and may encounter interference from other signals. Noise affects how efficiently the wireless signal can be encoded therefore how many bps can be carried on one cycle of bandwidth; this is bandwidth efficiency. As power decreases, the signal-‐to-‐noise (SNR) decreases, and there is a possibility for error to increase.

Results

In this report will be shown the data transfer between sender and receiver and see if it correlates with Shannon’s Theorem.

3

Design Specifications

The electronic hardware used to perform this experiment consists of:

• 1 MacBook Pro Laptop • 1 Hewlett Packard Laptop • 1 Broadcom 4322AG 802.11 a/b/g/n Wi-‐Fi Adapter • 1 Linksys WRT160NL IEEE 802.11b/g/n Wireless Access Point • 1 DieHard 10/2/20 Amp Battery Charger • 1 DieHard 12 Volt Battery • 1 Stanley 500 Watt Inverter • 1 Belikin 6 Foot Surge Protector

Each laptop is running a Linux operating system, the MacBook Pro is running Ubuntu 9.10 and the HP laptop is running Ubuntu 9.04. The HP laptop has the Broadcom 4322AG internal Wi-‐Fi adapter. The MacBook Pro is connected to the Linksys AP via a Cat5e ethernet cable. The MacBook Pro and AP are powered by connecting the AC adapters to the surge protector on the battery cart.

Battery Cart

The battery cart was constructed in order to provide power to a laptop and AP while taking measurements in a location without easy access to a sustainable power source. One Deep Cycle Battery provides 12 Volts of DC power and has a reserve capacity of 3 hours. The battery was charged prior to taking measurements with the DieHard 10/2/20 Amp Battery Charger. The battery charger controls must be set to 10 Amps and Maintenance Free Deep-‐Cycle. The battery is fully charged when the internal ammeter on the battery chargers reads 0 and the LED is lit. It is important to note that the battery charger must be plugged into a grounded AC outlet and connected to the terminals of the battery with 6 AWG or higher gauge wire. On the battery cart, the battery is connected using 18 AWG wire to the 500 Watt Inverter. The inverter converters 12 Volts of DC power to 110/120V AC with an output current of 4.1 Amps. It is important to note that the AP and the MacBook Pro laptop draw 1.5 Amps of current each and the HP laptop draws 1.7 Amps of current. Thus, the AP and only one other laptop may be connected while taking measurements rendering it imperative to fully charge both laptops beforehand.

The battery cart was assembled by attaching a 2’ by 1’ piece of plywood to a metal dolly. This attachment was accomplished by fastening wire ties through 1/8” drilled holes along the

4

perimeter and in the middle of the plywood. The surge protector and inverter were also fastened with wire ties while the battery was lashed to the cart with fabric (Figure 2).

Linksys WRT160NL Access Point

The firmware that comes pre-‐loaded with the Linksys AP is limited in capabilities. To overcome these limitations with the Linksys firmware, the AP was flashed with the DD-‐WRT firmware. Great care and precision is needed to flash the AP since any mistake made in the process can “brick” the router which renders it completely useless until an extremely difficult JTAG hardware reset is executed. After downloading the correct bin files, a “killer” firmware is uploaded to the AP. This firmware is a stripped down version of DD-‐WRT that overwrites the Linksys scripts. It overwrites the scripts as the router is being flashed to make space on the NVRAM for the full version of DD-‐WRT. The full version of DD-‐WRT then overwrites the “killer” version as it is being flashed on the router. The full process of flashing the AP can be viewed in Appendix A.

Both the Linksys and DD-‐WRT firmware share common capabilities that are important to understand for the design and testing of the network. A list of these standard capabilities and a brief description of their purpose is available in Table 1.

Figure 1. Battery Cart.

5

Table 1. Important firmware capabilities shared by Linksys and DD-‐WRT. Setting Description

Set the SSID and password Set the name and password of the network. SSID Broadcast Allows the SSID to be hidden from users attempting to connect to the

network. Wireless Security Wi-‐Fi Protected Access (WPA/WPA2) and Wired

Equivalent Privacy (WEP) are the available encryption protocols. MAC address filtering Allows only devices with a specific MAC address to connect to the

network. Mixed network mode b/g/n Allows devices with different 802.11 protocols to connect to the

network. Channel Width The channel bandwidth can be adjusted to either 20 MHz or 40 MHz

depending on the corresponding 802.11 protocol with b/g operating in the 20MHz band and n operating in the 40 MHz band.

Port Forwarding and Triggering

A port or range of ports may be designated for a specific application.

QoS Bandwidth Management Guarantees a bandwidth relationship between individual applications or protocols. Prioritize by application, port range, IP address or MAC address.

Statistics &Logs The Linksys AP has limited logging and statistical functions: • Incoming Log displays the source IP addresses and destination

port numbers for the incoming traffic. • Outgoing Log displays a temporary log of the local IP

addresses, destination URLs/IP addresses, and service/ port numbers for the outgoing traffic.

IPV6 The AP is enabled to handle clients that utilize the IPV6 protocol. IPV6 devices use a 128 bit addressing scheme to connect to IP addresses.

AP Isolation/Client Isolation Mode

Prevents devices on the network from communicating with each other, they can only communicate with the AP.

Transmission Rate Allows the administrator to manually throttle the transmission rate based on the properties of the network.

Fragmentation Threshold Maximum data allowed before a packet is fragmented and sent as two or more packets. The maximum value is 2346 bytes for wireless and 1500 bytes for Ethernet. A lower value can be specified.

Manual MTU Set the maximum packet length allowed to be transmitted from the sender to the receiver.

The network SSID was set to estadium and the password to e$tad465 for the measurements performed. When the network is deployed in the stadium the network will broadcast the same SSID for every game whereas the password will change and displayed to the fans each week. WPA encryption can be utilized in the network since it is more secure than WEP because it changes encryption keys at a specified time interval. Some older devices do not support WPA; however most of the devices that will access the network in the stadium are

6

smartphones that support WPA. MAC filtering will allow the Wi-‐Fi network to require devices to login in only once whereas fans accessing the eStadium site from a cellular network will have to login each week. A list of MAC addresses will be maintained allowing those users access to the network and also track the number of repeat users on the network.

The APs mixed network mode will allow devices with 802.11 b/g/n to access the network. All modern devices with an internal Wi-‐Fi card operate under the three aforementioned protocols. For the throughput measurements acquired in this experiment the mixed network mode was enabled and the channel width set to 20MHz. The Broadcom Wi-‐Fi adapter in the receiver can operate with 802.11 b, g or n but 802.11b/g was employed since all smartphone devices can connect to 802.11b/g.

Port Forwarding, QoS Bandwidth management and Client Isolation were not utilized for the throughput & SNR tests in this experiment. Port Forwarding will be useful in the deployed stadium network. Designating a specific port or port range on users’ devices for UDP video will allow the AP to automatically forward the request to the video server. Triggering will allow the AP to monitor outgoing data for specific port numbers allowing the AP to forward requested data to the correct device by way of IP addressing. QoS Bandwidth management will ensure better service for high-‐priority network traffic by granting UDP video data more bandwidth than all other network traffic which ensures application on the user’s device will not slow down. High-‐priority traffic can be determined by the outgoing port or the MAC address of the device. Thus, higher priority can be granted to repeat users who register the MAC address of their device allowing the eStadium team to make sure students and alumni of Georgia Tech always receive the best quality of service in the stadium. Client Isolation will ensure that users on the stadium network will only be communicating with the AP and not with other users.

The transmission rate, fragmentation threshold and MTU will be determined by characterizing the network. By performing throughput measurements, the optimal transmission rate can be determined based on the packet length of the data or the distance the client is from the AP. If the UDP data for video is larger than 1500 bytes, it must be fragmented when sent over the network. Setting the fragmentation threshold will allow the UDP data to be split into equal packet lengths. If an optimal packet length is determined for transmission over the network, the MTU can be set to that value. Moreover, if analysis of the measurements reveals that a large packet length does not transmit optimally over the network, the MTU can be lowered to provide better throughput.

Table 2. Important firmware capabilities unique to DD-‐WRT

7

Ad-‐hoc Mode The AP will be part of an Ad-‐hoc network which does not require the AP be connected to the internet.

Client Mode The AP will act as a client and have the ability to connect to other APs.

JFFS2 Journalling Flash File System allows the admin to have a writable Linux File System on a DD-‐WRT enabled router. The admin can load custom firmware utilizing the built in USB support.

Rflow Graphical traffic monitoring and management. Rx Antenna Output statistics of the receiver gain in dBm. Tx Antenna Output statistics of the sender gain in dBm. SSH server Allows an administrator to remotely access the AP while not on

the internal network by using Secure Sender Shell. Transmit Power Adjustment Set the output gain (dBm) of the transmitting antenna.

The laptops and AP were set up in an ad-‐hoc network when performing the throughput and SNR measurements. When the network is deployed in the stadium, the APs and user devices will be connected in an ad-‐hoc network because none of the APs will be connected directly to the internet. All data from the internet will be collected at the server and then sent to the users through the ad-‐hoc network. This data will include scores and updates from other NCAA football games. All information concerning the GT football games is uploaded to the server on site. Users on the eStadium network will not have direct access to the internet.

With JFFS2 on the AP, with DD-‐WRT, this allows not only access to a network printer or storage, but can have a USB flash drive that can contain special instructions for the AP to run. Also if a new version of DD-‐WRT comes out for the Linksys WRT 160NL the version can be loaded onto the flash drive and the user would never have to worry about flashing the AP again or worry about bricking the AP. The C code can be implemented with the USB flash drive. This is all due to JFFS2 that has more capabilities than the out of the box Linksys WRT 160NL.

Having the capability to adjust the power output on an antenna has advantages and disadvantages. An advantage is to increase the power from 18 dB to 21dB on an omni directional antenna. That would increase the coverage of the signal from the AP. A disadvantage can occur when increasing the power output of the antenna; since there is no limit as to how much output power can be given to the antenna if given too much the AP could overheat and melt components of the AP. Another advantage without the cause of overheating the AP is to have a small power output to the antenna so that the coverage is restricted to a very small area or whatever size the user would like to have coverage bearing in mind the overheating issue.

Methodology

8

The experiment was constructed by placing the AP and the HP laptop (receiver in Figure 3) a distance d apart. The receiver and AP were placed on wooden stools at a height of 29 inches. The receiver and the AP must be elevated to prevent the signal reflection off the ground from affecting the results. At a height of 29 inches there are specific distances where the reflection of the incoming signal will be exactly ½ wavelength off of the incoming signal causing destructive interference. Figure 2 shows the possibility of destructive interference occurring at a distance near 20 ft.

DESTRUCTIVE INTERFERENCE EQUATIONS AND ANALYSIS

It is imperative that the stool contain no metal since the metal can reflect the signal which will skew the results. Figure 3 represents the setup of the experiment with the measurements performed at the three distances of 20ft, 80ft and 140ft.

Figure 2. Destructive interference. L=20ft

H=29 in

9

Line of Sight (LOS) must be maintained between the laptop and AP. For LOS to occur no objects may be present between the AP and laptop. Moreover, it is essential that no objects be within ten feet left or right of the line between the laptop and the AP to maintain LOS. Any objects obstructing the LOS would cause the signal to reflect off of these objects and distort the results.

The throughput measurements were recorded at three distances: d=20ft, 80ft and 140ft. The distances were not selected arbitrarily; they were ascertained by measuring the Signal to Noise Ratio (SNR) every 10ft for 140ft.The SNR is measured in decibels per milliwatt of power or dBm and is ratio of the noise level (dBm) to the signal level (dBm) at the receiver. It is necessary for a significant difference in SNR to exist between the distances where the throughput measurements are acquired. It was determined that 20ft, 80ft, and 140ft each differed by approximately 6dBm, essentially receiving a ¼ the power for every 60ft of distance. After determining the measurement distances, the SNR was monitored for two minutes to verify that it did not fluctuate more than ±3dBm; ensuring that each distance was receiving at a different signal level.

SNR GRAPH

The measurements were obtained by starting the custom C program receiver_u at the receiver and then starting the program sender_ur at the sender. The sender program terminates when 50% throughput occurs causing each test to take approximately 5-‐6 minutes to complete. The tests were repeated five times for each packet length of 100, 300, 900 and

Surge Protector

12 V Battery 500 Watt Inverter

Battery Cart

Figure 3. Experiment Setup.

receiver

Access Point

d= 20, 80 & 140 ft

sender

Cat 5e cable

h=29 in

10

1200 bytes. The packet length was modified in the code sender _ur by setting the len variable. After resetting the packet length, the code was recompiled and executed for another five tests. For more details on the C programs receiver_u and sender_ur and for a copy of the code see Appendix B.

11

Results

SNR

The signal to noise ratio was measured at the beginning and end of each throughput test. An ideal case exists where the receiver receives a signal of constant power yielding no fluctuation in the SNR. However, the ideal case is hard to achieve in a practical measurement scenario. While LOS was maintained in order to minimize interference, external factors such as minor changes in the weather and the surrounding environment can affect the transmitting power of the sender. The SNR at the beginning and end of each 20ft measurement is plotted in Figure 4 along with the average SNR, standard deviation and each test average.

In order to obtain consistent throughput data it is optimal for the SNR to stay consistent for the beginning and end of each test. This occurred in almost half of the tests at 20ft. While the standard deviation was ±1.0767 dBm which represents a change of ±1.28 mW is blah.

SNR GRAPHS for 80 & 140 ft with ANALYSIS

Figure 4. Contains the overall average, test average, and each SNR at the beginning and end of each test.

43.875

40

41

42

43

44

45

46

47

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

SNR (dBm

)

Test Number

SNR @ 20]

Begin End Overall Average Test Average

±1.0767

12

Throughput

The data that was taken was broken up into several parts:

• SNR (signal to noise ratio) at different distances • Data taken at distances 20ft, 80ft and 140ft • Raw packet lengths of 100, 300, 900 and 1200 bytes

The significance of having different distances is needed in order to observe significant change, about 10 dBm. At these distances one can observe if throughput, pkt/sec, and percent loss of packets differs from the theoretical values. The packet lengths were chosen to have a wide range in order to test how the testbed could handle the data. With these different packet lengths it can be seen which length is more efficient in sending/receiving data. A packet length more than 1200 bytes was not chosen due to possible encounter of fragmentation.

Ethernet does not encounter fragmentation until having a packet length more than 1500 bytes; the 1500 bytes includes data and overhead. With the overhead all the packet lengths have 52 bytes added; resulting in 152 bytes, 352 bytes, etc. Wireless fragmentation threshold is 2346 bytes. Even with wireless fragmentation being 2346 bytes the information still gets to the AP and has to break up the packet to 1500 bytes and 898 bytes, to then send the information to the server. When the information comes back through the AP, it can piece the two packets together to send the information back to the wireless user.

Another limit that occurs is a hard limit. This hard limit functions with the AQP only having an Ethernet jack that is 10/100 Mbps instead of 10/100/1000 Mbps. The following graphs reveal that the sender starts to saturate when it tries to send data faster than 100 Mbps.

13

Figure 5. Actual sender speed vs desired speed.

0

20000

40000

60000

80000

100000

120000

140000

sabp

s (Kbp

s)

TBPS (Kbps)

Sabps vs Tbps @ 20]

100

300

900

1200


0

20000

40000

60000

80000

100000

120000

Sabp

s (Kbp

s)

Tbps (Kbps)

Sabps vs Tbps @ 80]

100

300

900

1200

14

In the graph of the sender at 20ft the 900 bytes sending rate going above 100 Mbps is a miscalculation in the code. As can be seen every other packet length no matter the distance starts to saturate when attempting to send over 100 Mbps.

Taking into account all the distances, packet lengths, and attempted data speeds the overall result for the actual sending speed vs the desired sending speed is on the graph below.


0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

sabp

s (Kbp

s)

Tbps (Kbps)

Sabps vs Tbps @ 140]

100

300

900

1200

15

Rabps vs Tbps

Now looking at the receiving end of the experiment we see that the receiver starts to differ from the sender at about 3.2Mbps. This is not bad because in 802.11b the data speed can get up to 11Mbps. As can be seen in the graphs below all distances show the same trend except for the 140ft distance. The separation of the sender speed and the receiver speed starts to occur at about 4x the speed at 20ft and 80ft. This occurrence cannot be explained (I don’t know how to explain this except for code error or something interfering?). As seen when the sender and receiver start to saturate, at about 100Mbps, the difference between the two data speeds are about 1/10th.

In the following graphs are all the packet lengths averaged together at the same distance to see the overall sending and receiving speed compared to the desired sending speed.

Figure 8. Overall sending speed vs desired sending speed.

10

100

1000

10000

100000

Tbps (Kbps)

Sabps vs Tbps Overall

sabps

16

Figure 9. Sending and receiving data speeds vs desired sending speed.

10

100

1000

10000

100000 sabp

s/rabp

s (Kbp

s)

Tbps (Kbps)

Overall Data @ 20]

sabps (all pkt len)

rabps (all pkt len)


10

100

1000

10000

100000

sabp

s/rabp

s (Kbp

s)

Tbps (Kbps)

Overall Data @ 80]

sabps (all pkt len)

rabps (all pkt len)

17

As mentioned above below is now the overall result of the receiver speed compared to the desired speed.


10

100

1000

10000

100000 sabp

s/rabp

s (Kbp

s log scale)

Tbps (Kbps)

Overall Data @ 140]

sabps (all pkt len)

rabps (all pkt len)

Figure 12. Overall receiving speed vs desired receiving speed.

10

100

1000

10000

100000

Tbps (Kbps)

Rabps vs Tbps Overall

rabps

18

Pkt/sec vs Tbps

The meaning behind packet per second (pkt/sec) is to how efficient, essentially throughput, the network is. Calculating pkt/sec is done by the formula below:

Pkt/sec = (Data speed * 1024)/(8 * packet length)

For example: sending a 100 byte packet at a rate of 100 Kbps will yield 129 pkt/sec. Using the information of how many pkt/sec is calculated is independent of distance. That being said we can see how efficient the test bed was compared to the theoretical situation. Given below is a theoretical graph of actual sending rates vs desired sending rates.

Again since determining pkt/sec is independent of distance all the actual sending vs desired sending have the same trend. As well there is a saturation of how many pkt/sec can be sent after trying to send faster than 100Mbps.

Figure 13. Theoretical sending speed vs desired sending speed.

1

10

100

1000

10000

100000

1000000

Tbps (Kbps)

Theoreacal Sabps vs Tbps

100

300

900

1200

19

The rabps pkt/sec vs tbps follows a similar trend to the sabps pkt/sec vs tbps, but since the sabps is over Ethernet and rabps is over wireless the data does vary. As can be seen from both the sabps and rabps pkt/sec that the smaller packets have more sent than the larger packets.

Figure 14. Actual pkt/sec vs desired sending rate.

1

10

100

1000

10000

100000

Tbps (Kbps)

Sabps pkt/sec vs Tbps @ 20]

100

300

900

1200

Figure 15. Receiver pkt/sec at a distance of 20ft.

1

10

100

1000

10000

100000

Tbps (Kbps)

Rabps pkt/sec vs Tbps @ 20]

100

300

900

1200

20


1

10

100

1000

10000

Tbps (Kbps)


100

300

900

1200


1

10

100

1000

10000

100000

Tbps (Kbps)


100

300

900

1200

21

Conclusions

The goals of flashing the APs with DD-‐WRT, making field tests (at Piedmont Park) more efficient by having the battery cart, and not only have a working test bed in the VIP room but as well at Piedmont Park were achieved. Understanding DD-‐WRT does take time to understand all the functionalities that it brings to the table. There are parts of DD-‐WRT that particularly do not apply to our purposes such as VPN, DHCP client and server, EoIP Tunneling. As stated above in the design specifications there are parts that DD-‐WRT does have that are important to the wireless sub team.

The resulting data given above in the results section does behave as expected. There are a couple things to note. One is Shannon’s Theorem states that from the SNR and the analog channel used (2412 MHz) the yielding BW should be in the range of 3.6-‐5.4Gbps. We do not see that in the resulting data due to 1) the AP has a hard limit of 10/100Mbps and 2) the sender laptop has a limit of 10/100/1000Mbps. Another thing to note is that the receiver’s data differs from the sender’s data due to the lack of a wired connection.

Shortcomings

There are a few issues that become problematic with the experiment. These issues are:

• Amount of time to collect data o Each test takes about 5-‐7 minutes (about 10 tests every hour)

• Battery cart can only handle 1 laptop and the AP at the same time • Processing and analyzing the data

These are problems come the Fall semester and each Fall semester on out that need to be addressed and fixed because of the time between each home football game. With a team of two it is difficult process and analyze the data before the next football game to see if any modifications are needed to done to the network. Also there is a “time limit” as to going out to Piedmont Park and run tests. When the battery of the receiver laptop is low there needs to be an extension cord to run out to the laptop to have the battery charged. Charging the laptop does affect the life of the battery.

Future Improvements and Recommendations

The following are solutions to the issues stated above. The solutions are:

• Change response time of code to take data every 5ms instead of 10ms • MATLAB code for processing data

22

• Increasing the AP CPU frequency

The response time was changed so that each test was reduced from 10-‐14 minutes to 5-‐7 minutes, but 5-‐7 minutes is still a long time when running several tests. MATLAB code is being written to organize and graph the data. This will help with the tremendous amount of time it takes to organize and graph the data in excel. It will give the wireless sub team more time to analyze the data to recognize what is happening during game day. It will also give more time to make any changes before game day to see if those changes affect the network.

Increasing the CPU’s frequency of the AP could help process more data faster and essentially have more pkt/sec. This will be implemented carefully as to an issue that reoccurs with using DD-‐WRT, overheating.

23

Appendix A

Step-by-step Checklist to Flash DD-WRT onto a Router Pepe Fundora Santiago Hässig Chris Holmes May 26, 2010 Last Revised: June 4, 2010 15:22

1. Downloading DD-WRT Firmware a. Open folder and name it “Firmware” b. Go to http://www.dd-wrt.com/site/support/router-database and type

“WRT160NL” in the search field i. Download “linksys-to-ddwrt-firmware.bin” and save under folder

ii. Download “wrt160nl-firmware.bin” and save under folder 2. (Optional) Confirm a good download by comparing the MD5 hash fingerprint of the firmware

we downloaded with the published checksum a. If using Linux,

i. Open Terminal and type: /usr/bin/openssl md5 /path/to/firmware.bin

ii. Look at the MD5 hash value and compare it to the one shown in http://www.dd-wrt.com/wiki/index.php/Hashes_%26_Checksums

iii. DO NOT flash the firmware until you can verify that the hash is correct! b. Using Windows

i. We can download HashTab (http://beeblebrox.org/hashtab/) ii. Once downloaded, right-click on the downloaded firmware file,

go to Properties > File Hashes tab. c. Look at the MD5 hash value and compare it to the one shown in http://www.dd-

wrt.com/wiki/index.php/Hashes_%26_Checksums 3. Flashing “Killer” with Web GUI

a. Log into the GUI i. To use the Web interface, you will need to have Javascript enabled with any

security restrictions disabled. Use Internet Explorer, preferably. ii. Type in the IP address of the router (typically, the default is 192.168.1.1,

especially with Linksys) into the address bar of your browser. iii. You will be prompted for username and password (If your router already has a

DD-WRT versions starting with 2006-Feb-28, the default username is root. Prior versions have a blank username by default. For Linksys firmware, the default username can be left blank or set to anything. For both DD-WRT and Linksys firmware, the default password is admin. Search online for other defaults on other routers).

b. Upload the “Killer” Firmware i. Do a hard reset aka 30/30/30.

ii. Go to Web GUI.

24

iii. Click the “Administration” tab.

25

iv. Click the "Firmware Upgrade" sub-tab. v. Click the "Browse" button and select the “linksys-to-ddwrt-firmware.bin” file

you downloaded and confirmed.

26

vi. Click the "Upgrade" button. vii. The router will take a few minutes to upload the file and flash the firmware.

During this time, the power light will flash. viii. A new page will open confirming that the upload was successful

(Installation#Possible errors if not). Now wait about 5 minutes before clicking "Continue".

ix. Lastly, do another hard reset on the unit. x. If flashed successfully you will now be able to access the DD-WRT web

interface at 192.168.1.1 xi. You will be prompted to change the username and password. For simplicity sake

we used root as the username and password.

c. NOTE: Hard reset

i. Hard reset ONLY after you have confirmed that the firmware upgrade is working. At this point you may have temporary problems using Web Interface, so just ping your router.

ii. Many Web Interface problems can be solved by a hard reset and by clearing your browser cache.

4. Flashing 2nd set Firmware with Web GUI a. You do not have to do a hard reset because you just did one. b. Go to the GUI of the router. c. Click the "Administration" tab.

27

d. Click the "Firmware Upgrade" sub-tab. e. Choose the option to Reset to Defaults after flashing.

28

f. Click the "Browse" button and select the “wrt160nl-firmware.bin” file you downloaded and confirmed.

g. Click the "Upgrade" button. h. The router will take a few minutes to upload the file and flash the firmware. During this

time, the power light will flash.

29

i. A new page will open confirming that the upload was successful (Installation#Possible errors if not). Now wait about 5 minutes before clicking "Continue".

j. Lastly, do another hard reset on the unit. k. If flashed successfully you will now be able to access the DD-WRT web interface at

192.168.1.1 l. You will again be prompted to change the username and password. Have the username

be estadium and password e$tad465.

30

5. Troubleshooting steps: Possible Errors with Uploading Firmware a. After initially attempting the install of the "kill" file for the WRT160NL, the browser

may keep providing an error message. Referencing to the peacock thread shows that pinging the router and receiving a TTL of 100 means that, while the router may appear bricked, it is ready for the installation of the dd-wrt .bin file for the WRT160NL. Using the tftp.exe discussed in the peacock thread may help. Again, the best method is to look first at your hardware-specific guidelines and refer to those instructions, keeping in mind the precautions outlined above.

b. During the firmware upload process, if your router says something similar to, "Upload Failed," you may be using the wrong version of DD-WRT. This may occur through the web GUI if you use a *wrt54g.bin version when you should have selected the generic version instead. It may also be that you failed to flash the router with the mini version (TCP Kill) first before you flashed the full version. Make sure you have the correct version. Note: You may simply need to use a different web browser (e.g. from Firefox to Internet Explorer, from Safari to Internet Explorer, etc).

c. After clicking Upgrade when upgrading firmware from one DD-WRT version to another, if you are using Firefox there may be a problem with the upload. In this instance the screen fades to white with a countdown timer and is followed by a Connection Reset message shortly after. After this you cannot access the Web GUI again, and a router reboot will result in a flashing power light (WRT54GL is the case in point). You can recover from this and use a different browser (e.g. Internet Explorer) to upload the firmware.

d. If logging in fails with the default username/password, you can reset the password with a reset and reboot.

31

Appendix B

UDP Packet Transmission Test

Written by Seksan Laitrakun

The objective of the UDP packet transmission test is to experimentally measure the characteristics of a (possibly wireless) network using UDP packets sent between two laptops (or other IP hosts).. The throughput, packet delay, and packet loss are recorded during the test. These values

measure how well the wireless channel can support the packet transmission in that location. The result will be used in network planning and design such that the quality of the service will be satisfied.

The UDP packet transmission test consists of two programs, sender_ur.c and receiver_u.c, which were originally written by Dr. Randal T. Abler, and modified by the former and current Wireless subteam

members. Each program will be stored in a laptop and run at the same time.

Conceptually the program reports three bit rates. The first bit rate is the desired bit rate (called tbps), it is used as an input parameter into a Poisson distributed random interval calculation. Randomizing the interval, rather than sending at a periodic rate, creates traffic bursts more typical of

network behavior. The second bit rate is the actual bit rate sent (called sbps), as measured by the sender, i.e., actual sender bit rate. This varies from the desired sending bit rate based on several factors including:

• Statistical variation due to the Poisson interval • Quantitization of timing intervals inherent in the Linux • Inability of the sender to keep up with the desired rate due to CPU, O.S., or physical

output rate of the network interface • Complexities in determining the exact header size for UDP/IP/Ethernet/Wifi

Third, the received bit rate (called rbps) is measured at the receiver. The receiver bit rate varies from the sender bit rate based on:

• Lost packets (ideally on average: sent = lost + received) • Quantitization of timing intervals on the receiver • Statistical variation due to the Poisson distribution traffic.

Lets call the laptop running the program sender_ur.c as the sender and the other running the

program receiver_u.c as the receiver. The test starts with calling the program receiver_u.c first and then calling the program sender_ur.c at the sender. During the test, the sender will periodically send a packet with the data length len and the desired sender bit rate bps bits per second. Using the program

32

receiver_u.c, the receiver will count the arriving packets, record the arriving time, and check the packet loss. After an assigned time duration, the receiver will report these statistics (the measured values) back

to the sender. Upon the report, the sender will show the statistics measured from both sides, sender and receiver, on the screen in the pattern below,

tbps sbps sabps milli read missed % pkt/sec rbps rabps

where

• tbps is the desired sender bit rate. It is used as a parameter in a statistical calculation that attempts to provide some randomized transmission behavior. During the test, tbps will be doubled after a particular time interval.

• sbps, measured at the sender, is the actual sender bit rate. The value shows the number of bits including the header that are actually sent per second. It increases as increasing tbps. However, since sbps represents the actual sending bit rate of the host, there is a limit number, an upper bound, that sbps cannot exceed.

• sabps, measured at the sender, is the actual sender “data” rate. The value shows the number of bits, excluding the header, sent per second. sabps is less than sbps.

• milli, measured at the receiver, is the time duration measured at the receiver. It is the time duration used to calculate the current statistics. (Unit: millisecond)

• read, measured at the receiver, is the number of packets arriving at the receiver during the time duration milli. (Unit: packet)

• missed, measured at the receiver, is the number of packets lost during the time duration milli. (Unit: packet)

• %, measured at the receiver, is the ratio between the arriving packets and total sending packets during the time duration milli. (Unit: percent)

• pkt/sec, measured at the receiver, is the number of packets per second. • rbps, measured at the receiver, is the actual receiver bit rate inclusive of headers. The value

shows the number of bits (including the header) is received per second. In average, it must follow the equation,

data loss rate = actual sender rate – actual receiver rate.

• rabps, measured at the receiver, is the actual receiver “data” rate. The value shows the number of bits excluding the header is received per second.

The appendix is organized as follows. Part A and Part B explain the program sender_ur.c and receiver_u.c, respectively. The source codes of the programs are shown in Part C and D.

A. The explanation of the program sender_ur.c

33

The program sender_ur.c consists of the function main and three sub-‐functions, which are explained below.

1) Function main The flowchart of the function main is shown in Figure A.1. The sender starts sending

packets with the desired bit rate equal to INITIALBPS. The number of packets that has to be sent is computed and equal to (RUNTIME * desired sender bit rate)/(8 * (len+52)), where RUNTIME is the time duration for testing the current desired bit rate (here is 20 milliseconds), len (bytes) is

the data length, and 52 (bytes) is the header length. After that, the program enters the while loop to send a packet after a random delay interval which is computed by the sub-‐function possion_wait. During that time, the sender will periodically check whether the receiver has

reported the statistics back. When getting the report, the sender will immediately show the statistics through the sub-‐function printstats. The sender will stop the test at this desired sender bit rate when the number of sent packets exceeds the threshold stored in the variable

count, (see this line on the program, “while (i<=count)||notprint)”). The variable notprint is used to make sure that the statistics will be shown before the program will finish the test for this desired sender bit rate. Thereafter, the program will double the desired sender bit rate, and

the process repeats again. The program will end the test whenever the desired bit rate is more than four times of the actual sender bit rate. In this case, it likely implies that the actual sender bit rate reaches the upper bound, i.e., it cannot increase anymore.

The meanings of the variables are as follows.

• bps is the desired sender bit rate. • count=countcalc is the total required number of packets to be sent for this desired

sender bit rate. • i is both a counting variable and the packet sequence number. • print_interval is the time interval measured between the time getting previous

report and the time getting the current report. (Unit: seconds) • bytes_sent is the number of bytes including the header sent during this time interval

print_interval. • bytes_datasent is the number of bytes excluding the header sent during this time

interval print_interval. • statrep.sendbw is the actual sender bit rate. • sendbw_app is the actual sender data rate.

34

Figure A.1: The flowchart of the function main.

35

2) Sub-‐function printstats The sub-‐function printstats uses the inputs (sr,bps,pklen,sendbw_app) to compute and

show the statistics on the screen.

The meanings of the variables are as follows.

• sr-‐>sendbw is the actual sender bit rate. • sendbw_app is the actual sender data rate. • sr-‐>milli is the time interval used to collect the statistics for this desired sender bit

rate. (Unit: millisecond) • sr-‐>intrd is the number of packets arriving the receiver during this time interval sr-‐

>milli. (Unit: packet) • sr-‐>rdmissed is the number of packets lost during this time interval sr-‐>milli. (Unit:

packet) • sr-‐>tbrd is the total number of bytes including the header received at the receiver

during this time interval sr-‐>milli. (Unit: byte) • sr-‐>tdata is the total number of bytes excluding the header received at the receiver

during this time interval sr-‐>milli. (Unit: byte)

3) Sub-‐function poisson_interarrival The sub-‐function poisson_interarrival computes the time interval t for sending one

packet in order to satisfy the desired sender bit rate. The time interval t guarantees statistically that the intervals between packets follow Poison distribution.

4) Sub-‐function possion_wait The sub-‐function possion_wait takes care of the waiting time that the sender will be

able to send the next packet. Figure A.2 shows an example of the timeline when packets are sent. During a random time interval waitd, the sender will send only one packet and wait for the next interval. The value waitd is computed from the sub-‐function poisson_interarrival. The

time t1 is the beginning of the current interval, which is also the end of the previous interval. Similarly, t4 is the beginning of the next interval and the end of the current interval. However, there is a gap that the packet cannot be sent until the time t2, which will be explained later. The

sending ends at the time t3. After that, the sender will alternatively sleep and wake up until the time t5 to send a packet again. The process is repeated in this way. More details are be explained. In addition, Part i) and Part ii) in the figures mean that the explanations are in i) and

ii) below.

36

Figure A.2: A timeline of sending packets.

Lets consider the details in the program sender_ur.c. The time t2 is the time when the program call

n=sendto(sendfd,sendbuf,len,0,…….....................……..);

which means the sender is sending the packet. The program will return from this command at the time t3, which finishes sending. After that the program enters the sub-‐function

possion_wait and stays there until the time t5. When the program is back to the function main, it will check whether there is a report from the receiver (this takes a little time) and then it will call the command n=sendto(……) to send a new packet again.

Within the sub-‐function possion_wait, the program computes waitd and adds it to the

time t1 (which is stored in the variables last_sec and last_usec), to estimate the time t4 (which is the expected beginning of the next interval). The program will repeatedly check whether the time has passed the time t4 yet by computing the difference between the current time and the

expected time t4. This different value is stored in the variable howmuchlonger (= t4 – the current time). There are two conditions on how the sender waits until the time t4.

i) When howmuchlonger is larger than 11 milliseconds. In this case, the value of howmuchlonger indicates that the current time is still far from the time t4. As a result, the sender will use the command usleep(10000) to sleep for 10 milliseconds. See the following line in the program:

if (howmuchlonger > 0.011) usleep(10000);

For example, consider Figure A.2. After the sender finishes sending the current packet at the time t3, it will compute howmuchlonger h1. Supposed that h1 is larger than 11 milliseconds, the sender will sleep for 10 milliseconds, and then wake up at

the time x2. Again, it will compute howmuchlonger h2, and goes to sleep since h2 is still larger than 11 milliseconds. However, when computing howmuchlonger h3 at the time x3, since h3 is less than 11 milliseconds, the sender knows that the current

time is close to the time t4. In this case, the sender will not go to sleep anymore.

37

ii) When howmuchlonger is less than or equal to 11 milliseconds. In this case, the value of howmuchlonger indicates that the current time is close to the expected time t4. As a result, the sender keeps waking up by running the do loop. However, the variable howmuchlonger will be ready at a particular discrete time due to the fact that any command called in the do loop needs an amount of time to operate. As shown in Figure A.2, the sender will have the values of howmuchlonger h4, h5, and h6 at the times x4, x5, and x6, respectively. On the other hand, we can say that the sender can only check on how much the current time is close to the expected time t4 at the discrete times x4, x5, and x6. Due to the do loop’s condition:

do {………………………….} while (howmuchlonger > 0.0);

the sender will still be in the do loop after the time x4 and x5 because h4 and h5 are larger than 0. Finally, since h6 is now less than 0, the sender knows that it has just passed the desired time t4. Then, the sender finishes waiting for the next time

interval to send the next packet by exiting the do loop. Note that due to howmuchlonger is computed at a particular discrete time, it is unlikely that we will have howmuchlonger=0, which the new packet will be sent at the expected time t4.

Therefore, due to the condition of the do loop above, there is always a gap between t4 and t5.

Thereafter, the sender will update the time t4 (=t5 + howmuchlonger), which will represent the beginning of the new duration, and keep it in the variables last_sec and last_usec before

returning to the main function. Note that the values waitd and howmuchlonger are varied from time to time.

5) Comments • Before running the program make sure that the variables RUNTIME, INITIALBPS, and len

have been set. Originally, they are 20, 100000, and 100, respectively. • The sequence number of the packet is increased by one and is back to the number 1

whenever the sender doubles the desired sender bit rate. • The criterion to still running the function main (i.e., to still in the loop do) is

do { ………………………. } while (old_bps < (4*statrep.sendbw)).

However, there might be more suitable criteria to stop the program, which exactly depend on the situations. One criterion, which was used in the previous version, is

do {………………………..} while (statrep.rdmissed < statrep.rdbuf/2),

i.e., stop the program when the packet loss is more than 50%.

• The value shown by the line (third line from the bottom) fprintf(stderr, “Approx %f bits/sec\n”, ………………………

seems incorrect. It uses the variables count and totaldelay. However, the variable count is the number of packets has been sent during the time duration between previous report and

38

the latest report, while the variable totaldelay is the total time duration from starting until ending the whole test.

• In the sub-‐function possion_wait, the condition to exit the do loop is howmuchlonger<0. However, this condition can be changed such that howmuchlonger is less than a small positive value, e.g., 0.001.

• For a particular report shown on the screen, the observation time interval at the sender is larger than that at the receiver, i.e., print_interval>=statrep.milli. This is because the variable print_interval is measured (at the sender) from the time when a packet is sent up to the time when the report is fed back. On the other hand, the variable statrep.milli is measured (at the receiver) from that packet arriving until feeding back the report. Therefore, the time difference is at least 2 * propagation delay. Similarly, the number of packets observed at the sender is more than that at the receiver. However, statistically, this makes no error on the values sbps, sabps, rbps, and rabps.

• Consider Figure A.2. When the desired sender bit rate increases, the difference between t3 and t4 will be smaller. Until a particular desired sender bit rate, t3 will be larger than t4. As a result, the program sender_ur.c cannot preserve its sending rate as a Poisson distribution anymore.

39

B. The explanation of the program receiver_u.c The program receiver_u.c begins with a series of socket setup. After that, the measured statistics are dealt within the loop for,

for (x=0; x<2000000000; x++) {…………………………..}.

In this loop, the receiver will do the following subsequently.

1) When a packet arrives, the receiver will check whether there is an error in the packet or not. If not, the receiver will extract its sequence number and store in the variable rdbuf. This description is performed in

if (bytesrd<4) {…………..……………} else {………….………………}.

2) The receiver will check whether the sender sent a packet with a new desired sender bit rate. This is important since otherwise the set of the current measured statistics might consist of the packets from both the previous and current sender bit rates, and, as a result, these statistics are useless. When the receiver finds that the current arriving packet is due to the new sender bit rate (i.e., the sequence number is back to the number 1), it will delete all ongoing recorded statistics (which are not yet reported to the sender) and starts a new record. This description is performed in

if ((rdbuf<last_rdbuf)&&(check_newset)) {……………………………...}.

The variable last_rdbuf stores the sequence number of the last packet in the previous report (the statistics sent to the sender). The variable check_newset is set to TRUE whenever the

report is sent. Since rd_buf normally increases, the condition ((rdbuf<last_rdbuf)&&(check_newset)) is mostly false. There are two possibilities that this condition ((rdbuf<last_rdbuf)&&(check_newset)) will be true. First, a series of arriving packets

around the time that the receiver is reporting back to the sender is out of order, which in this case the variable check_newset also just has been set to TRUE. This case is unlikely to happen. Second, there is a packet with the sequence number 1 arriving (indicating the new sender bit

rate has been used), which is the case we want.

3) The receiver will check whether the sequence number of the arriving packet is equal to the previous sequence number (i.e., intprev) plus one. If it is true, there is no packet lost; otherwise, the number of the packets lost is equal to the number of the missing sequence values. This description is performed in

if (rdbuf==intprev+1) {…….….………...….} else {…….….……….…..}.

4) The receiver will check the time duration, which has been used for measuring the current statistics, every 20 arriving packets (lpcnt). The value 20 is chosen such that it is not so often to call the function gettimeofday, which will increase the CPU load, but is fine enough to preserve the variable milli around 5 seconds.

5) When recording the current statistics for 5 seconds, the receiver will report these statistics to the sender. This description is performed in

if (milli>5000) {………………………………………….}.

Otherwise, the receiver will wait for a new arriving packet. And the process repeats again.

40

6) Comments • In this program, we assume that all packets arrive at the receiver in order. Whenever the

out of order happens, the program will account it as packet loss. Therefore, this program still does not deal the packet loss accurately. However, so far, the situation that the packets arrive out of order is rare. This might need improvement.

• The statistics will be reported every 5 seconds. The value can be changed. • The number 52 (bytes) used in the program is the header length. It might not be yet

correct. 7) Some variable meanings

• bytesrd is the packet length, which is equal to the value of the variable len in the sender. (Unit: byte)

• rdbuf is the current arriving packet sequence number. • milli is the time interval used to collect the statistics for the current report. (Unit:

millisecond) • tdata is the total bytes received during the current report. • tbrd is the total bytes (including the header) received during the current report. • intrd is the number of received packets during the current report. • intprev is the previous arriving packet sequence number.

C. The source code of the program sender_ur.c

#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/ip.h> #include <stdlib.h> #include <stdio.h> #include <strings.h> #include <string.h> #include <errno.h> #include <math.h> #include <netdb.h> #include <asm/param.h> #include "statrep.h" /* Secs to run at each rate, used to compute number of packets to send */ #define FALSE 0 #define TRUE !FALSE #define RUNTIME 20.0 #define INITIALBPS 100000 /* Dumps stats as rcvd by the receiver and sent back to us via the TCP socket */ printstats(sr,bps,pktlen,sendbw_app) struct statrep_strct *sr; int bps; int pktlen; double sendbw_app;

41

{ //printf("tbps(kb/s)\tsbps(kb/s)\tsabps(kb/s)\t\tmilli\t\tread\t\tmissed\t%\tpkt/sec\t\trbps(kb/s)\t\trabps(kb/s)\n"); printf("%8d %11.3f %11.3f %6d %7d %7d ",bps/1000,sr->sendbw/1000,sendbw_app/1000,sr->milli,sr->intrd,sr->rdmissed); printf("%8.2f %11.2f %11.3f %11.3f\n",100.0*sr->intrd/(sr->intrd+sr->rdmissed), sr->intrd*1000.0/sr->milli,sr->tbrd*8.0/sr->milli,sr->tdata*8.0/sr->milli); } /* bps is desired average bits per second */ /* s is packet size in bits */ /* bps and s should be non-zero */ double poisson_interarrival(bps, s) double bps; double s; { double t; double r; do { r=drand48(); } while (r == 0.0); t = - s * log(r)/bps; //(original --> correct) return(t); } /* poisson wait routine, waits a random amount of time since it was previously called */ /* before returning. It tries to do this efficiently (using usleep) */ /* but may busy-wait for small time intervals */ double possion_wait(bps,s) double bps,s; { static int last_sec=0, last_usec=0; int sec,usec, now_sec, now_usec,usc, kk, xlast_usec; struct timeval timereturn; double waitd,howmuchlonger; waitd=poisson_interarrival(bps,s); /* how long to wait since last call */ do { gettimeofday(&timereturn,NULL); /*convert current time to secs & microsecs */ now_sec = (int) timereturn.tv_sec; now_usec = (int) timereturn.tv_usec; /* initialize last_sec & last_usec if this is the first time this is called */ if((last_sec==0) && (last_usec==0)) { last_sec=now_sec; last_usec=now_usec; } howmuchlonger = waitd - ((double)(now_sec-last_sec) + (double)(now_usec-last_usec)/1000000.0); if(howmuchlonger >0.011) usleep(10000); /* Sleep if we need to wait > 10 millisec */ } while (howmuchlonger > 0.0); //if(howmuchlonger <-0.0200) fprintf(stderr,"Can't keep up: %f\n",howmuchlonger); //***** Modification starts from here. There are two parts: a) and b)************** last_sec = now_sec; // *** a) Add howmuchlonger to the now_usec. Note that howmuchlonger is negative.

42

last_usec = (now_usec + (int)(howmuchlonger*1000000)); // *** b) Check whether last_usec is less than 0 or not. And correct it. //If the last_usec is a negative value, we need to decrease last_sec by 1 at a time and adjust last_usec backwards by add 1000000. //Range of last_usec and now_usec is between 0 and 999999 in the unit of microsecond. while (last_usec < 0) { last_sec = last_sec - 1; last_usec = 1000000 + last_usec; } //***** Modification ends here. **************************************************** return(waitd); } main(argc,argv) int argc; char **argv; { int sendfd,datafd; int notprint; int old_i,i,n,port,len,bps,count,old_bps; int secp,usecp,osecp,ousecp,bytes_sent,bytes_datasent; struct sockaddr_in sendsock; struct sockaddr_in datasock; struct hostent *hostlookup; struct statrep_strct statrep; struct timeval timeret; char sendbuf[1500],destaddr[100]; int netaddr; double totaldelay=0; double countcalc,print_interval,sendbw_app; if(argc != 2) { fprintf(stderr,"Usage: sender_ur <host_IP>\n"); exit(1); } bzero(&sendsock,sizeof(sendsock)); fprintf(stderr,"HZ = %i\n",HZ); /* Configure address */ if (argc>1) { hostlookup = gethostbyname(argv[1]); fprintf(stderr,"Official name = %s\n",hostlookup->h_name); fprintf(stderr," # addresses = %i\n",hostlookup->h_length); netaddr = *(int *)hostlookup->h_addr; } else { inet_pton(AF_INET,"127.0.0.1",&netaddr); } fprintf(stderr," dest address = %s\n",inet_ntop(AF_INET,&netaddr,destaddr,100)); /* Configure Port number */ port = 2867; fprintf(stderr,"Port %i\n",port);

43

/* Configure Length of packet */ len=100; fprintf(stderr,"Len = %i (data) + 20 (IP) + 8 (UDP) + 24 (L2) = %i\n",len,len+52); /* Configure Initial bps */ bps = INITIALBPS; fprintf(stderr,"Initial BPS %i\n, kbytes/sec %f\n",bps,(double)bps/8000.0); fprintf(stderr,"Initializing UDP sender socket\n"); sendsock.sin_family = AF_INET; sendsock.sin_port = htons(port); sendsock.sin_addr.s_addr = (u_int32_t) netaddr; fprintf(stderr,"opening stuff\n"); if(-1 == (sendfd = socket(AF_INET,SOCK_DGRAM,0))) { perror("socket "); fprintf(stderr,"socket() call failed\n"); exit(1); } fprintf(stderr,"Initializing TCP sender socket\n"); datasock.sin_family = AF_INET; datasock.sin_port = htons(port); datasock.sin_addr.s_addr = (u_int32_t) netaddr; if(-1==(datafd=socket(AF_INET,SOCK_STREAM,0))) { perror("tcp socket "); fprintf(stderr,"socket() call failed\n"); exit(1); } if(0 != connect(datafd,(struct sockaddr *) &datasock,sizeof(datasock)) ) { perror("tcp connect "); fprintf(stderr,"connect failed!\n"); exit(1); } do { //fprintf(stderr,"sockets open, Begin writing\n"); /* Configure count of packets to send */ countcalc = RUNTIME * bps; countcalc = countcalc/(8*(len+52)); count = countcalc; old_i = i=0; /*Seq is reset when the rate is double /* Loop until count pkts have been sent, then keep going until the next datarate report is received */ while( (i<=count) || notprint) { notprint = TRUE; i++; *((int *)sendbuf) = i; n=sendto(sendfd,sendbuf,len,0,(struct sockaddr *)&sendsock,sizeof(struct sockaddr_in)); if(n!=len) fprintf(stderr,"write returned n=%d\n",n); totaldelay += possion_wait( (double)bps, (double)(8*(len+52)) ); n=recv(datafd,&statrep,sizeof(statrep),MSG_DONTWAIT); if((n != 0) && (n != -1)) { if(n==sizeof(statrep)) { gettimeofday(&timeret,NULL); /*convert current time to secs & microsecs */ secp = (int) timeret.tv_sec; usecp = (int) timeret.tv_usec; print_interval = (secp - osecp)+ (usecp-ousecp)/1000000.0; bytes_sent = (len+52) *(i-old_i);

44

bytes_datasent = len * (i-old_i); //Bytes of application data packet. old_i = i; statrep.sendbw = 8.0 * bytes_sent / print_interval; sendbw_app = 8.0 * bytes_datasent / print_interval; //Data bit rate printstats(&statrep,bps,len,sendbw_app); //printf("**************** Last send rdbuf: %d\n",i); osecp = secp, ousecp = usecp; notprint = FALSE; } else { fprintf(stderr,"rcv'd strange number of bytes (%d) on tcp socket ... ignoring\n",n); } } } old_bps = bps; //Modified: save to be used in while loop below. bps = bps * 2; /* Double the data rate */ } while (old_bps < (4*statrep.sendbw)); /* Keep going till desire sending rate more than 4 times actual sending rate */ fprintf(stderr,"done\n"); fprintf(stderr,"Sent %i packets in %f secs, %f pkt/sec\n",count,totaldelay,(double) count/totaldelay); fprintf(stderr,"Approx %f bits/sec\n", 8.0*(len+52)*(double) count/totaldelay); close(sendfd); }

D. The source code of the program receiver_u.c

#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/ip.h> #include <stdlib.h> #include <stdio.h> #include <strings.h> #include <errno.h> #include <sys/time.h> #include "statrep.h" #define FALSE 0 #define TRUE !FALSE main(argc,argv) int argc; char **argv; { int recfd,rwfd; int datafd,datafd2; unsigned int x,i,n; int lpcnt,bytesrd,intrd,intprev,rdmissed; int totalread; int prev_rdbuf,end_seq, check_newset;

45

int milli,secs; int rdbuf, last_rdbuf; int tdata,tbrd; struct sockaddr_in datasock,sendsock; char sourcename[30]; char rdbufc[1500]; struct timeval now, then; struct timezone tz; struct statrep_strct statrep; bzero(&tz,sizeof(tz)); bzero(&datasock,sizeof(datasock)); bzero(&sendsock,sizeof(sendsock)); fprintf(stderr,"Initializing receiver, port 2867\n"); sendsock.sin_family = AF_INET; sendsock.sin_port = htons(2867); sendsock.sin_addr.s_addr = htonl(INADDR_ANY); fprintf(stderr,"IN_ADDR_ANY = %d\n",INADDR_ANY); fprintf(stderr,"2\n"); fprintf(stderr,"opening stuff\n"); if(-1 == (recfd = socket(AF_INET,SOCK_DGRAM,0))) { perror("socket "); fprintf(stderr,"socket() call failed\n"); exit(1); } n = bind(recfd,(struct sockaddr *)&sendsock,sizeof(sendsock)); if(n !=0 ) { perror("bind:"); exit(1); } fprintf(stderr,"Start the sender to proceed\n"); datasock.sin_family = AF_INET; datasock.sin_port = htons(2867); datasock.sin_addr.s_addr = htonl(INADDR_ANY); fprintf(stderr,"2\n"); fprintf(stderr,"opening stuff\n"); if(-1 == (datafd = socket(AF_INET,SOCK_STREAM,0))) { perror("socket "); fprintf(stderr,"socket() call failed\n"); exit(1); } n = bind(datafd,(struct sockaddr *)&datasock,sizeof(datasock)); if(n !=0 ) { perror("bind:"); exit(1); } n = listen(datafd,1); if( n != 0 ) { perror("listen:"); exit(1); } fprintf(stderr,"Start the sender to proceed\n"); n = sizeof(datasock); datafd2 = accept(datafd,(struct sockaddr *)&datasock,&n); if(datafd2 == -1 ) {

46

perror("accept:"); } intprev = 0; intrd = 0; /* Packets read */ lpcnt = 0; rdmissed = 0; totalread = 0; tbrd = 0; /* Total bytes including assumed L2 Ethernet header */ tdata = 0; /* Total data bytes */ prev_rdbuf = last_rdbuf = 999999999; //end_seq=FALSE; check_newset=TRUE; //gettimeofday(&then,0); for(x = 0; x < 2000000000; x++) { bytesrd = recvfrom(recfd,rdbufc,1500,0,NULL,0); if(bytesrd < 4) { printf("bytes read = %d\n",bytesrd); } else { rdbuf = *(int *)rdbufc; //100 byte array and treat the first 4 bytes as an int -> packet No. //***************************************************************************************** //If the new seq starts (due to the new bps), reset all recorded data but are not yet reported to the sender. //This will happen when the rdbuf is less than last_rdbuff, where last_rdbuff is the last seq num in the recent report //(see around the end of the code below). //To protect the entering to this condition again during the same bps, check_new_set will be set to FALSE, //and be holded until reporting. if ((rdbuf<last_rdbuf) && (check_newset)) { check_newset=FALSE; intprev=lpcnt = rdmissed = intrd = tbrd = tdata = 0; //Set all variables to zero. gettimeofday(&then,0); printf("######### Starting rdbuf of the new data rate: %d\n",rdbuf); } //********************************************************************************************* //Here is the previous part used to check the new set of seq due to new datat rate. // if(rdbuf < prev_rdbuf) { //another new data burst, don't try and print stats for 1st packet // printf("######### Starting rdbuf of the new data rate: %d\n",rdbuf);// // if(rdbuf != 1) printf("starting seq num %d\n",rdbuf); // gettimeofday(&then,0); //first packet enters // if(intrd != 0 ) end_seq=TRUE; // intprev=0; //Reset the previous sequence number to 0 when we double data rate. // }; //********************************************************************************************** prev_rdbuf = rdbuf; tdata += bytesrd; //total # of bytes read. tbrd += bytesrd + 52; //total # of bytes read + packet overhead. lpcnt++; if(rdbuf == intprev+1) { //previous packet = previous packet + 1 then good. intrd++; } else { intrd++; rdmissed += rdbuf - intprev - 1; //to see how many packets missed. } intprev = rdbuf; } if (lpcnt > 20) { /* check the time passed every 20 packets?, or */

47

//to see what time it is after 20 packets for not getting overhead gettimeofday(&now,0); milli = (now.tv_usec - then.tv_usec)/1000; secs = (now.tv_sec - then.tv_sec); milli += secs*1000; lpcnt = 0; /* Modified */ if (milli > 5000) { /* if more than 5 seconds have passed, print stats */ then = now; totalread += intrd; printf("RDBUF: %d\n",rdbuf); printf("Millisecs %d\n",milli); printf("Read %d\n",intrd); printf("TotalRead %d\n",totalread); printf("Missed %d\n",rdmissed); printf("Percent = %f\n",100.0*intrd/(intrd+rdmissed)); printf("Packet Rate (packet/sec) = %f\n",intrd*1000.0/milli); printf("packet (L2) data rate: bytes/sec = %f\n",tbrd*1000.0/milli); printf(" bits/sec = %f\n",tbrd*8000.0/milli); printf("application data rate: bytes/sec = %f\n",tdata*1000.0/milli); printf("********** Last received rdbuf: %d\n",rdbuf); //Just print a line. printf("=================================================\n"); statrep.rdbuf = rdbuf; statrep.milli = milli; statrep.intrd = intrd; statrep.rdmissed = rdmissed; statrep.tbrd = tbrd; statrep.tdata = tdata; //sending stats to the sender to see if there is a 50% data loss if(1 > write(datafd2,&statrep,sizeof(statrep))) { fprintf(stderr, "Write failed\n"); perror("write"); } lpcnt = rdmissed = intrd = tbrd = tdata = 0; check_newset=TRUE; last_rdbuf=rdbuf; //end_seq=FALSE; } } } }

throughput)&snr)infreespace:) applied)to)thedesign)of...

Documents