WiFi mysteries resolved once and for all — Power saving is clearly the culprit!


 

Hmm, so your router is unable to wake up the pandora for whatever reason (yet another router compatibility issue I guess..).


Here is how it works for me (pandora is idle and not doing any network activity):

64 bytes from 192.168.1.11: icmp_req=1 ttl=64 time=152 ms64 bytes from 192.168.1.11: icmp_req=2 ttl=64 time=83.4 ms64 bytes from 192.168.1.11: icmp_req=3 ttl=64 time=309 ms64 bytes from 192.168.1.11: icmp_req=4 ttl=64 time=219 ms64 bytes from 192.168.1.11: icmp_req=5 ttl=64 time=151 ms64 bytes from 192.168.1.11: icmp_req=6 ttl=64 time=72.0 ms64 bytes from 192.168.1.11: icmp_req=7 ttl=64 time=297 ms
 

I tried pinging my Pandora at my parents place. They have a fritzbox router and their WiFi is the only one around (in contrast to my first test at home, there are about 15WiFis around).


The pinging from a laptop to my pandora gives these results:


C:\Users\Tigao>ping 192.168.178.9 -t


Ping wird ausgeführt für 192.168.178.9 mit 32 Bytes Daten:


Antwort von 192.168.178.9: Bytes=32 Zeit=204ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=124ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=327ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=234ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=150ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=66ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=312ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=202ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=124ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=327ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=236ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=171ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=78ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=280ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=187ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=124ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=312ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=218ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=139ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=45ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=263ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=156ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=62ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=278ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=15ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=109ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=312ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=218ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=124ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=31ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=265ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=156ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=62ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=280ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=186ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=128ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=530ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=416ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=153ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=62ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=364ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=296ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=155ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=323ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=249ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=156ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=62ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=280ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=184ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=86ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=403ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=311ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=156ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=39ms TTL=64


Antwort von 192.168.178.9: Bytes=32 Zeit=280ms TTL=64


Ping-Statistik für 192.168.178.9:


Pakete: Gesendet = 55, Empfangen = 55, Verloren = 0


(0% Verlust),


Ca. Zeitangaben in Millisek.:


Minimum = 15ms, Maximum = 530ms, Mittelwert = 200ms


STRG-C


^C


The pinging works here. So the reason for the problems at the other wifi is either an effect of the router, of the number of wifis or a combination of both...
 
My Pandora doesn't connect to any wireless network when there are lots available. I have tried yesterday in two places crowded with wireless networks (my son's school and a cinema). I couldn't connect in either place. There where so many networks that every time I tried to pick one the list was different. One thing I never seen before with my Pandora's wifi was that it seemed to self power off and on. I mean it was trying to connect, trying, trying, trying, then the wifi led went off and on and again trying to connect and so on. My O2X phone couldn't connect in the cinema either but successfully connected in the school.
 
Last edited by a moderator:
The pinging works here. So the reason for the problems at the other wifi is either an effect of the router, of the number of wifis or a combination of both...
We have a Fritzbox as well, but there is quite a number of other Wifi-Networks and interference. I get the same ping-times as Notaz or you at your parents place. This seems to be independent of the signal-strengths, which I found rather unexpected.

This is using the latest Wifi fix.

I could try to set the router to a very crowded channel and test again if that would be of any help. Probably not until next week though.
 
Upgrade summary: Slight improvement, but practically still unusable. In other words: Measure-able but not feel-able.

Improvement: ping 8.8.8.8 avg: before 200-260ms, after 60-70ms. (powersaving ON, no other networking activities besides ping)

But concerning download speed and interruptions nothing changed. The "critical treshhold theory" still applies.

It works once you achieved a stable throughput (requires large download from speedy server, I can achieve 500-600 KB/s if lucky; for comparison: USB-WiFi always instantly achieves my WAN's max of 850 KB/s, no need to "build up the stable speed over time"), but before that (applies for most small downloads, browsing, PNDManager, etc) it is slow and often interrupts.

Interesting observation: If ping is the only networking activity, avg is 70ms, if there is an active download, avg gets 27ms! "Critical treshhold theory" seems to apply for ping too.

Explanation attempt: The active download seems to influence the dynamic powersaving, which notaz desribed, to the better. My initial thesis "power-saving is the culprit" seems to be very true afterall. As notaz described it, powersaving (radio silence) is on mostly, but dynamically disabled while the radio is active, but the timing of the switching seems to be bad, particularly with some routers/environments ("loosing sync/buffer"). So while an active download reached a stable speed, there is no chance for the dynamic PS to kick in, PS is defacto off while that, but should there be the slightest drop in the network connection, PS kicks in and sabotages WiFi because its state switching takes too long, results in a buffering/out-of-sync problem, which the user then realizes as an interrupt/stalling.

Further: As the most of us reported unreliable WiFi experience (sometimes amazingly works, mostly sucks), I assume that those Pandora WiFi user experiences are not related to "bad or good" WiFi chips in their particular Pandoras, but rather more or less suited WiFi environments for that quite sensitive chip/driver! Exception of course: True HW-faulty WiFi-chips, which never connect at all, or with constantly low speed.
 
Last edited by a moderator:
I never got more then 650 - 700kB/s on the Pandora and the N900 (using the same module) also doesn't get more (just check google for that).


That's probably the speed to expect when everything is working fine with the internal module.
 
I never got more then 650 - 700kB/s on the Pandora and the N900 (using the same module) also doesn't get more (just check google for that).


That's probably the speed to expect when everything is working fine with the internal module.
That would be absolutely satisfying for me, and most other WiFi-troubled users as well, I guess.

As described in depth by me and others, the problem lies far beyond that: No one complains about the max-speed being too little, but rather about WiFi mostly interrupting/stalling, working reliably only every once in a while (after passing treshhold, which is not achieved by normal app usage, only by artificially triggering large stable-speeded download) or only under very unrealistic circumstances (no other WiFi stations/devices around, and only with very specific WiFi stations, which don't get out of sync in conjunction with the very special powersaving state switching, as notaz describes it in depth).

Thanks for chiming in, but honestly, your post seems to contribute not much to the discussion now, our discussion has reached far another (very in-depth) stage now. Re-read @notaz most recent findings please. No noise. Thanks.
 
Last edited by a moderator:
@notaz: What do you say to my observation & my explanation attempt?
Perhaps right, although we also have some users for whom disabling power saving doesn't help, so "power saving is the culprit" is not always correct.

Also I'm not able to observe any effects of "critical treshold theory" you describe, it must be specific for your environment. For me it goes fullspeed from the start and ping is ~30ms. The same was true in my parents place, it would either go fullspeed or start crawling from very beginning.
 
Thanks for your clarification. Likely no solution for my Pandora to come. Except if there is another dev, who had one with the very same symptoms, who could tinker with it.
 
Well, you could be that dev:)


But as already has been said, the protocol is complex and there simply are combinations of wlan client and router that are suboptimal. I actually have exactly your symptoms with a rtl73 based stick (attached to my laptop) and my home router, even though my Pandora works great with the same router. So it may well be, that your problem cannot be solved on the kernel side of things.
 
These stuff is too low level for me to understand. What I attempted is to look into the router's log, but it only shows superficial stuff like MAC associations ON/OFF, TCP open/close, etc, but nothing related to syncing.
 
I want to add an experience I'm noticing with my router. (Netgear DG834G v4)

A little history about the issue:

I always had the problem that when using the Pandora Wifi AND the PC Wifi (with some load) the Pandora loses connection with the router.

When that was happening, pinging the router resulted in a "Destination host unreachable" even if Network Manager wasn't aware of the disconnection.

If the PC is connected through ethernet the Pandora Wifi has no problems at all.

What I found now:

I'm using an external wifi dongle (Netgear WG111v2) with the Pandora, the dongle that came from the box with my router, now the Pandora is downloading at full speed and my PC is having a lot of trouble even when I try to use ssh in the lan using the wifi, it's so slow that sometimes even surfing the net result in a not full downloaded page, so it is clear that the router itself has problems to manage multiple computers connected through wifi.

Anyway, both the PC and the Pandora dongle remains connected to the router, even after many seconds of waiting for just a ping.

Is there a not so low level and technical method to find why the external dongle remains connected and the internal wifi seems like to lose track of the router ?

Maybe some comparison from the dongle and the internal wifi connection data ?
 
Hmmm...

https://plus.google.com/u/0/116960357493251979546/posts/RZpndv4BCCD

"Linux may have been causing USB disconnects on resume from device suspend all along."

"There's a 10 ms timeout in the USB core, with a simple comment over it "TRSMRCY = 10 msec".  And indeed, in the USB 2.0 spec, section 7.1.7.7, the spec states "The USB System Software must provide a 10 ms resume recovery time (TRSMRCY) during which it will not attempt to access any device connected to the affected (just-activated) bus segment."

A software developer would say, "Ok, that means I can access the device after I wait 10 ms."  However, a hardware developer would take a careful look at Table 7-14 and notice TRSMRCY is listed as a minimum value."

I wonder if this is the issue...
 
Hello everybody! I am a new Pandora (1 Ghz! no.:532) user, since I received it yesterday from Dragon Box (Thank you ED!), so I have a little experience with it. What I know is that the internal Wi-Fi is not functioning the way I would like it to. Here is the story:

Yesterday after I started this little jewel I configured the usual things (GUI, passw, etc.) than I instantly switched on the Wi-Fi and downloaded Firefox and PNDManager from PNDStore app (appr.: 40-50MB). After that I used the Pandora OS Upgrade function. Without disconnects and stalls! Of course it was on the 1.54 SZ. BUT! After the upgrade (1.55 SZ) my problems with wifi started as it was mentioned before in this thread also. Sudden disconnects, and unable to load anything, can't even ping the router I'm connected to(according to the "ifconfig" info...).
Just for your information the things are:

Hardware Version: TP-LINK WR541G/542G v4 08140201
Firmware Version:3.6.1 Build 070806 Rel.68639n

And WPA-PSK(TKIP) encryption is used! This is at my home.

Oh, and during this my laptop was also connected to the same wifi router without problems (yes, during the first time with 1.54 SZ too!).

Sometimes I can get the ping to the router work for cuple of attempts (10-20), but after it stops and connection stalls.
At my workplace where i try to connect to the wifi (EXACTLY THE SAME as my home router!)it connects and gets IP from DCHP without problems, but the ping and any other stuff would not work even from the beginning... :( Maybe this is bacause of the greater load on the device... maybe not... I don't know. Thing is that practically I can't use the internal wifi at all. Of course I didn't try the "power saving off" and the "antenna hack" things, but I doubt it should make any significant difference as many other users mentioned before on this forum.
Maybe later I'll give it a try and post about the results, (should be flash back to 1.54..??)!
Please take into account that this is not a complaint from me, just to inform you about the facts how things are with my new favorite gadget.

Thank you all! Pandora is truly a GREAT DEVICE! Aside from wifi problems...
 
A small wifi dongle will solve your problems, but granted it is not the ideal solution.
 
Were there some Wifi-tweaks introduced between 1.54 and 1.55? I think there were ... maybe having a small program to switch between different Wifi-settings (similar to the "SGX driver installer") may be halpful? Either to track down a solution, or if different settings work best for different environments to have all the options?

(Probably a lot of work to implement though :( )

I find myself turning off the power saving more frequently now, but since my connection never failed completely I find it hard to judge how things changed. Your case may be more helpful, since it worked great before and now fails completely.
 
Last edited by a moderator:
Now I checked at my workplace on the TP-LINK router before mentioned, with power saving off (from Pandora System Info GUI!). The only change I noticed the connection speed went up from 5,5Mbit/s to 54Mbit/sec as for the Sys Info screen stated. But for anything else it didn't do a thing. Ping still fails ("Destination host ureachable...") to the wifi point i connect to. Heck it even gets the IP from the DHCP server what runs on the same router, but afaik this is a different story due to different protocols and bandwith usage... On the sys info's Network screen I do see some traffic up/down, but i think those are only little packets trying to desperately extablish connection. Hmm maybe I do some logging and post it here. See you!
 
Breaking News! I tried to connect to a different router (works as WiFi AP) at work and SUPRISE! It WORKS FLAWLESSLY! I did ping and upgraded the packages from PNDStore, during this I checked SysInfo Network screen and power saving was ON all the time. Bit rate varied from 1Mb/s to 54Mb/s and also the ping response time went from 18ms to 4-500ms. Aside from some sudden stops, which were about 1-2 sec but happened several times as data was written to SD, it worked! I also would like to check net speed but speedtest needed the newest flash plugin in Firefox (seems i have to install the 11.1.. ).

JFYI the router it worked on was the following type:

 TP-LINK TL-WR740N Ver.: 4.2 (S/N: 11979209098)

 Stock Firmware, DHCP off

 It has 4 other clients connected to it through wifi(aside from my Pandora)

That's all for now! If I happen to know anything new I'll post it here.

I already ordered a WiFi dongle :p (checked up in compatibility list!)

Thanks!
 
@kaitosan: as far as I see from your description, you have exactly the issue I have, and the problem is not related to the firmware, but to the wifi load the router is processing.

If your other devices connected are doing nothing with wifi, the Pandora works well, but if them start some heavy upload/download the Pandora goes to "Destination host unreachable", and you can resolve this  connecting them through ethernet cable, so the Pandora has a clear wifi band.

EDIT: I made a PND a year ago to make the pandora reconnecting automatically in this situation

http://boards.openpandora.org/index.php/topic/8690-wifi-reconnector/

It will not create a stable connection, but it detect the problem and reconnect automatically. This is useful mainly just for internet browsing, not heavy download because until the wifi is busy the Pandora will still lose the router address after little time.
 
Last edited by a moderator:
Back
Top