Stephen Fry

"Education is the sum of what students teach each other in between lectures and seminars. " - Stephen Fry
Showing posts with label android. Show all posts
Showing posts with label android. Show all posts

Thursday, 23 August 2012

Notes on "A Close Examination of Performance and Power Characteristics of 4G LTE Networks"! - Pt1

 These are my notes on "A Close Examination of Performance and Power
Characteristics of 4G LTE Networks" which can be found here

4G is as the name suggests, the forth generation of mobile communication standards. There are currently two competing technologies, Mobile WiMAX and LTE. Long term evolution (LTE) is the technology that this paper considers.

4G Test Android Application

The team designed an android application called 4GTest. It is available in the Play store here. The application measures the network performance including latency, download speed and upload speed.

The application description claim that the results produced by this application are more accurate that any other test using single-threaded TCP tests.     

I tested the application on an old HTC Magic but I couldn't get the application to recognize my internet connection. The application is not compatible with the Nexus 7.  

Overall Results/ Conclusions

The abstract states that "LTE generally has significantly higher downlink and uplink throughput than 3G and even WiFi, with a median value of 13Mbps and 6Mbps, respectively". I am not sure why the median value has been quoted here instead of the mean value (if you know why, please comment below).

The data set for the study was 20 smart phone users over 5 months, this seems like a fairly limited sample size.

The power model of the LTE network, had a less than 6% error rate. It was found that LTE was less power efficient than WiFi and 3G. Testing of android applications highlighted that the device power is now becoming a bottleneck, instead of network performance, compared to 3G.

Long term evolution
LTE aims to enhance the Universal Terrestrial Radio Access Network, more commonly known as 3G. LTE is commercially avaliable but is not yet wide spread. The targeted user throughput is 100Mbps for downlink and 50Mbps for uplink. These targets are distinctly different to median values of 13Mbps and 6Mbps, respectively previously quoted. 

User-plane latency is defined as the one-way transit time between the availability of a packet at the IP layer (the network layer) at the source and the availability of this packet at the IP layer (the network layer) at the destination. This definition means that user-plane latency includes the delay introduced by associated protocols. Since the delay is measured from network layer to network layer, we do not need to consider the delay introduced by the application layer or transport layer.

LTE can be compared to other networks such as Wi-FI and 3G by comparing network statistic such as bit rate, latency, user equipment (UE) power saving etc..

LTE uses Orthogonal Frequency Division Multiplex (OFDM) technology.
OFDM is based on FDM, but FDM wastes bandwidth as you need to leave bandwidth free between different carriers to stop the signals from interfering with each other. OFDM allows the carriers to be more closely spaced together so less bandwidth is wasted.

But OFDM is less power efficient as its more complex and requires linear amplification. To save power, LTE up ink uses a special implementation of OFDM called SC-FDMC.

Discontinuous reception (DRX) is also employed to reduce UE power consumption by some existing mobile technologies. LTE supports DRX. DRX is configured on a per UE basis and allows tradeoff to be made between power saving, delay and signalling overhead.

This study differs from previous ones since it doesn’t use either total on time or simplified LTE. Furthermore it uses real user traces instead of synthetic packets. UMICH refers to the real user data set of 20 smartphone users over 5 months, this data consists of user traces from Wi-Fi and 3G networks but not from LTE networks. So instead Wi-Fi traces are feed into the LTE model simulation framework, Wi-Fi traces were chosen over 3G as the RRT of Wi-Fi is more similar to that of LTE than 3G.

The study shows that LTE is less power efficient than WiFi and 3G for small data transfers but for bulk data transfers LTE is more power efficient than 3G but not Wi-Fi. Because LTE is more efficient than 3G for bulk data transfer then its important to make us of application tools such as Application Resource Optimizer (ARO) (MobiSys11 demo here) in LTE.

LTE is less power efficient than WiFi and 3G, even when DRX was used.

In LTE, the tail timer is the key parameter in determining the trade off between UE energy usage, performance and signalling overhead.

The study identified performance bottlenecks for android applications caused by device processing power, this is detected by monitoring CPU usage of application on the android devices.

Background on Radio Resource Control (RRC) and Discontinuous Reception (DRX) in LTE

Radio Resource Control (RRC) is a signalling protocol between user equipment (UE) and the 3G network (or 4G in this case). Long term evolution (LTE) has two RRC states: connected and idle. The transition from RRC-connected to RRC-idle is made when no data have been received/sent in a time peroid. The transition from RRC-idle to RRC-connection is made when some data is received/sent

Discontinuous Reception (DRX) is a used in mobile communication to conserve power. The UE and the network (in this case LTE) decide on phases when data transfer occurs, outside of these phases the network reciever on the mobile device is turned off thus consuming less energy.

For example. in 802.11 wireless networks, polling is used to control DRX. The mobile device is placed into standby for a set time interval and then a message is sent by the access point to indicate if there is any waiting data, if not then it is placed in standby again.

When LTE is RRC-connected state, then the UE can be in continuous reception, short DRX or long DRX. When LTE is RRC-idle, then the UE is only in DRX mode. Long DRX and short DRX are cycles of the receiver being on and off. The receiver is off for longer in long DRX, which increases delay but reduces emergy consuption. The receiver is on for longer in short DRX, which increases energy consuption but reduces deley. The parameters which dictate the length of time before various transitions, controls the trade-off between battery saving and latency.

Network Measurement
The android application designed to collect test data was called 4GTest and allows the user to switch between 3G, WiFI and LTE. The application made use of M-lab support. Measurement Lab (M-lab) is an distributed server platform for the deployment of internet measurement tools. The server-side tools are open source and the API's allow researchers to develop client tools such as 4GTest.

When considering RRT for LTE, its important to consider the latency of the wired parts of the path from client to server because the latency of LTE is lower than that of 3G so errors (caused by wired parts) become more notable. To minimize the path from client to server, which is not LTE, the nearest server to the client is always used.

If GPS was not available then IP address was used to locate the client. This translation from IP address to GPS is a rough estimate. The service used for this translation was MaxMind. 

To measure RRT and latency variation (difference in latency between connections not packets so its not called Jitter), the application repeatedly established a new TCP connection with the server and measures the delay between SYN and SYN-ACK packet. The median RTT measurements and the variation are reported to central server

To measure peek channel capacity, 4GTest sets up multi-threaded TCP measurements using the 3 nearest servers in M-lab. The throughput test lasts for 20 seconds, the first 5 seconds were ignored due to TCP slow start then the other 15 sec are split into 15 1 sec bins. The average throughput for each bin is calculated and the median of all bins is the measured throughput.

Interestingly, the median is used here instead of average as median reduces the impact of abnormal bins.

To collect packet traces on the android phone, tcpdump was cross-compiled.

To capture CPU usage history, a C program was written to read /proc/stat in the android system.

To understand the impact of packet size on one-way delay, delay was measured for a range of packet sizes and for each packet size, 100 samples were measured.

Power measurements were made using a Monsoon power monitor as power input for the android phone. Phone screen was turned off where possible.

The data set used for analysis is called UMICH and includes full packet traces in TCPdump format including both headers and payloads

The network model simulator takes the binary packet trace files in libpcap format and percessioning is required to collect accurate data.

Application performance 

The sample applications tested where some of the most popular apps. For the browser a simple website and a content-rich website were both tested. The approach taken involved launch the applications and then monitoring upstream, downstream data and CPU usage.

LTE Network characterization

These results are from the public deployment of 4GTest. In the US, the coverage of LTE, WiMAX and WiFi were found by 4GTest to be similar.

The public deployment of 4GTest found that the downlink and uplink throughput were both much higher for LTE than for Wi-FI, WiMAX and 3G technology. High variation in LTE throughput was observed.

For RRT and Jitter, LTE was found to have similar values to WiFi and better values than 3G and WiMAX

One-way delay and impact of packet size
On Wifi, packet size didn’t seem to influence one way delay, in either direction. On LTE, the uplink delay increases as packet size increases.

Modility
The requirements for LTE highlight that the network should be optimized for UE at low mobile speed (0 to 15 km/h) whilst still supporting high mobile speed (15 to 120 km/h). It was observed that in the face of speed changes, RTT remains stable and no significant change in throughput was observed.

Time of Day
Time of day was not found to have significant impact on the observed results .
 


Wednesday, 1 August 2012

Data Collection for Latency, Goodput & Jitter - Demo Pt 5.2

Everyone who I have spoken to about my work since yesterday, has asked me the same question. Why are you writing this in Java ? The answer is that I am going on the Google European Android Development Camp in a few weeks so I am using Java were possible in my work so that I can get familiar with the basics again.

To ensure that the server (my laptop) and the client (my android phone) can address each other I ensure that they are behind the same NAT so that private IP addresses can be used. This ensures that both devices can initialize an connect with the other

My Java code for analyzing and comparing Signpost Diagnostic Application to the results generated by Iperf and Ping, requires the following files:
  • SignOutput.txt - this is generated by the Signpost Diagnostic Application, It can be generated by:
    • Hard coding the server IP address into the application code, found here
    • Uninstall previous versions of the application and connect the android phone via USB
    • Within eclipse, load the application onto the android phone
    • cd into Downloads/android-sdk-linux/platform-tools
    • In another terminal, cd into the location of the demo server and start server using ./server.native
    • use "./adb logcat-s SIGPST >> SignOutput.txt"
    • The location of the file SignOutput.txt is now Downloads/android-sdk-linux/platform-tools, copy the file to /TestingSignpostAppOutput
  • IperfOutput.txt - this is generated by a remote shell on the Android phone, it can be generated by:
    • (In terminal 1) cd into Downloads/android-sdk-linux/platform-tools
    • connect android phone via USB
    • use "./adb shell" to start a remote shell 
    • in another terminal (terminal 2), cd into /TestingSignpostAppOutput so output file is loaded straight into correct directory
    • (In terminal 2) use  iperf -s -u >> IperfOutput.txt
    • (In terminal 1) use iperf -u -c {insert laptop IP}
  • PingDownstreamOutput.txt - this is generated by the server sending pings to the client (the android phone), it can be generated by:
    • cd into  /TestingSignpostAppOutput so output file is loaded straight into correct directory
    • Run a bash script containing the following:
    • #!/bin/bash

      for i in {1..10}
      do
        ping {insert phone IP} -c 10 -n -q >>
      PingDownstreamOutput.txt;
      done
  • PingUpstreamOutput.txt - this is generated by the client (android phone) sending pings to the server, it can be generated by:
    • cd into Downloads/android-sdk-linux/platform-tools
    • Save a bash script (lets call it pingUp) containing the following
    • #!/bin/bash

      for i in {1..10}
      do
        ping {insert laptop IP} -c 10 -n -q >>
      PingUpstreamOutput.txt;
      done
    • Connect android phone via USB and copy script to SD cards using  "./adb push pingUp / sdcard/   "
    •  use "./adb shell" to start a remote shell 
    • In the remote shell cd into /sdcard
    • In the remote shell run the script using ./pingUp
    • exit the remote shell
    • cd into  /TestingSignpostAppOutput
    • copy the PingUpstreamOutput.txt file to the laptop from the android phone using "./adb pull /sdcard/PingUpstreamOutput.txt  

Once you have generated all of these files then you can run my program SignpostOutputAnalysis.java found here which should output the average true and estimated latency, goodput and jitter.


The code in SignpostOutputAnalysis.java is still incomplete and untested, I also have not yet tested my instructions for generating the correct files at the correct locations for the java code to be ran. I will be doing this testing next...

Tuesday, 31 July 2012

Data Collection for Latency - Demo Pt 5.1

Now its time for me to collect data from the Signpost Diagnostics Application and Iperf to see if there is a statistically significant difference between the Latency and Goodput data from the two applications. [Jitter will soon be added to the application so I will need to go back the test that]

THE PLAN...

Part A - Data from Signpost Application
  1. Connect the android phone (the client) and laptop (the server) to Internet in such a way that they are behind the same NAT box, so the client can initiate a connection with the server from a private IP address
  2. Set up the OCaml Server running on my laptop
  3. Change in client IP address in the client code and load onto android phone
  4. Running client with server, collecting data whilst viewing output from log files
Part B - Latency data from Ping
  1. Workout how to send pings bothways
  2. Workout how to use ping to get RRT bothways
  3. Collect some data on latency
Part C - Compare Data from Signposts Application and Ping
  1. Extract sufficient data from both methods
  2. Get data from both method into a suitable format
  3. If required, convert units for latency so all data in same units
  4. Compare data
  5. Answer the Question: Is there a significant difference between the data collected by Ping (assumed to be accurate) and the Signpost Application


AND THE REALITY...
 

Part A

I've just been send the most recent version of the Signpost Diagnostics Application as a .apk file. I uninstall the old version of the application using the Android GUI and install the new version using:

cd /android-sdk-linux/platform-tools
./adb install ~/Downloads/SigcommDemoAndroid.apk

I quick come to realize that the above is stage is useless. It will correctly install an application from the .apk file but I need to be able to edit the code of the application so that I can set the client IP address at a later stage

I connect both the client and server to the same Wi-FI network so that the client will be able in initiate an connection with the server

As per usual, to start up the OCaml Server, I will do


cd Downloads/sebastian-SignpostDemo-53ebd3e/SignpostServerOCaml/
./server.native

I uninstalled the last Signpost Application, change the IP address in the code and load onto phone, via Eclipse using the run as dialogue.

Pressing start on the Android application triggers a connection to be initiated with the server, this is successful as the sever outputs a link detailing the android phones name, IP address and port number used.

I can view the logs for this application live, using:


cd  Downloads/android-sdk-linux/platform-tools
./adb logcat-s SIGPST

To filter the output of logcat, I use the arguments -s SIGPST, this gives me a log output such as:

I/SIGPST  ( 1520): Received Latency Upstream: 25500
I/SIGPST  ( 1520): Received Goodput Downstream: 4026
I/SIGPST  ( 1520): Received Latency Downstream: 6008
I/SIGPST  ( 1520): Received Goodput Downstream: 1262925
I/SIGPST  ( 1520): Received Latency Upstream: 49000
I/SIGPST  ( 1520): Received Goodput Downstream: 4787
I/SIGPST  ( 1520): Received Latency Downstream: 10376
I/SIGPST  ( 1520): Received Latency Upstream: 50000
I/SIGPST  ( 1520): Received Goodput Downstream: 2735
I/SIGPST  ( 1520): Received Latency Downstream: 17004
I/SIGPST  ( 1520): Received Latency Upstream: 46500
I/SIGPST  ( 1520): Received Goodput Downstream: 4461
I/SIGPST  ( 1520): Received Latency Downstream: 4463
I/SIGPST  ( 1520): Received Goodput Downstream: 799720
I/SIGPST  ( 1520): Received Latency Upstream: 51000
I/SIGPST  ( 1520): Received Goodput Downstream: 3684
I/SIGPST  ( 1520): Received Latency Downstream: 6875
I/SIGPST  ( 1520): Received Latency Upstream: 307000
I/SIGPST  ( 1520): Received Goodput Downstream: 4670
I/SIGPST  ( 1520): Received Latency Downstream: 8749
I/SIGPST  ( 1520): Received Latency Upstream: 16500
I/SIGPST  ( 1520): Received Goodput Downstream: 2652
I/SIGPST  ( 1520): Received Latency Downstream: 6795
I/SIGPST  ( 1520): Received Goodput Downstream: 24060150
I/SIGPST  ( 1520): Received Latency Upstream: 72500
I/SIGPST  ( 1520): Received Goodput Downstream: 4190
I/SIGPST  ( 1520): Received Latency Downstream: 6809

A quick code inspection, highlights that the latency values are divided by 1000 to be converted into secs, which means that the latency values here are in ms
I will look at how to convert this to a more convenient form in part 3

I can append the output to the file Signoutput.txt using ">> Signoutput.txt"

I have added a sample of Signoutput.txt here 

Part B

I open a remote shell on the android phone using ./adb shell, I then use the ping unix commend from the client to the server, and i get an output such as

 24 packets transmitted, 24 received, 0% packet loss, time 23070ms
rtt min/avg/max/mdev = 35.614/90.183/297.302/51.944 ms

The latency will be half the RRT so here it is 45.0915 ms

Then repeating the test from the server to the client and i get an output such as

43 packets transmitted, 40 received, 6% packet loss, time 42070ms
rtt min/avg/max/mdev = 33.371/93.812/241.825/45.579 ms

So the latency is similar to before at 46.906 ms

Now I want to collect the data from the ping output, so I wrote the following bash script to do this:

#!/bin/bash

for i in {1..10}
do
  ping 192.168.14.47 -c 10 -n -q >> Pingoutput.txt;
done


This sents 100 pings, in 10 sets of 10 and sent the results of the 10 test to a file called Pingoutput.txt
The first line "#!/bin/bash" mean that this is a bash script, the ping argument "-c 10" means said 10 pings and "-q" means quiet output. >> means append to file.

I've added a sample of Pingoutput.txt here

Part C

To analysis the output files, I have written the Java code here. Currently this code is untested


Thursday, 26 July 2012

Iperf on Andriod, a new approach - Pt 4.3

This is blog post number 4, on try to run Iperf on Android, my previous attempts were:
  • Method 1 - getting the Google Play Store on a CyanogenMod phone and downloading the Iperf for Android application
  • Method 2 - SSHing into an Android phone and trying to run Iperf from the command line
  • Method 3 - repeating method 1 & 2 on another Android phone and trying a different application called Aperf
  • Method 4 - trying to run a cross-compiled version of Iperf on the Android phone
  • Potential Method 5 - cross-compile Iperf myself and try to run that version
  • Potential Method 6 - install Linux on android, following instructions here.
  • Potential Method 7 - write my own version of Iperf

THE PLAN

  1. Get to grips with the basics of Android Debug Bridge (adb)
  2. Download the cross compiled Iperf and push it onto SD card
  3. Copy Iperf over the correct location in the system

THE REALITY

1
Android Debug bridge (adb) is a command line tool for communicating with an android device via USB or an emulator instance. adb is not installed in the machine so it must be ran from the correct location, for me this was android-sdk-linux/platform-tools/.

I connect my android phone via USB and run ./adb devices to test that the device is connected. If multiple emulators/device instances are running then I will need to specify with device to use when using adb so for simplicity, I close all running emulators so that I have only my android phone running.

I can install applications from the .apk file using "adb install <path_to_apk>" and I can copy files between my device and computer using "adb pull <remote_location>  <local_location>" and adb push <local_location> <remote_location>"

2/3
I've downloaded Iperf compiled for android and I do the following:

 ./adb push ~/Downloads/iperf / sdcard/   
(* copy iperf from downloads to SDcard *)

./adb shell
(* starts a remote shell on the android device, the command prompt becomes #   *)

mount -o rw,remount /system
(* remount the /system filesystem so that its now read-write *)

cp /sdcard/iperf /system/bin
(*copy the iperf code over to newly remounted /system filesystem *)

mount -o ro,remount /system
(* remount the /system filesystem so that its now read-only *)

Now I try iperf, from the remote shell and IT WORKS !
Yes, that's right, it works perfectly. This time it was 4th time lucky.

And this right here, is the reason that I'm a computer scientist. For the high, that you get when something finally works and you know that it works because you made it work. Looking back over the past few days, I feel like I've learned so much about Android and given the opportunity I would definitely do it all over again but now its time for a coffee.

Wednesday, 25 July 2012

Another Day, Another Andriod Phone - Pt 4.2

My current aim is to get Iperf running on an Android phone so that I can collect "accurate" network data to compare to the network data produced by Signpost Demo Application that I'm currently trying to test.

The problem is that I can't get the Iperf for Android application to run on any of the available android phones. I have also tried SSHing into the phone and running Iperf, this also did not work.

I need to get Iperf working on android to collect the data for comparison to data produced by the demo code. The back up plan will be to write my own application to collect the required network data, but I would like to have Iperf working so that I can test my own application.

If anyone has suggestions of tools to collect network data like bandwidth, latency, goodput and jitter, that work on linux and android using a client server architecture, then comment below.

So, I've got my hands on yet another android phone, I think this is phone number 6 or something like that. It is a HTC Magic, that is currently not rooted. I boot it up, get it going and download the Iperf for Android application and ...


.... it still will not work

So, I do some research and I come across another application that claims to also act as an Iperf cleint, this one is called Aperf. I install it on two different android phones, test and ...


.... it still will not work

Repeating the tests, changing Wi-Fi networks and finally it works, The following results are from the Iperf server

[ ID] Interval       Transfer     Bandwidth

[  4] local <server> port 5001 connected with <client_1> port 58204
[  4]  0.0- 8.9 sec  30.0 KBytes  27.6 Kbits/sec
[  5] local <server> port 5001 connected with <client_2> port 37831
[  5]  0.0- 6.0 sec  47.0 KBytes  64.3 Kbits/sec
[  4] local <server> port 5001 connected with <client_1> port 43876
[  4]  0.0- 6.6 sec   132 KBytes   164 Kbits/sec
[  5] local <server> port 5001 connected with <client_2> port 56253
[  5]  0.0- 6.6 sec   400 KBytes   496 Kbits/sec
[  4] local <server> port 5001 connected with <client_1> port 55373
[  4]  0.0- 6.5 sec   103 KBytes   131 Kbits/sec
[  5] local <server> port 5001 connected with <client_2> port 50778
[  5]  0.0- 8.6 sec   697 KBytes   662 Kbits/sec
[  4] local <server> port 5001 connected with <client_1> port 42511
[  4]  0.0- 5.1 sec  59.0 KBytes  94.3 Kbits/sec
[  5] local <server> port 5001 connected with <client_2> port 42474
[  5]  0.0- 5.9 sec   386 KBytes   539 Kbits/sec
[  4] local <server> port 5001 connected with <client_1> port 38663
[  4]  0.0- 8.6 sec  35.0 KBytes  33.3 Kbits/sec
[  5] local <server> port 5001 connected with <client_2> port 38036
[  5]  0.0- 8.2 sec   332 KBytes   331 Kbits/sec

The information above dose not show the complete picture. This data was collected from the server, in each case the client has only transmitted data for 5 seconds, this means that the bandwidth values above as incorrect. To calculate the correct bandwidth values I need to take amount of data transferred and divide by 5 seconds.

The client dose not seem to output any data except that required to calculate bandwidth. Using UDP instead of TCP dose not seem to allow me to collect any more information.

Ironically the network statistics collected by the Signpost diagnosis android app are latency, goodput and jitter but the only network statistics that I am able to collect is bandwidth.

I do not know where to go forward from here, I need accurate network statistics between a android client and Linux server so I can test the code. I could write my own application to collect the data, but then I will have the same problem again as I need accurate network statistics to check my application is working correctly

Any suggestions ??

Tuesday, 24 July 2012

Another Failed attempt to set up iperf on Andriod Phone - Demo Pt 4.1

Due to the issues with the Iperf application for android and part of the touch screen on my andriod phone not working properly, I've decided that it would be best to set up SSH to remote access on android phone, to make working with the phone easier.

To application that I decided to use to help get my SSH running on as quickly as possible was SSHDroid. This is an excellent application that I would highly recommend. The steps in setting up SSH access where:
  • Install SSHDroid and launch application
  • Change the password from its default which is "admin"
  • Install OpenSSH on your linux computer
  • run ssh root@<ip-address of android phone> 
  • Enter password when requested

Now I have the command line of the android phone, I downloaded iperf and extracted the contains of the .tar.gz file to the SD card. The next stage in my plan was to use ./configure then make then make install as per usual.

But as ever, thing are never that straight forward.
  • on doing ./configure, I get permission denied
  • on doing sudo ./configure, I get sudo: not found
  • on doing echo $USER, I get root
  • on doing ls -l | grep configure, I get ---xrwxr-x
so why will it not work ?

UPDATE:

I've managed to deal with the "Permission Denied" error despite having root access and the correct permission by prefixing ./configure with sh. This then fails to compile due to the lack of a C++ compiler

Monday, 23 July 2012

Using Iperf for Collecting Data - Demo Pt 4

Today, I am going to take a look at Iperf and get it running between my server (written in Ocaml and running my laptop) and client (on an android phone). To avoid the issues with IP addresses, I will use the same Wi-Fi network for both the client and server so that both devices are behind the same NAT box and can address each other using the private IP addresses. In this case, (like before) I only need the IP address of the server, which I will get from connection information in Ubuntu 12.04.

Iperf is already installed the server (my laptop) from when I was using Iperf to test the network properties of Tor such as latency, bandwidth and packet-loss. This was before starting this blog. I assume that Iperf was not included in Ubuntu 12.04 and that I got it via "sudo apt-get install iperf" (someone please correct me if I am wrong in this assumption)

Getting on Iperf on the client (an android phone) is a little more complex. Iperf has an android application at the google play store but my android phone does not have an app store as its running CyanogenMod. The paragraph at the top of this wikipedia article explains why there is no build in google play store

The following instruction where taken from this YouTube video. To do this you will need a micro SD card and a USB adaptor

To get the Google Play Store on CyanogenMod:
  1. Download the correct version of gapps from here
  2. Copy the .zip file of gappy onto the micro SD card and put SD back into phone
  3. Reboot in recovery mode
  4. Select flash zip from SD card and then the gapp file
  5. Reboot android phone
  6. Sign-in to your Google account

Then I simply get the Iperf application from the Google Play Store by searching Iperf.

But...
The Iperf application on android don't seem to work,  The application will load and allow me to enter an Iperf command, in this example I am simply entering -s and click Done, but then nothing happens. If I click the button with "off" on, it momentary turns green and says on before returning to off.
So as per usual its time for some trouble shooting checks:
  • Is the application for my version of andriod ? Yes, the application requirement is 1.5 or up and my version is 2.3.7
  • Is there network connectivity ?  Yes
  • Is the command that I'm test correct ? Yes -s is the example used for screenshots on Google play, also other commands like -c also don't work
  • Is this a known bug ? nope, source here
I've posted the question on stackoverflow here

Whilst I wait and see if anyone can help with my problem. I am going to take a look into the world of Android terminal emulators to see if I could run Iperf this way instead if the android application still fails to work or maybe I can ssh into the phone and run iperf. CyanogenMod comes with a terminal emulator, which I will use for now


Sunday, 22 July 2012

Getting Client & Server Talking - Demo Pt 3

Now I have an Android phone running the client and my laptop running the server, its time to get them taking.

A quick inspection of the client code shows the line "public static final int [] IP_ADDR = {128,2362,110,172}; " I change this to the IP address of my laptop and reload the code onto my android phone.

I launch the server on my laptop, the client on the Android phone and here the troubleshooting begins. Nothing appears to happen on either the client or server so I:
  1. check the network connection on both client and server 
  2. un-install the client application and re-install it
  3. check the IP address of the server is correct
  4. Try running client on emulator ✓ just got the exact same problem 

Taking a closer look at the IP address used:

I tried to find out the IP address of the server by visiting here but i thought that I should try to take a more technical approach. Visiting connection information in Ubuntu gives me a different IP address. Now I'm fairly sure that my server is behind a NAT as is my client.

Initally I assume that the different IP address are caused by the NAT, therefore the IP address from the website, is my public IP address (the IP address of the NAT) and the IP address given to my by my OS is the private IP address, that I am referred to by machines also behind the NAT.

This explaination fails to explain why using the IP address from the website didn't work and the IP address given to me by my OS doesn't have the normal structure that I would accociate with a private IP address.

So I now repeat my initial test using the different IP address (previously I used the address provided by a website and now I am using the one provided by the OS) and it works on both the android phone and the emulator.

But by use of the word "works" I mean that the server recognises that a client has connected and the GUI on the android client provides graphs showing latency and goodput, it unfortunately doesnt mean that I've yet found a good way to extract the data to make a comparision to the data provided by Iperf to test accuracy and reliably, on the assumption that Iperf will always produce accurate results that we can assume to be the true value.

The next useful step will be to continue to explore why this IP address works and the other one doesn't. As the client and server are now able to connect I can test if this IP address is working only because both client and server are behind the same NAT or is there something more complex going on. Currently both the laptop and android phone are making use of the same Wi-FI network, so the next step in testing if this will work when the client and server are not behind the same NAT is to change the network that either is using.

The plan for testing with would be:
  • move server onto another WiFi network
  • find out new IP address and update client code
  • test if emulator can connect to server, it should do as it used same network connection as the host computer, which in this case is the server
  • test if android phone can connect to server, it should not as its now not behind the same NAT as the server
  • move the android phone onto the other WiFi network
  • test if android phone can connect to server, it should now be able to 
As this test is not critical for now, I will move onto Part 4 next week, where I get Iperf collecting the same data between the android client and then compare the data collected








Wednesday, 18 July 2012

Running the Android Client - Demo Pt 2.1

An update for you on my progress on test the code to measure network performance between an android phone and a computer running a server written in Ocaml. So far, I have run the server and the client separately but not yet got them communicating. As explained in part 2 of this series, I decided to set up Eclipse with ADT Plugin on my desktop after getting some weird errors on my current laptop set up of Eclipse and ADT. The details of the problem are available here on Stackoverflow.com. There has been no clear solution to the problem. Therefore I have had to totally remove my install of Eclipse and ADT, so that I can start all over again.
DreamPlug

I've also been distracted the last few days by this piece of new kit, the DreamPlug. We are using it as part of the upcoming Signposts Demo at SIGCOMM in Helsinia.I will write an article on it soon

Finally I've fix my Eclipse set-up and I'm now able to load the client code onto the Android phone and run the server on my laptop. Part 3 will be coming very soon.

Also on a personal note, I am 20 today...

Monday, 16 July 2012

Running the Ocaml Server - Demo Pt 1

-->
I've got some code here and here in OCaml & Java, that I have been tasked with running, testing and fixing. I've already taken a look at the basic syntax but now its time to get to grips with some the libraries and related packages that Signposts makes use off.

THE SERVER IN OCAML


The first thing that took me by surprise was the number of files in the repo, considering that this is suppose to be a fairly straight forward project.

Oasis


The repo contains a file called “_oasis”, which on closer inspection includes a collection of metadata on the project. OASIS is a tools to integrate a configure, build and install system into an OCaml project. The _oasis files tells me that the entry point for the program is “server.ml” and the build dependences are the findlib packages lwt.syntax, lwt.unix, re, re.str.

The creater of the program will have ran oasis setup”, which has generated setup.ml, _tags and myocamlbiuld.ml.

According to the instructions for OASIS you can configure, build and install the Ocaml program using:

  • ocaml setup.ml -configure

  • ocaml setup.ml -build

  • ocaml setup.ml -install

Re_str

The server.ml file makes use of Re_str and two of the biuld dependences are the findlib packages re and re.str. I have found the packages here on github. Re stands for Regular expression and ocaml-re is a regular expression library doe Ocaml (that is still under development). This project has also made use of OASIS and installs without a problem

Compiling the Code

I cd into the directory and run ocaml setup.ml -configure, ocaml setup.ml -build and ocaml setup.ml -install. This generates a new dirctory “_biuld” and a new link to an executable in _biuld

Running the Code

I run a link to the execuated in _biuld and it return the following error:
Fatal error: exception Unix.Unix_error(50, "bind", "")

This means that the socked that the code is try to bind to is already in use. I inspected the code, identified the ports that were being used and ran “sudo netstat -ap | grep ':<portnumber>' “. This identified a process already using the port, the process was in fact an earlier attempt to run the project. I identified the process ID and killed the process, re-running “sudo netstat -ap | grep ':<portnumber>' “ showed that the port was now free. I can now happily run the executable in the _build directory. As this is a client-server implementation, I now need to move my attention to the client code



Sunday, 15 July 2012

Running the Android Client - Demo Pt 2



[ Sorry but this is part 2 in the series, I have completed part 1 but will not be able to upload the article until tomorrow ]

This is the 2nd part of a series on my taking a look at the code here, to test it and then improve it if required. In part 1, I ran the Ocaml server on my laptop. In this part, I run the android client. Tomorrow (Monday), in part 3 I am going to get the client and server communicating. On Tuesday, I will hopefully collect some data that I can then extract in some suitable format. On Wednesday, I hope to run Iperf between my client and server to collect data and extract in some suitable format. On Thursday, I hope to have a day of collecting data using both the GitHub code and Iperf. Finally on Friday, I hope to use a statistics package such as MatLab to compare the data collected and see if there is a statistically significant difference.

Since I have managed to mess up my eclipse/android install (see part 1), this gives me a perfect excuse to set up eclipse with ADT Plugin on my desktop. I've also got my hands on a different android phone, since the code that testing was designed for API 10. The phone info is as follows: 


Model: HTC Hero Andriod Version: 2.3.7CPU: ARMv6- compatible processor #34Available memory: 190MBMod Version: CyanogenMod-7.2.0-RC1-UNOFFICAL
Build Number: GWK74




THE BIG PLAN

The stages in setting up the Android ADK, Eclipse and loading the code that I'm testing on the Android device (spec above)

  1. Download the Android SDK (Software Development Kit)
  2. The SDK only installs the SDK tools so to install other parts of the SDK, I've got to open up the Andriod SDK Manager, this is done by cd'ing into the tools/ directory and executing android SDK
  3. To develop an Andriod app, I need to download the lastest Android SDK Platform-tools and at least on Android platform. The platform that I want is the one associated with Android 2.3.7 and API 10, I'm going to get the related SDK Platform. Documentation and System image.
  4. Download and install the latest Eclipse Classic
  5. Add the source of the ADT Plugin to the Repository in Eclipse and download the Developer Tools in via Eclipse
  6. Specify the location of the Android SDK directory in the Preferences panel of Eclipse
  7. Create a AVD (Android Virtual Device) in Eclipse with target platform 2.3.7 and API 10
  8. Download the code that I'm testing from GitHub
  9. Import the code into Eclpise
  10. Test Code on the AVD
  11. Plug in Android phone and test code on the Andriod phone


AND THEN THE REALITY


1

The Android SDK is avaliable from the Android Developer Site, the package for Linux is called android-sdk_r20-linux.tgz.


The download comes as a .tgz file, this can be extracted using: tar -zxf android-sdk_r20-linux.tgz after using cd to move to the directory that you downloaded the file to.

I've found that its useful the learn as your going along, the purpose of the arguments that you are passing to programs, so that you can then easily adjust the arguments in future to suit your needs. Using man tar, explains that -z means filter archive through gzip, -x means extract the filesand -f means that your next going to give the file name.I would highly recommend that when following tutorials with Unix commands that you use man to look up what the executable and its arguments do.


2

As with the last time I installed Android SDK, to launch the Android ADK Manager, I need to enter ./android SDK instead of android SDK. This then appears to work fine, but I would still be interested as to why I didn't work as expected.

[To clarify This command is entered after you use cd to move into android-sdk-linux/tools]


3

I selected the required packages (that I've listed in the plan above) and download them, simple as.


4

(Read this whole paragraph before beginning to download Eclipse) I download Eclipse Classic 4.2 for 32 bits as a .tar.gz file and extract the file (like before using tar -zxf eclipse-SDK-4.2-linux-gtk.tar.gz ). To install Eclipse, I cd into the new eclipse directory, to find no configure file, so my normal method of installing from .tar.gz files, of using ./configure && make && sudo make install will now not work. I little bit of research highlights that installing eclipse its not as straightforward as it might seem and the best approach for integration into Ubuntu is to get it from the software center, though I would prefer to continue to use the command line, I'm happy to leave it for now and return to this point at a later date


5

I start up eclipse, select my workspace and go into Help > Install New Software. I add the ADT Plugin at the URL https://dl-ssl.google.com/android/eclipse/. I then select the Developers Tools and install


6
With a slow connection,
you could be waiting sometime


I restarted Eclipse and configured the new ADT Plugin to link it to the Android SDK. On launching Eclipse, I'm presented with a Welcome to Android wizard (not used in the instruction at https://developer.android.com/sdk/installing/installing-adt.html)


7/8/9

Using the Eclipse GUI setting up a virtual device is straightforward. I navigate to the correct page on GitHub, download the code and extract as already done twice before and then I import the code as an existing Android project into Eclipse.


UNEXPECTED DIGRESSION


On loading the code, that I know should compile, eclipse highlights 2 errors and 13 warnings. As I'm just testing the code today before reviewing it next week. I will ignore the warming but deal with the errors as they prevent me from testing the code. The first error is from the line: import com.google.gson.Gson; I download the Gson project from googlecode and add it as an external libray to the project to overcome this. The second error is from the following line: public void onClick(View v). The error is that: The method onClick(View) must override a superclass method so this can be fixed by removing the above @Override annotation


10

Before I can run the code on the emulator, I create a new andriod project and add the code so far. I then use Run As > Android Application to test the code and it works

11

I put the android phone into USB debug mode, plug it in and run as. Again it works :)




"The best part about being a computer scientist is the feeling of satisfaction when something finally works"