Tuesday, 6 May 2014

Part One: HackRF One - Questions and Answers

I saw on IRC (#hackrf @ freenode) today that some prototype KS backers had received their GreatScott Gadgets HackRF One. Some were asking for quick tests to check that they were good to go and others were having problems, I though that I would make a quick log of the problems, queries along with their corresponding solutions and .suggestions. And add a few extra notes of my own, if I am able. I have removed all sources of questions and answers to protect peoples privacy (what little is left of it these days).

If you are currently scratching your head, because you have never heard of a HackRF before, then you should probably watch the Kickstarter video to find out more.

I'll probably sort these random questions and answers into some sort of logical order when there is enough of them, Hardware, Software, GNU Radio, RF fundamentals, .... but for now I'll just leave them mixed up higgledy-piggledy in the order that they were asked.

Problem    1: "hackrf_info" command is hanging
(VMWare 10; Host OS Windows 8.1 Enterprise; Guest OS Ubuntu Linux 14, ). 
Solution   1: Booted from a GNURadio DVD, hackrf_info responds perfectly
Extra info  1: I'm not sure if anyone has been able to get HackRF working in any vmware/virtualbox on a windows host OS. We don't know yet whether or not there is any hope for VM on Windows OS.  My guess is it may work (but perhaps at a reduced maximum sample rate) if we fix some firmware USB bugs. 

Question  2: Is the Preferred OS Linux, should I even try to use it on Windows?
Answer    2: Linux is HackRF's happy place, but there are people who have made it work under Windows.

Question  3: Is there any functional testing you can recommend performing ?
Answer    3: Listen to a FM radio station.
Extra info  3: Software to do this, and more, can be downloaded for Windows from:http://sdrsharp.com/ and for Linux: from http://gqrx.dk/ (gqrx requires GNU Radio)

Question  4: What about telescopic antenna? I guess that comes with the final unit?
Answer    4: Yes. the ANT500 were not ready in time for the prototype shipment, but they were ready in time for the default Kickstarters.

Question  5: Why the rectangle outline of pads near antenna? looks like a shield is missing?
Answer    5: There is an optional RF shield you can install if you want.

Question  6: Using GNU Radio Companion,  I can't get the osmocom source to see the HackRF One.  It shows an error message: "Source - out(0) Port is not connected."
Answer    6: "Source - out(0) Port is not connected" doesn't mean it's not detected, it's a gnuradio error message which means that the blocks' output is connected nowhere in the flowgraph within GRC. You need to connect the Source to the next block in the flow or a Sink.

Question  7:  Is this correct ? I run lsusb in verbose and it shows
Bus 001 Device 007: ID 1d50:6089 OpenMoko, Inc.
Couldn't open device, some information will be missing
Answer    7: The warning about missing USB info is due to some info being missing on the HackRF. This will probably be fixed in a later firmware revision. If it shows up on a lsusb, then all should be fine (or a "lsusb -t" if you want to check that it is plugged into a 480Mbit/sec USB 2.0 HighSpeed port on your computer). http://wiki.openmoko.org/wiki/USB_Product_IDs shows that 1d50:6089 is indeed a "HackRF One SDR".
Extra info 7:At the moment all that lsusb under Linux knows is that the vendor code is owned by "OpenMoko, Inc.", it does not know that the device is a HackRF One (yet) in /var/lib/usbutils/usb.ids. I'm sure that this will be added in a later version of the usbutils package, once it is added to the list on http://www.linux-usb.org/

Question  8: Will the final version have a RF shield over the analogue section of the board ?
Answer    8: To save cost it was dropped, but you can just buy the parts and install them yourself.
Extra info 8: From the HackRF One Bill of Materials the following two "Do Not Place" parts would be the RF shield.
The Frame is soldered to the board and the cover clips on to the frame to complete the RF shield but still allow future access to the parts under the shield if required.

Queation  9: Does the length of an antenna matter ?
Answer    9:Yes it does, in an ideal world it should be one full, 3/4, 5/8, a 1/2 or a 1/4 wavelength of the frequency that you want to tune into.
So for FM radio (88MHz-108MHz), the middle frequency is 98,000,000Hz and the speed of light is 300,000,000 meters/second [lambda=c/f]  the full wavelength length would be approximately be 3 meters (10 feet), the half wavelength would be 1.5 meters (5 feet) and the quarter wavelength would be 750 mm (2 feet 6 inches).
For WiFi on the 2.4GHz industrial, scientific and medical band 2.400 GHz to 2.500 GHz midpoint would be 2 450 000 000Hz, so the full wavelength would be about 122 mm (4.8 inches), half would be 61 mm (2.4 inches) and a quarter would be 30 mm (1.2 inches).
The rule of thumb is the higher the frequency the shorter the antenna and the lower the frequency the longer the antenna needed.
A 10MHz signal needs a 1/4 wavelength dipole antenna of length 7.5 meters (24 feet 7 inches).
Where as a 6GHz signal needs a 1/4 wavelength dipole antenna of length 12.5 mm (half an inch).
 Extra info  9: I always think of the antennas as a form of sympathetic resonance in tuning forks that if the length is close you will get near maximum power transfer. And I also think of it as a filter as well, that attenuates signals that are either side of the right frequency, a bit like a swing.

Question 10:  Is there a way to get rid of the DC spike in GNURadio ?
Answer   10: Short answer no, the DC spike is there and there is little you can do to get rid of it. But you do not need to, you just tune slightly above or slightly below the frequency that you actually want, by lets say one MHz and then use a Xlating FIR Filter block to shift the captured spectrum down or up by one MHz to avoid the DC offset spike in your baseband signal. Here is an example: http://www.sharebrained.com/2013/06/15/wireless-microphones-and-hackrf/

Problem    11: Looking for some advice on how to reduce the noise on a HackRF One running the latest firmware. I am experiencing a lot of noise.on FM radio stations that are clear as a bell using a rtlsdr dongle with the exact same software and antenna, but the HackRF One has very poor reception.
Solution   11: Make sure your host software is at latest version. All software was removed and gnuradio and gqrx were both built from the latest source. And now it works awesome!, smooth, clean and clear. no more garbled noise.
Extra info 11: There was a majorish design change/upgrade in the firmware  where I and Q were changed from unsigned to signed this is done in the CPLD instead of on the host computer now, so less CPU is needed by the host computer now. This happened in March 2014, so any software older than April 2014 will basically show noise instead of signal with this firmware upgrade.

Question 12: What are the dimensions of the HackRF-One ? (AKA - Will it fit in this X by Y by Z metal box, to shield external RF interference).
Answer   12: The PCB of the HackRF-One is 120 mm x 75 mm

Problem  13: The HackRF One can be seen with a lsusb 'ID 1d50:6089 OpenMoko, Inc.'. But with the delivered firmware on the HackRF One, the latest GNURadio and HackRF tools installed, as root I run hackrf_info and get the following error message "hackrf_open() failed: HACKRF_ERROR_NOT_FOUND (-5)".
Solution 13:  Uninstall, verify total removal (find /usr -name "*hackrf*" -print), and reinstall. It is possible that an old library is getting linked in.

Question 14: What is the input impedance of the HackRF antenna port ?
Answer   14: 50 ohms

Question 15: How fast can the HackRF, in theory anyhow, switch from TX to RX or vica versa ?
Answer   15: The RX/TX turn-around time hasn't been optimized yet, but it should be under 100 microseconds, not milliseconds. That would be achievable when controlled by the microcontroller; USB would add some latency if it is controlled by the host computer. The implications of adding too much delay vary considerably by application. For FRS two-way radio, the USB latency should be no problem at all. For 802.11, it would be a problem specifically because acknowledgement (ACK) packets need to be transmitted in a timely fashion; a possible workaround might be implementing ACKs on the microcontroller while implementing data packets on the host computer.

Question 16: How can I in GRC (GNU Radio Companion) use the HackRF One as both a sink(TX) and a source(RX)
Answer   16: Looking through the source code for gr-osmocom, it looks like it does not currently support rx/tx switching with HackRF. The sink block is only 786 lines long.  It looks like it wouldn't take too much to add tx/rx switching to it. But building and tearding down the whole TX chain at each on/off seems very slow and a bad idea. The lib supports tx on/off and rx on/off. There must be a better way.  Right now 'tx on' happens in the constructor for the sink, and that should probably be changed so that 'tx on' happens when there is data in the tx queue and 'tx off' when the queue is empty. But can you have the same device opened twice, once in RX and once in TX ? The lib seems to handle these as mutually exclusive states.  we are either in rx or in tx.  so there would need to be some coordination between the sink and source blocks......

Question 17: How do I get SDRSharp to work on Windows with the HackRF One ? I just can not get it to work. It is not seen or all I get is noise.
Answer   17:  
  1. Download and install: Zadiag http://zadig.akeo.ie/
  2. Plug your HackRF One into any USB 2.0 High Speed port on your computer.
  3. Run Zadiag and click on Options and select “List All Devices”.
  4. Choose the one that says “HackRF One”.
  5. In the box to the right of the green arrow make sure “WinUSB” is chosen - not libusb or libusbk. The big button underneath will say “Replace Driver” or “Reinstall Driver”. Before you proceed make sure the USBID matches the VID/PID of the HackRF One ( 1D50 6089 - See: http://wiki.openmoko.org/wiki/USB_Product_IDs )
  6. Download and install SDRSharp from http://sdrsharp.com/ any version newer than r1261 (15 May 2014) should be good (samples from unsigned to signed 8bit to conform to HackRF's convention)
  7. Some people suggest editing SDRSharp.exe.Config (it is in the same directory as SDRSharp.exe on your PC, right click on the SDRSharp icon and "open file location") and adding the following lines to the appSettings section:
        <add key="HackRFLNAGain" value="3" />
        <add key="HackRFVGAGain" value="3" />
        <add key="HackRFExternalAmp" value="True" />
    (sharebrained[HackRF port-a-pack] suggests the following settings with a modest antenna in <1GHz bands, RF:0, LNA/IF:16, 24 or 32, and BB/VGA:16 to 40)
  8. Run SDRSharp, tune to the FM band and smile.You can only change the gain settings, when the start button has been pressed in SDR#.
N.B. If you insert the HackRf One into a different USB port you may have to use Zadig again. It seems that you can change which driver is loaded depending on the USB port used. 
When changing the sampling rate in SDR# I have found that the HackRF stops working for me (probably best to leave it at 20MSPS and zoom in anyhow). I end up pressing Stop in SDR#, Press the blue reset button on the HackRF One, waiting about 3 seconds, and then pressing start/play in SDR#.

Question   18: How can I upgrade the ARM firmware and CPLD firmware on my HackRF One from Microsoft Windows ?
Answer     18: You currently can not, but if you have a Raspberry Pi you could upgrade the firmware(s). The instructions will work from most Debian based Linux distributions.
Extra info 18: Most flash devices are only rated for 3000 writes per block before failure, so flashing is not something that you want to do continually. It is the second part of the HackRF that can easily break without due care, the first being overloading the rx path with more than -5dBm power.
Update     18:  September 2014. There is now a temporary way to do a HackRF One upgrade on Windows: using https://homes.cs.washington.edu/~supersat/hackrf-tools-cpld-update-hack.zip 1. Install ARM firmware, 2. power cycle hackrf, 3. flash CPLD firmware, 4. power cycle hackrf.
Update     18:  If firmware 2015.07.2 (2015-07-24) or later is installed, this should work on all Windows machines using the latest hackrf host tools.

Question   19: What is the strong signal at 204, 408, 612, 816, 1020, 1224, and 1428MHz?
Answer     19: The NXP LPC4320 ARM CPU in the HackRF is clocked at 204MHz so these 'birdie''s are due to the clock signal being picked up by the antenna, or directly in the analogue part of the circuit.

Question   20: I found a grc file on the Internet for gnuradio 3.6,can I convert it to work with gnuradio 3.7 ?
Answer     20: Read http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7/ where there is mention of a script http://nathanwest.us/grc_to_37.sh for converting simple 3.6 to 3.7  grc files.

Question   21: I need to generate a cfile, how do I do this with the HackRF.
Answer     21: The default output from hackrf_transfer is 8 bit signed chars in pairs (Inphase and Quadriture), a cfile is in the same general format but is floats (usually scaled up by 8,000,000). So to convert you read in the signed char values, multiply by 8 million  and write them out to a new file, see below. For comparison the default output of a rtl-sdr is 8 bit unsigned chars, see here for more info about the rtl-sdr flowgraph.

Question   22: In gqrx how do I tune to a frequency lower than 30MHz ?
Answer     22: In gqrx under "input controls" put a tick in the "Ignore limits" checkbox to tune down to DC and up to 7250MHz.

Question   23: What is the lowest sample rate that I can set the HackRF One to ?
Answer     23: The lowest baseband filter width in the  MAX2837 chip is 1.75MHz, so the minimum sample rate is 2MSPS. 
Extra info 23: There are 16 available filters in this chip 1.75MHz , 2.25MHz, 3.5MHz, 5, 5.5MHz, 6MHz, 7MHz, 8MHz, 9MHz, 10MHz, 12MHz, 14MHz, 15MHz, 20MHz, 24MHz and 28MHz, all of which are available in the HackRF One (see: hackrf/firmware/common/max2837.c). Even though the 24MHz and 28MHz ones will never be used, at least not in the H1. There is nothing stopping you from selecting a lower sample rate below 2MSPS, but because there is no smaller analogue filter, you will end up with some nasty overlapping alias images of unwanted in band and out of band signals.
Question   24: How much power does the HackRF One need to function ?
Answer     24: The USB 2.0 specification is 500mA at 5 volts, and the HackRF says that it needs this much to function correctly https://github.com/mossmann/hackrf/wiki/FAQ#q-8. But since there is 50mA at 3.3 volts available for software-controlled antenna port power, this suggests that a HackRF One should be able to function perfectly well with only 467mA (If there is no power requirement for a LNA on a remote antenna).

Question   25: Where can I find example flowgraphs files for gnuradiocompanion ? Is there a repository of examples somewhere ?
Answer     25: The two places I would begin if looking for examples would be https://github.com/argilo/sdr-examples and http://www.oz9aec.net/index.php/grc-examples. Then I would search for additional flowgraphs in most search engine with "site:github.com filetype:grc" or "site:gnuradio.org filetype:grc" or just "filetype:grc" and whatever other search term that you are looking for an example.

Question   26: How do I open the plastic cover of the HackRF One ?
Answer     26: Remove all three SMA nuts and then use a guitar pick, or a credit card, along one side of the HackRF One from below (see this picture, which should help make it clear). 
Extra info 26: There are some excellent photos of the HackRF One at https://github.com/fd0/hackrf-one-pictures ( and Jawbreaker at https://github.com/fd0/jawbreaker-pictures ).

Question   27: I'm trying to use the HackRF to record some signals with very tight frequency requirements, but there appears to be a lot of frequency drift. Is there any way that I can reduce this or get rid of it altogether ?
Answer     27: Even atomic clocks have drift, there is no way to get rid of it totally. But it can be reduced. Basically there are a number of solutions to get less drift and they almost all revolve around having a more stable clock plugged into HackRF Clock IN port (after signal conditioning to match exactly what the HackRF One expects).
10MHz GPSDO (GPS disciplined oscillator), Trimble Thunderbolt or clock-tamer-GPS (typical 0.05ppm).
10MHz Rubidium Frequency Standard (typically 0.00005 ppm)
A custom circuit could be built that uses a "10Mhz OCXO" (0.01ppm) or even a DOCXO (0.0004ppm).
 Extra info 27: There are three quartz crystals in the HackRF: One at 2^15Hz for the RTC; One for the USB bus to allow DFU (if the H1 was ever bricked during a firmware upgrade) and finally one at 25MHz which everything else is clocked from.  The drift is caused by this X1(CX3225GB25000D0HEQZ1) (30 ppm). So any external reference clock that provides a 0 volt to 3 volt square wave at 10MHz, that is better than 30 ppm stability will reduce the drift in the HackRF. But most of the short term drift in a crystal is caused by temperature changes. As the Xtal warms up it's frequency changes. So a cheap way to stabilise the clock drift a tiny bit is to heat the HackRF up by running it for 10 minutes, to warm up, before sampling your signal of interest. It will still drift, but not as much.

Question   28: I have a 7m length of wire, as my antenna, connected to a ham-it-up upconverter which is connected to my HackRF, how come I can not receive AM radio stations. My tiny cheap AM/FM radio picks up AM station no problem, and it doesn't have a 7m antenna.
Answer     28: Antenna size is proportional to wavelength. AM radio band has rather long wavelengths. If the frequency is about 300KHz then the full wave length would be 1000 meters (a quarter of this is about 250 meters). Most AM radios have a very long copper wire wrapped around a ferrite core inside. Try using a 75m antenna and you will probably pick up some AM stations.

Question   29: Can I use a Raspberry Pi Generation 2 model B with the HackRF One ?
Answer     29: Short answer: No. Long answer: The main deficiency is the USB core of the Broadcom SOC, plug "RPi usb split transaction" into a search engine and read. The bottom line is that when it comes to moving large amounts of data around fast the RPi would be near the bottom of any performance chart. The secondary problem with the RPi is its single USB bus, it is a design deficiency. Cheap was the design criteria and never performance. There are many things that it is good for, this is not one of them. In saying all that if all you want to do is upgrade the firmware on your HackRF One and nothing else, then any RPi hardware has enough performance for that task alone.

Question  30: How can I check if my external clock has been selected by the HackRF ?
Answer    30: If you read a document called Si5315 AN619, the answer is hidden within it and the design of the hackrf. You can just use the following command "hackrf_si5351c -n 0 -r" if 0x51 is returned then internal XTAL is active, if 0x01 is returned then CLKIN is active.

Question  31: How can I convert a file captured with hackrf_transfer into a cfile for use with inspectrum ?
Answer    31: The sox audio application in UNIX can do the conversion "sox -t s8 input_file -t f32 output_file"

Useful Links:


Saturday, 3 May 2014

Raspberry Pi USB 2.0 'Gigabit' Ethernet Adapter throughput test


Update (2015-02): RaspBerry Pi Generation 2 model B - Since this USB 2.0 'Gigabit' Ethernet adapter throughput was performance bound by low CPU there should be some improvement with this new board. One can only hope that it would be closer to the Banana Pi performance with the same adapter of 39.5 MB/s (download) and 19.7 MB/s (upload) instead of RPi B non-overclocked performance of 12.5 MB/s (download) and 12.3 MB/s (upload). I would need a new RPi2B board to do tests, but worst case its performance should (still) be better than the builtin 10/100 NIC. In fact thinking about it a bit more because of the 5 port USB hub internal to the RPi2B, its performance will not be as high as the Banana Pi with dedicated USB 2.0 ports. So in theory it should be slower than the Banana Pi, but faster than a RPi B/B+ at transferring data.

Update (2014-07): There is a new RPi model B+ with 4 USB ports (well 5 in fact when you include ethernet using a LAN9514 chip instead of 3 ports using the LAN9512 in the model B). Just to be clear the tests below were done on the model B. If and when I repeat the the tests with a model B+ I do not expect to see better performance.

Raspberry Pi USB 2.0 'Gigabit' Ethernet Adapter throughput test

I bought a cheap USB 2.0 to Gigabit Ethernet Adapter (Maximum Data Transfer Rate 480 Mbps according to the website), mostly because I wanted to see how it performed on a Raspberry Pi. It can never reach 480Mbps, but it will be interesting to see how much throughput it can achieve.

As usual, I have censored any identifying information about my local network or personal hardware.

Hardware Configuration:

Raspberry Pi model B - 512MB model, 128MB of RAM allocated to GPU, no overclocking
Inbuilt 10/100 NIC is not connected.
Top USB port is empty
Bottom USB port has USB 2.0 to Gigabit Ethernet Adapter plugged in and plugged.into router

+---+  +------+         +------+           +----------------+
|RPi|->|USB2.0|->1Gbps->|router|->200Mbps->|Remote webserver|
+---+  +------+ Ethernet+------+ Internet  +----------------+
480Mibps             |
                         1Gbps Ethernet
                     |LAN webserver|

Software Configuration: 

I had to add in an extra two lines for this new USB eth1 NIC to get it working on the Raspberry Pi, the last two lines below.

pi@raspberrypi ~ $ cat /etc/network/interfaces
auto lo

iface lo inet loopback

iface eth0 inet dhcp

allow-hotplug wlan0

iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

allow-hotplug eth1

iface eth1 inet dhcp
pi@raspberrypi ~ $

pi@raspberrypi ~ $ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M
        |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
        |__ Port 3: Dev 4, If 0, Class=vend., Driver=smsc75xx, 480M

pi@raspberrypi ~ $ sudo ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full

        Port: MII
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbag
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
pi@raspberrypi ~ $  netstat -i
Kernel Interface table
eth0       1500 0         0      0      0 0             0      0      0      0 BMU
eth1       1500 0       377      0      0 0           382      0      0      0 BMRU
lo        65536 0        14      0      0 0            14      0      0      0 LRU

pi@raspberrypi ~ $ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 80:3f:5d:**:**:**
          inet addr:*.*.*.*  Bcast:*.*.*.*  Mask:*.*.*.*
          RX packets:385 errors:0 dropped:0 overruns:0 frame:0
          TX packets:390 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29012 (28.3 KiB)  TX bytes:50254 (49.0 KiB)

pi@raspberrypi ~ $

Internet Test (via a 200Mbit/sec broadband connection)

Download a single 100MiB file to the Pi through the USB 2.0 Gigabit Ethernet Adapter and send the downloaded data to /dev/null.

pi@raspberrypi ~$ time time wget http://qrng.physik.hu-berlin.de/files/speedtest-100MB.bin -O /dev/null
time wget http://qrng.physik.hu-berlin.de/files/speedtest-100MB.bin -O /dev/null
--2014-05-04 01:06:23--  http://qrng.physik.hu-berlin.de/files/speedtest-100MB.bin
Resolving qrng.physik.hu-berlin.de (qrng.physik.hu-berlin.de)...
Connecting to qrng.physik.hu-berlin.de (qrng.physik.hu-berlin.de)||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[=====================================================================>] 104,857,600 1.07M/s   in 2m 26s

2014-05-04 01:08:49 (701 KB/s) - `/dev/null' saved [104857600/104857600]

real    2m26.290s
user    0m0.880s
sys     0m3.130s
pi@raspberrypi ~ $

LAN Test

Download a single 100MiB file to the Pi through USB 2.0 Gigabit Ethernet Adapter and send the downloaded data to /dev/null. The data source is on the Local network from a machine with a 1 Gbit/sec NIC patched directly into the router with the data being read from a RAM disk to maximise read speed.
root@webserver:~# apt-get install nginx nginx-common nginx-full
root@webserver:~# /usr/sbin/nginx &
root@webserver:~# mkdir /usr/share/nginx/www/ramdisk
root@webserver:~# chmod 777 /usr/share/nginx/www/ramdisk
root@webserver:~# free -m
root@webserver:~# mount -t tmpfs -o size=256M tmpfs /usr/share/nginx/www/ramdisk
root@webserver:~# cp speedtest-100MB.bin /usr/share/nginx/www/ramdisk

pi@raspberrypi ~$  time wget http://*.*.*.*/ramdisk/speedtest-100MB.bin -O /dev/null
--2014-05-04 01:17:24--  http://*.*.*.*/ramdisk/speedtest-100MB.bin
Connecting to *.*.*.*:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[=====================================================================>] 104,857,600 12.6M/s   in 8.0s

2014-05-04 01:17:32 (12.5 MB/s) - `/dev/null' saved [104857600/104857600]

real    0m8.049s
user    0m0.600s
sys     0m2.310s

pi@raspberrypi ~ $

Peak Internet transfer rate 1.07MiB/sec (8.98Mbps) - about 13 hops away
Average Internet throughput 701KiB/sec - about 13 hops away.

Because this server is so many hops away it's throughput varies wildly with time of day and is effected by so  many uncontrolled fluctuations on every hop in between. This result is more an example of a typical Internet based throughput than a maximum throughput.

Peak LAN transfer rate 12.6 MiB/sec (105.7Mbps) - for 1000Mbps (even limited to USB 2.0 480Mbps) this is not a very good throughput.
Average LAN throughput 12.5 MiB/sec - for 1000Mbps (even limited to USB 2.0 480Mbps) this is not a very good throughput.

I'm not very pleased with the USB 2.0 Gigabit Ethernet Adapter result for the Raspberry Pi. I was expecting a result somewhere between 20 MiB/sec and 40 MiB/sec. I tried to enable jumbo frames ("sudo ifconfig eth1 mtu 9000") on the webserver and on the Raspberry Pi to see if I could get a better result, but I couldn't get it to work. I'm not quite sure why, yet but I'm still looking into it.

Additional testing

I decided to try the test in reverse. Install a webserver on the Raspberry P, and make a 128MiB ramdisk to download a file from the Raspberry Pi through USB 2.0, through the USB 2.0 Gigabit Ethernet Adapter down to the midrange PC with a Gigabit NIC, and then throw the data away.
pi@raspberrypi ~ $ sudo apt-get install nginx
pi@raspberrypi ~ $ sudo mkdir /usr/share/nginx/www/ramdisk 
pi@raspberrypi ~ $ sudo chmod 777 /usr/share/nginx/www/ramdisk
pi@raspberrypi ~ $ free -m 
pi@raspberrypi ~ $ sudo mount -t tmpfs -o size=128M tmpfs /usr/share/nginx/www/ramdisk
pi@raspberrypi ~ $  sudo cp speedtest-100MB.bin /usr/share/nginx/www/ramdisk

midrangepc $ time wget http://*.*.*.*/ramdisk/speedtest-100MB.bin -O /dev/null
--2014-05-04 17:56:38--  http://*.*.*.*/ramdisk/speedtest-100MB.bin
Connecting to *.*.*.*:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[======================================>] 104,857,600 12.3M/s   in 7.8s

2014-05-04 17:56:46 (12.2 MB/s) - `/dev/null' saved [104857600/104857600]

real    0m7.819s
user    0m0.392s
sys     0m1.744s
midrangepc $

No better than before, slightly less, same general transfer rate. But I did notice one thing, that the CPU load on the Raspberry Pi hit the roof during the transfer, so I overclocked it from 700 to 1000 MHz ("sudo raspi-config") and ran the exact same test again.

midrangepc $ time wget http://*.*.*.*/ramdisk/speedtest-100MB.bin -O /dev/null
--2014-05-04 18:06:22--  http://*.*.*.*/ramdisk/speedtest-100MB.bin
Connecting to *.*.*.*:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[======================================>] 104,857,600 17.0M/s   in 6.1s

2014-05-04 18:06:28 (16.4 MB/s) - `/dev/null' saved [104857600/104857600]

real    0m6.094s
user    0m0.312s
sys     0m1.588s

Faster, so empirically it looks like there is not enough CPU grunt in the RPi to saturate this hardware to it's maximum throughput potential. Maybe the smsc75xx driver on the RPi which pushes data to the Microchip's LAN7500 Hi-Speed USB 2.0 to 10/100/1000 Ethernet Controller chip, is CPU bound and needs to be optimised for the ARM architecture. Or maybe this is just as good as it gets on the RPi, that it is already fully optimised.

I have searched the web and some people are seeing throughput of 38.2MB/sec (305.6Mibps) using a MacBook Air using the same USB 2.0 Gigabit Ethernet Adapter. Browsing through the latest Linux kernel log file for updates to smsc75xx there was a patch for jumbo frames, which may not be in the RPi kernel yet, which could explain my problems trying to use jumbo frames above. Reading through the source code for the smsc75xx.c driver is giving me a headache, so I think that I will just accept the probable fact that this hardware does not perform all that well on a RPi. And it appears to be CPU bound.

Update (Nov 2014): I ran the above tests on a Banana Pi and managed to achieve 39.5 MB/s (download) and 19.7 MB/s (upload). But it is not really required, since the Banana Pi has a builtin 10/100/1000Mbps NIC that I have tested that can download at 109 MB/sec (872Mbps) and upload data at 71.5 MB/s (572Mbps).