50% Packet loss on Wifi!

[dan-youd]

I have been using my Raspberry Pi over wireless recently with a TP-Link Nano Wireless N adapter using the Realtek RTL8192CU chipset. The problem I'm having is that I have started using SSH to get into the RPi through my android tablet and phone but have been having trouble with SSH freezing constantly during the RPi session both over wireless on the same network and through external networks using my dynamic DNS or using my VPN. I have ruled out my SSH software (Connectbot) as I have been connecting to my MyBook World Edition NAS drive with it for a long while over all the above conditions and it runs super smooth even over WAN. Also rules out the processor being to slow as I'm sure the MyBook has a slower ARM processor than the RPi. So I've started suspecting packet loss as I have also found the RPi runs extremely slow on the web browser.

I have done a ping test on the RPi today with my windows machine and found that it was getting an average of 50% packet loss through the wireless but 0% packet loss from a 15m Ethernet cable. ifconfig on the RPi backs up what the windows machine found as it shows just over 50% RX packets dropped.

I have also tried the USB Dongle in my wireless hub as I did wonder if it was a power issue, because if I plugged the Dongle in while the RPi was already powered on it would cause the RPi to restart but if I left it in it seemed to run stable. I found that in the USB hub the RPi got faster transfer speeds of over 600kbps while updating ect... but still suffered from around 50% packet loss.

Any help would be great as this is pretty useless as it is and I may have to use wireless for at least a few months.

[jamesh]

I'm not expert, is there any way to determine if the packet loss is down to the wireless transmission itself, or something between receiving the packet and getting it in to the CPU via USB? Anyone?

Have you tried the Raspi close to the AP just to ensure its not an interference problem?

[bgirardot]

What does

Code: Select all

sudo iwlist scanning

return for the access point you are connected to?

[dom]

This has been discussed before:
http://www.raspberrypi.org/phpBB3/viewt ... 9&p=178366
http://www.raspberrypi.org/phpBB3/viewt ... 14#p182714
http://www.raspberrypi.org/phpBB3/viewt ... 00#p171977

gsh did investigate and I believe he concluded no packets were being lost inside the USB stack.

This was from MrEngman
"And here's something of an anomaly. The ls -alR / command executes about 15% quicker for the devices using the RTL8188CUS wifi adapters, even with the 50% or so packets dropped on the Rx side, than the Netgear WNA1100 with zero packet loss. Transfering data to the Pi the RTL8188CUS devices were also quicker than the Netgear by about 5%. Makes me wonder whether the dropped packet counts are valid."

So, at the moment we're not sure if the packet loss is real, or just a reporting error.
I'm interested to hear any evidence that can prove this.

I would imagine iperf in udp mode could confirm if 50% of packets are actually getting lost.

[drgeoff]

I'm not expert, is there any way to determine if the packet loss is down to the wireless transmission itself, or something between receiving the packet and getting it in to the CPU via USB? Anyone?

One could connect the same Wi-Fi dongle to another desktop or laptop PC and position the dongle in the same place and orientation as when it was connected to the RPi. (Possibly use a USB extension lead to prevent the body of the desktop or laptop having more than a small effect on the RF propagation.) Repeat the test and compare the losses.

Maybe not 100% accurate but if the error rate was very significantly less than with the RPi, I think it would be fairly indicative that the wireless transmission itself is not the problem.

[6677]

packet loss over wifi always will be higher than over ethernet but not by that much

[dan-youd]

by bgirardot » Tue Jan 01, 2013 6:11 pm

What does

CODE: SELECT ALL
sudo iwlist scanning


return for the access point you are connected to?

Code: Select all

pi@raspberrypi ~ $ sudo iwlist scanning
lo        Interface doesn't support scanning.

wlan0     Scan completed :
          Cell 01 - Address: FC:75:16:AE:FD:28
                    ESSID:"AOL"
                    Protocol:IEEE 802.11bgn
                    Mode:Master
                    Frequency:2.447 GHz (Channel 8)
                    Encryption key:on
                    Bit Rates:300 Mb/s
                    Extra:wpa_ie=dd1a0050f20101000050f20202000050f2040050f20201000050f202
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    Extra:rsn_ie=30180100000fac020200000fac04000fac020100000fac020000
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    IE: Unknown: DD780050F204104A00011010440001021041000100103B000103104700107A34065FAD78BF86FD3FFC7516AEFD2810210006442D4C696E6B1023000844534C2D323738301024000844534C2D323738301042000830303030303030301054000800060050F20400011011000844534C2D32373830100800020086
                    Quality=100/100  Signal level=72/100  

eth0      Interface doesn't support scanning.

I have tried the same dongle in a windows machine and also a backtrack5 machine in the same location with 0 packet loss so I don't think its interference.

Dom. I have done a 64b ping test from the windows machines console and 5 out of 10 packets got lost over the wireless while 0 out of 10 packets got lost over ethernet. I could be wrong but I would say that is pretty good evidence as I couldn't see the windows machine being wrong when 9 other machines on my network all had 0 packet loss and that includes several different devices such as NAS drives, PC's and android and apple devices. I haven't checked the links you've put up yet but I'll have a look tomorrow.

It's also worth mentioning that the main OS I'm using is Raspbian but also I seem to be having the same issue with other OS's such as Raspbmc and Openelec.

If it does turn out that the packet loss is fake and not a real issue then I am still stumped as I still have the problem with SSH and also I found that VNC was freezing.

[bgirardot]

I am not familiar with the ongoing issue related to this that dom points out, so I'll just put this out there as an aside basically:

Maybe look to see if you can improve things with some ap channel selection. Wifi channels can not only be congested if others are on the same channel as you, but they overlap in general, so adjacent channels can cause interference too. Generally you want 5 channels between your network and the next strongest signal affecting you, with consideration for pure number of users of a channel if applicable.

inSSIDer is a good (free) tool to help see how things are working in your wifi neighborhood. The video on the following page shows you the basics of how to use it.

http://www.metageek.net/products/inssider/

This page also has a few tips and an explanation of the overlapping:

http://www.geekzone.co.nz/inquisitor/2996

[dan-youd]

I have finally had a chance today to test some more things out.

I have tried with the Pi closer to the router with no change,

I tried pinging www.google.co.uk which got 9% packet loss,

I changed my MTU using ifconfig to 1450 as my ISP (talktalk) doesn't use the default 1500, but that just seemed to make it worse for some reason giving me 13% packet loss in the same ping test to Google,

It's strange because it seems like the packet loss is only at the start of the ping test as if it's taking its time to start but then the pings seem constant. Could explain why SSH is so slow.

[dom]

Can you try:

("sudo apt-get install iperf" if you don't have it already)

On Pi run:
iperf -su -i 1 &

On another machine run:
iperf -c [IP address of Pi] -b 20M -i 1 -t 5

what is reported as packet loss? (final number in brackets)

[dan-youd]

Can you try:

("sudo apt-get install iperf" if you don't have it already)

On Pi run:
iperf -su -i 1 &

On another machine run:
iperf -c [IP address of Pi] -b 20M -i 1 -t 5

what is reported as packet loss? (final number in brackets)

Ill give that a try in a bit. Out of interest what do them commands actually do?

[dan-youd]

I have just got around to doing more tests on my Pi using my ethernet cable and these are the results I got:

Pi Store opens fine on ethernet but gives me an error over wireless,

Pinging www.google.co.uk from ethernet gives 0% packet loss but wireless gives me about 9% packet loss,

pinging my Pi from my Galaxy S2 using Android Terminal to ethernet gives me 0% packet loss but to wireless gives me 50% packet loss,

Also using Connectbot from my Galaxy S2 to SSH into my Pi over ethernet works excellent but doing the same over wireless is extremely slow and even cuts off or doesn't connect at times,

I haven't tried the iperf command yet but I'm setting up my second machine now with ubuntu running from a flash drive so I will post my results asap.

My conclusion is that its definately the wireless thats the issue but now I need a solution.

[jamiesk]

My conclusion is that its definately the wireless thats the issue but now I need a solution.

Your wireless is on channel 8. This is not good if there are ANY other wireless about !!! Change the channel to either 1, 6 or 11.

The ijuts who designed the 2.4 WiFi did not understand RF transmissions - a minor problem !!!

Think a new road with motorbike size lanes. The run trunks on that same road. If they do not use the lanes with enough space between them, there is going to be collisions !!!

Try again and see if this helps.

[dom]

Ill give that a try in a bit. Out of interest what do them commands actually do?

The iperf command sends UDP packets at a rate of 20 Mbits/s. UDP is lossy, so if there are errors/dropped packets they won't be retransmitted.
The recieiving end will report what % of packets it actually received.

With a wired ethernet connection I get 0% loss up until about 80Mb/s (the bandwidth of my link), then packets start getting lost.
If the Pi is busy, I start losing packets earlier, so it's best to run this on an idle Pi.

[dan-youd]

Ill give that a try in a bit. Out of interest what do them commands actually do?

The iperf command sends UDP packets at a rate of 20 Mbits/s. UDP is lossy, so if there are errors/dropped packets they won't be retransmitted.
The recieiving end will report what % of packets it actually received.

With a wired ethernet connection I get 0% loss up until about 80Mb/s (the bandwidth of my link), then packets start getting lost.
If the Pi is busy, I start losing packets earlier, so it's best to run this on an idle Pi.

I tried it out: I SSH'd into my MyBook World and used it to do the iperf command on the Pi. This is the result:

Code: Select all

 ---------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.10 port 5001 connected with 192.168.1.
pi@matrix ~ $
[ ID] Interval       Transfer     Bandwidth        Jitter
pi@matrix ~ $
[  3]  0.0- 1.0 sec  2.40 MBytes  20.1 Mbits/sec   0.711 ms
  58/ 1769 (3.3%)
[  3]  1.0- 2.0 sec  2.37 MBytes  19.9 Mbits/sec   0.493 ms
   0/ 1693 (0%)
[  3]  2.0- 3.0 sec  2.31 MBytes  19.4 Mbits/sec   0.327 ms
   0/ 1650 (0%)
[  3]  3.0- 4.0 sec  2.36 MBytes  19.8 Mbits/sec   0.501 ms
   0/ 1683 (0%)
[  3]  0.0- 5.0 sec  11.8 MBytes  19.9 Mbits/sec   0.608 ms
  57/ 8446 (0.67%)
[  3]  0.0- 5.0 sec  1 datagrams received out-of-order

[dan-youd]

My conclusion is that its definately the wireless thats the issue but now I need a solution.

Your wireless is on channel 8. This is not good if there are ANY other wireless about !!! Change the channel to either 1, 6 or 11.

The ijuts who designed the 2.4 WiFi did not understand RF transmissions - a minor problem !!!

Think a new road with motorbike size lanes. The run trunks on that same road. If they do not use the lanes with enough space between them, there is going to be collisions !!!

Try again and see if this helps.

I wish it was as simple as channel switching but I've already tried it and no different. The router is now in auto channel switching mode which may not be ideal but I've had no issue with it so I have left it that way.

With it the way it is now all my wireless devices in my house work excellent which includes android phones and tablets, windows netbook, windows laptop, kindles, xbox 360, wii, iphone and even a backtrack 5 box using the wireless adapter I'm trying to get working on my Pi works perfect. I believe it is and issue with my Pi and the Wireless adapter not communicating correctly.

[dom]

I tried it out: I SSH'd into my MyBook World and used it to do the iperf command on the Pi. This is the result:

Code: Select all

 ---------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.10 port 5001 connected with 192.168.1.
pi@matrix ~ $
[ ID] Interval       Transfer     Bandwidth        Jitter
pi@matrix ~ $
[  3]  0.0- 1.0 sec  2.40 MBytes  20.1 Mbits/sec   0.711 ms
  58/ 1769 (3.3%)
[  3]  1.0- 2.0 sec  2.37 MBytes  19.9 Mbits/sec   0.493 ms
   0/ 1693 (0%)
[  3]  2.0- 3.0 sec  2.31 MBytes  19.4 Mbits/sec   0.327 ms
   0/ 1650 (0%)
[  3]  3.0- 4.0 sec  2.36 MBytes  19.8 Mbits/sec   0.501 ms
   0/ 1683 (0%)
[  3]  0.0- 5.0 sec  11.8 MBytes  19.9 Mbits/sec   0.608 ms
  57/ 8446 (0.67%)
[  3]  0.0- 5.0 sec  1 datagrams received out-of-order

That seems to prove that the 50% packet loss reported is spurious. You received almost every packet correctly.

[dan-youd]

I tried it out: I SSH'd into my MyBook World and used it to do the iperf command on the Pi. This is the result:

Code: Select all

 ---------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.10 port 5001 connected with 192.168.1.
pi@matrix ~ $
[ ID] Interval       Transfer     Bandwidth        Jitter
pi@matrix ~ $
[  3]  0.0- 1.0 sec  2.40 MBytes  20.1 Mbits/sec   0.711 ms
  58/ 1769 (3.3%)
[  3]  1.0- 2.0 sec  2.37 MBytes  19.9 Mbits/sec   0.493 ms
   0/ 1693 (0%)
[  3]  2.0- 3.0 sec  2.31 MBytes  19.4 Mbits/sec   0.327 ms
   0/ 1650 (0%)
[  3]  3.0- 4.0 sec  2.36 MBytes  19.8 Mbits/sec   0.501 ms
   0/ 1683 (0%)
[  3]  0.0- 5.0 sec  11.8 MBytes  19.9 Mbits/sec   0.608 ms
  57/ 8446 (0.67%)
[  3]  0.0- 5.0 sec  1 datagrams received out-of-order

That seems to prove that the 50% packet loss reported is spurious. You received almost every packet correctly.

Strange thing is that I have just done a ping test from the Pi to www.google.co.uk with 147 packets transmitted and 147 packets received and also done a ping test from my Samsung Galaxy S2 to my Pi with 183 packets transmitted and 183 packets received. Strangest part of it is that none of the conditions have changed. Will have to check out SSH ect...

[dan-youd]

Actually forget that last post. I've just restarted the Pi and now the packet loss has started back up again. It doesn't make sense. It's to inconsistent to see what's even causing it because seconds after it was working it now decides its not working again.

[dan-youd]

Just did a new test with the iperf command:

Code: Select all

 ~ # iperf -c 192.168.1.10 -b 20M -i 1 -t 5WARNING: option -b implies udp testing
------------------------------------------------------------
Client connecting to 192.168.1.10, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   104 KByte (default)
------------------------------------------------------------
[  5] local 192.168.1.2 port 44726 connected with 192.168.1.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0- 1.0 sec  2.38 MBytes  20.0 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  5]  1.0- 2.0 sec  2.35 MBytes  19.7 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  5]  2.0- 3.0 sec  2.41 MBytes  20.2 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  5]  3.0- 4.0 sec  2.39 MBytes  20.1 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  5]  4.0- 5.0 sec  2.35 MBytes  19.7 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0- 5.0 sec  11.9 MBytes  19.9 Mbits/sec
[  5] Sent 8482 datagrams
[  5] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  5]  0.0- 5.5 sec  8.97 MBytes  13.7 Mbits/sec  1.428 ms 2083/ 8481 (25%)
[  5]  0.0- 5.5 sec  1 datagrams received out-of-order
~ #

Correct me if I'm wrong but 'datagrams received out-of-order' is a bad thing right? Also 2083 lost out of 8481 can't be a good thing? Strange thing I have found with this is that the packet lost always seems to be at the start of transmitting or receiving on the Pi never broken in the middle of transmitting, almost as if it's taking its time to activate the adapter for use or as if the cpu is taking its time to put its resources into the adapter. Maybe a bit like the adapter is going to sleep and then when it's needed its not waking up fast enough and once it's awake the packets are constant but as soon as the ping/download or whatever stops it goes back to sleep again.

Either way I think I'm going to buy some powerline adapters tomorrow and use it through ethernet instead because spending more the 2 weeks trying to fix my wireless is becoming way to unproductive. I'm extremely stubborn and rarely give up on solving problems on pc's ect.... In fact I wouldn't be good at my job if I gave up easily as I'm an ICT Technician but if I don't give up on this I believe my girlfriend may actually kill me lol.

Besides I'm not excellent at Linux just yet so maybe when I've learnt a bit more I'll figure it out. For the meanwhile if anyone does come up with a working solution please let me know because the wireless would be good to have for projects even if I am going to be using ethernet for now.

[jamesh]

Thanks for the reports, and good luck with the powerline stuff. Hope that sorts you out.

[dan-youd]

Just to make extra sure I'm not going mad I did one last test.

I have a fresh install of ubuntu on a 16Gb sandisk flash drive with presistant storage so I plugged it into a spare usb port on my girlfriends netbook and booted into it. I then put the wireless adapter that I'm using in my Pi in the netbook and made sure that ubuntu was using the usb adapter and not its built in wireless. I then did some tests in ubuntu and all results were perfect.

0% packet loss in a ping to google or any other machine from the ubuntu netbook,

0% packet loss when pinging the ubuntu netbook from different machines in my house,

0 RX dropped packets in ifconfig on the ubuntu netbook,

All tests were done under the same conditions as the Pi with the ubuntu netbook in the same room as the Pi.

Proves its deffinaty a Pi problem.

Told you I was stubborn lol. Any way on that note I'm on my way to buy some powerline adapters.

[dan-youd]

I have just got around to testing the Pi with a Powerline adapter and so far its working well.

Ping test to www.google.co.uk got 0% packet loss,

Ping tests to the Pi got 0% packet loss,

ifconfig shows no dropped packets both RX and TX,

this is my new iperf results by running iperf from my MyBook World Edition:

Code: Select all

pi@matrix ~ $ iperf -su -i 1 &
[1] 2314
pi@matrix ~ $ ------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.15 port 5001 connected with 192.168.1.2 port 45640
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec  2.36 MBytes  19.8 Mbits/sec   0.587 ms    0/ 1681 (0%)
[  3]  1.0- 2.0 sec  2.38 MBytes  20.0 Mbits/sec   0.608 ms    0/ 1701 (0%)
[  3]  2.0- 3.0 sec  2.38 MBytes  20.0 Mbits/sec   0.277 ms    0/ 1697 (0%)
[  3]  3.0- 4.0 sec  2.41 MBytes  20.2 Mbits/sec   0.359 ms    0/ 1716 (0%)
[  3]  4.0- 5.0 sec  2.37 MBytes  19.9 Mbits/sec   0.276 ms    0/ 1690 (0%)
[  3]  0.0- 5.0 sec  11.9 MBytes  19.9 Mbits/sec   0.655 ms    0/ 8501 (0%)
[  3]  0.0- 5.0 sec  1 datagrams received out-of-order

Still comes up with 1 datagrams received out-of-order but I'm still not sure if thats good or bad? but as you can see no lost packets this time.

Also SSH is working excellent and I'm actually sending this message using my Pi which is usually much slower. Another thing I have noticed is that the temperature of the CPU in the Pi seems a bit lower now that I'm not using WIFI.

Still a pitty about the wireless but this should do the job for now.

Thanks for the help guys.

[dom]

Still comes up with 1 datagrams received out-of-order but I'm still not sure if thats good or bad? but as you can see no lost packets this time.

That's not a problem.
http://en.wikipedia.org/wiki/User_Datagram_Protocol
"there is no guarantee of delivery, ordering or duplicate protection"
Higher levels of network stack have to deal with it.

[dan-youd]

Still comes up with 1 datagrams received out-of-order but I'm still not sure if thats good or bad? but as you can see no lost packets this time.

That's not a problem.
http://en.wikipedia.org/wiki/User_Datagram_Protocol
"there is no guarantee of delivery, ordering or duplicate protection"
Higher levels of network stack have to deal with it.

Fair enough. Well I think you'd agree that the iperf test was a deffinate improvement over LAN than over WLAN right?