I’ve worked with 802.11b (Wi-Fi) for a number of years, and I found myself wondering if there was a better way to transfer files between computers at home than FTP. FTP uses the TCP protocol, which does not always perform ideally when both ends of the transfer are on the same Wi-Fi network. This page lists the results of some tests I did, and my conclusion was that, yes, you can do better than FTP but there are no widely available, consumer-grade tools that you could use.

Experimental Set-up

There are three network nodes in this scenario: the access point providing the Wi-Fi coverage (call it AP), a Wi-Fi enabled source (call it node A), and a Wi-Fi enabled destination (call it node B).

Access Point (AP): My access point is a BT Voyager 2000, sourced in the U.K. It provides 802.11b (not 802.11g) signal, and I’ve had little trouble with it.

Node A: Files were transfered from a Linux laptop. It’s a Toshiba Portege 3840CT with 192MB of RAM, running Linux 2.4.25 and a Debian Sarge distribution.

Node B: Files were received by a Windows laptop. It’s a Toshiba TECRA A3 with 512MB of RAM, running Windows XP Pro SP2. Both nodes A and B were within 3m of the AP and were separated by 2m from each other.

File: The same file was sent in each test, and was a compressed Zip file of length 11,844,459 bytes (11.3 MB). It was big enough, with sufficiently random contents, to enable any network artifacts to show themselves. I guess I should’ve sent the same file multiple times to check my measurements, but when I did there weren’t any changes, so all measurements were the results of a single test.

Tests and Results

To give you an idea of the speed of my network, a simple ping test from A to B showed a consistent RTT of 3.6ms. All nodes were transmitting at the nominal maximum 802.11b rate of 11Mbps (effective speeds were lower than this of course).

FTP: The first test was to see how long it took FTP to transfer the file between A and B. B was running FileZilla Server 0.9.10beta. The Linux command line FTP tool on A reported that the transfer took 38.8s

FSP: I was pretty convinced that I wouldn’t better that time using an TCP based approach, so I next used a UDP based tool. FSP is reasonably popular, albeit mostly within the less reputable parts of the Internet, but was designed as a way to set up file servers that could service large numbers of downloads without overwhelming a link. As a consequence, it has speed-limiting aspects which would have impacted the results. B was running FSP server 2.8.1b24 under Cygwin (no special tweaking). The “date” tool was used on Linux to measure the transfer time, which was 75s

netcat: To remove any speed-limiting, I tried the swiss-army network tool netcat. It has a UDP mode, and allows pure transfers without any pesky additional overheads. I used netcat v1.10 but unfortunately the transfer failed to work. The network dropped most of the packets, and the received file was woefully incomplete. This disqualifies it, of course. For interest’s sake, the sending took 18s

TFTP: Another UDP-based transfer approach that’s pretty mainstream is TFTP. It’s used for low-level file transfers within networks, rather than across the Internet, and is designed for simplicity rather than speed, security or flexibility. I put the SolarWinds TFTP Server v8.27 on B, and the command line TFTP tool on A reported that the transfer took 135.5s

UFTP: Now I was beginning to doubt that I could better FTP, but then I came across UFTP. This obscure UDP-based tool is apparently used by the Wall Street Journal and is designed for transfers over wireless networks (primarily satellite) with long latencies. As it’s public domain, I modified the source to (barely) compile under gcc and got it running under Windows/Cygwin and Linux. Using the “-R 3000″ option to force a 375kB/s transfer speed, it reported a successful transfer in only 31.6s

Conclusions

Well, UFTP is the winner, being 18% faster than FTP on a 802.11b network. I don’t doubt that a UDP-based tool specifically tailored to Wi-Fi file transfers wouldn’t be slightly faster still. However, UFTP isn’t for everyone, and I couldn’t find a simple consumer-grade tool that was faster than FTP.

Admittedly, I didn’t spend much time trying to tweak TFTP or FSP. It could’ve been that there were settings that would allow them to approach UFTP’s performance. Personally, I suspect not though.

TCP isn’t totally defeated though. There are many TCP options which would support better transfer speeds under Wi-Fi, but this would require widespread operating system support. In my scenario both Linux and Windows would have needed to support the same such options, which is unlikely. But, maybe one day…

Finally, if the transfer is to/from a wired node and a wireless node, then TCP performance is likely to be close to UDP. These results are dependent on the set-up being transfer between A and B, i.e. two wireless nodes on the same Wi-Fi network.

pixelstats trackingpixel

6 Responses to “Wi-Fi Test Results”

  1. Daniel Lynch says:

    Dear Andrew,

    I read with interest your test results. I am looking or a client/server file transfer that can run over high latency (satellite) links. We’ve tried FTP but was hoping that there was someone out there using UDP.

    I was wondering if you had done anymore work or had any other contacts on this after writing up your test results?

    With kind regards,

    Dan.

  2. I don’t know about the other protocols, but I do know FSP (I’ve written a client implementation for it). If you lower the resend delay time you can increase your speed drastically. The FSP manual recommends setting it to a value close to the expected round trip time. The default value is more than a second, so this can make a huge difference. You might also get some extra performance by using a package size of 1400 bytes instead of the default 1024 (but the benefit of this is probably less big).

    Leon

  3. Andrew,

    You might expand your experiment to include Udpcast (http://udpcast.linux.lu/).

    I’ve been using this software for several months now to IP Multicast data over a three node Amateur Packet Radio Network I’ve created.

    In the near future, I intend to investigate how well Udpcast, and UFTP, perform when used to IP Multicast data over ARISS (http://www.ariss.org).

    -Paul

  4. Marco Glez says:

    Dear Andrew,
    I have worked to projects about WiFi, now I am searching a website that furnish public repositories´s test.

    Do you know where I can see this?
    University of Mexico

  5. setiri says:

    Very interesting stuff. I’ve been looking for a simple tool to do multicast transfers for local networks, any recommendations for this? Moving large files around using windos file shares is always painfully slow.

Leave a Reply