2

So I bought this Edup dongle off ebay. It's rated 802.11n, 150mbps.

I'm on a 1.5MB/sec down stream. However, when I run speedtest-cli on the dongle, contrasted with the Ethernet cable plugged into the Pi, I get the following stats:

 Wifi - EDUP (802.11n):
      d: 4.27Mbit/s
      u: 0.64Mbit/s

 Ethernet cable:
      d: 8.68Mbit/s
      u: 0.55Mbit/s

Now I'm not sure if it's the dongle - being too cheap and for me to get something more officially endorsed (according to this), or better rated.

Or is it more likely the Pi isn't configured for maximum throughput?

So what kind of settings should I look to, to improve my wifi performance?

Thanks in advance

  • 1
    Those numbers do seem low. You might try timing transfers within the LAN for comparison. I would not bother replacing the adapter. – goldilocks Jan 13 '16 at 11:44
  • 1
    Your Ethernet speed is pretty low too tho. Isn't it a network issue? – Lonefish Jan 13 '16 at 14:37
1

Considering there is seven layers in the OSI model to debug for any network. I suggest doing a full diagnostic on your network connection. One doing a speedtest is only step one in a five step test.

  • Step 1: Connectivity Testing via telnet/nc and speedtest

    This step verifies the connectivity between one's localhost and the outside service. While speed test gives a general idea of one's pipeline bandwidth.

  • Step 2: Traceroute

    traceroute <host> is the next step since this shows any latency between you and the end point.

    Each row represents a hop along your network (you may have more or fewer hops). To ensure that traceroute is accurate, the packet of data is sent through the network three times. Note the response times milliseconds (ms) for each hop.

    Note any abnormally high response times and take down the IP addresses (the numbers in the parentheses just before the response time). You will have to determine high response times within the context of the other response times.

    For example, if your traceroute returns response times between 1 ms and 50 ms, but one hop shows a three-digit response time, then you should note the IP address for that hop. Try to replicate abnormal response times to rule out any one-time interruptions.

  • Step 3: Latency test

    Pinging network servers (also called a latency test) via ping -c 5 <host> refers to repeatedly sending a packet of data to an IP address and recording the response time for each send. This tells if there is a consistent problem with a network component.

  • Step 4: Name Resolution

    dig(1) is able to report on the response time of your dns resolution. This does add latency when each hostname is looked up.

  • Step 5: Verifying network only issues

    This one is simple, a portscan via mxtoolbox or isup.me/hostname to test outside one's network verifies issues with the remote service.

  • Step 6: (optional) Verify base station connectivity* Since this is over wifi and not a standard ethernet connection then one has to take into account the surrounding 802.11 signal strenght, line of sight to the base station, channel noise, and how many other stations are flooding your airwaves.

    The most simplest way to check is to run cat /proc/net/wireless where one can get the raw dbi signal strength, link levels, and overall noise for a connection.

    As a rule of thumb for link levels range in quality:

    • High quality: 90% ~= -55db
    • Medium quality: 50% ~= -75db
    • Low quality: 30% ~= -85db
    • Unusable quality: 8% ~= -96db

Once one tests to find the issue then one can tune performance from there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.