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

[EvilDragon]

Can report huge improvements here as well.


I never had issues with slow download rates (about 600KB/sec), but I had slow ping times and websites with a lot of elements like pictures took very long to load.


That's now fixed - syncing C4A scores is also about 3 - 4 times faster than before.


Awesome

 

[zapman]

What if you ping pandora from the network, does it work? What kind of ping times do you get?

This is my network:

My Pandora: 192.168.1.55

My PC: 192.168.1.51

My router: 192.168.1.1

Pinging the router from my Pandora gets me ping times 20-40 ms.

These are the ping results I get pinging from my PC [my comments are in [..] brackets]:

[No returned packages if I just ping the Pandora from my PC]
[As soon as I additionally start pinging my Router from my Pandora]:

C:\Users\Doppelwurst>ping 192.168.1.55 -t

Ping wird ausgeführt für 192.168.1.55 mit 32 Bytes Daten:
Antwort von 192.168.1.55: Bytes=32 Zeit=268ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=275ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=280ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=274ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=274ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=278ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=324ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=281ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=295ms TTL=64
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.55: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=668ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=675ms TTL=64
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.55: Bytes=32 Zeit=687ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=103ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=682ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=684ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=670ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=656ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=642ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=657ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=645ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=57ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=664ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=667ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=669ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=670ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=664ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=675ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=45ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=653ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=667ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=649ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=10ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=55ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=661ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=87ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=665ms TTL=64

[Here I quit pinging the router from my Pandora, resulting in lots of timeouts of packages sent from my PC to my Pandora]

Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.51: Zielhost nicht erreichbar.
Antwort von 192.168.1.51: Zielhost nicht erreichbar.
Antwort von 192.168.1.55: Bytes=32 Zeit=1006ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=3ms TTL=64
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.55: Bytes=32 Zeit=397ms TTL=64
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

[Here I start pinging the router from my Pandora again]

Antwort von 192.168.1.55: Bytes=32 Zeit=372ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=373ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=373ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=347ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=355ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=357ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=349ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=417ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=356ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=403ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=37ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=347ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=354ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=359ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=368ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=343ms TTL=64
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.55: Bytes=32 Zeit=425ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=422ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=416ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=418ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=420ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=406ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=415ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=401ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=402ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=404ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=398ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=400ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=401ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=403ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=436ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=400ms TTL=64
Antwort von 192.168.1.55: Bytes=32 Zeit=424ms TTL=64
Zeitüberschreitung der Anforderung.

Ping-Statistik für 192.168.1.55:
    Pakete: Gesendet = 97, Empfangen = 77, Verloren = 20
    (20% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 3ms, Maximum = 1006ms, Mittelwert = 410ms
STRG-C
^C
C:\Users\Doppelwurst>

 

[notaz]

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 ms
64 bytes from 192.168.1.11: icmp_req=2 ttl=64 time=83.4 ms
64 bytes from 192.168.1.11: icmp_req=3 ttl=64 time=309 ms
64 bytes from 192.168.1.11: icmp_req=4 ttl=64 time=219 ms
64 bytes from 192.168.1.11: icmp_req=5 ttl=64 time=151 ms
64 bytes from 192.168.1.11: icmp_req=6 ttl=64 time=72.0 ms
64 bytes from 192.168.1.11: icmp_req=7 ttl=64 time=297 ms

 

[lingenfr]

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 ms
64 bytes from 192.168.1.11: icmp_req=2 ttl=64 time=83.4 ms
64 bytes from 192.168.1.11: icmp_req=3 ttl=64 time=309 ms
64 bytes from 192.168.1.11: icmp_req=4 ttl=64 time=219 ms
64 bytes from 192.168.1.11: icmp_req=5 ttl=64 time=151 ms
64 bytes from 192.168.1.11: icmp_req=6 ttl=64 time=72.0 ms
64 bytes from 192.168.1.11: icmp_req=7 ttl=64 time=297 ms

That is a lot of variation on a local network. Not sure what else is connected and generating traffic, but if you were isolated with just your P on the net, you would not expect to see that kind of range.

 

[notaz]

That's actually wifi powersaving in action, the chip only turns on it's radios every 300ms to see if anyone wants to send anything, and this timing is negotiated with the router so the router knows when to send all data that accumulated during radio silence. I'm not sure where this 300ms setting comes from, mac80211 (Linux wifi stack) provides it over it's API to the driver, but it might be actually received earlier from the router itself. Some material  about it here:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings

Clearly this mechanism isn't working for zapman, maybe wifi firmware gets out of sync from the router or maybe something is wrong with negotiation.

 

[slaeshjag]

This seems to make it even worse on my pandora. Now I get okay speeds (~200 kB/s,) but it drops out within 30 seconds now.

 

[lingenfr]

That's actually wifi powersaving in action, the chip only turns on it's radios every 300ms to see if anyone wants to send anything, and this timing is negotiated with the router so the router knows when to send all data that accumulated during radio silence. I'm not sure where this 300ms setting comes from, mac80211 (Linux wifi stack) provides it over it's API to the driver, but it might be actually received earlier from the router itself. Some material  about it here:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings

Clearly this mechanism isn't working for zapman, maybe wifi firmware gets out of sync from the router or maybe something is wrong with negotiation.

I'm not an expert, but it appears that the TBTT and Listen intervals could be an issue. If there is as much variability as yours is showing on a slower connections it could cause timeouts and retransmits and chaos will ensue. I think your intent was to increase the window before power saving kicks in which would seem to make sense. I imagine a math wiz could calculate an optimum value. Unfortunately, that's not me.

 

[Gyges]

Thank you, O Great Notaz!

So, what if your wifi is sufficiently unreliable that you can't download the update?

Download http://openpandora.org/feeds/unstable/omap3-pandora/omap3-pandora-kernel2_3.2-pandora-r8.5_omap3-pandora.ipk some other way and put on SD card somehow (SD card reader or whatever), then run "sudo opkg install /path/to/omap3-pandora-kernel2_3.2-pandora-r8.5_omap3-pandora.ipk".

 

[Zero3K]

Is there any way for its internal WiFi chip to use all available bandwidth?

 

[mcobit]

If somebody knew, this thread wouldn't exist...

 

[Zero3K]

If somebody knew, this thread wouldn't exist...

Is the chip supposed to be able to use all of it?

 

[WizardStan]

What do you mean "use all of it"?

 

[Zero3K]

What do you mean "use all of it"?

By "use all of it", I'm asking if it should be able to be as fast as the internet connection allows.

 

[WizardStan]

Of course not. Internet connections these days far exceed what even the best wifi is capable of. Assuming an absolutely perfect connection, the best wifi chips should be able to get as much as 2MB/s transfer speed. The wifi chip in the Pandora was only ever rated for 900kB/s though, unfortunately, and most people with good connections can still only reach speeds of 600KB/s. Not that that isn't still quite good for all but the most demanding of activity, mind.

 

[skeezix]

yeah, I've got a 1ghz unit .. got about 80-90K/s (with spikes to 50K/s, or occasionally to 120K/s rarely) before, and the same after; no apparent difference.

But mine has always been relatively stable.. just slow

jeff

FWIW, I did the tin tape mod as well, a year back; that did help

 

[Asiyura]

I have a GHz, my wifi has always been good… like in "far better than skeezix's speeds"  :lol:  and it improved! (I never opened my pandora, didn't do the tin tape mod)

I have a better stability of the download speed with pndmanager, it used to cycle between large spike to 200K/s and large drop to almost 0K/s. Now, it's staying around 175K/s (since the repo seems to be capped at 176K/s per download). 

Arora seems to load websites faster too.

I ran a wget from my internet box (it's got a dummy file generator, quite handful) to pandora's /dev/null. The download speeds are ranging from 550 to 774.90K/s… AWESOME IMPROVEMENT 

(when the back of the screen is facing the floor, it drops to 450 or 500K/s… "THE IMAGE IS BLURRY FIX THAT DAMN ANTENNA!" :lol:  )

 

[Binky]

the repo seems to be capped at 176K/s per download

I think that's PNDmanager, not the repo itself

 

[Dimacus]

I have an original gc 256mb Pandora.

I have not tried the wifi mod.

Before the patch I had a stable ~80kb/s and around 50ms ping to my router. (power-savings on)

Unfortunately I didn't think of measuring it with power-savings off

After the patch I have an unstable 0 - 450kb/s (avg 50-60) and around 3-15ms ping to my counter (avg 6ms, power-savings off)

After the patch I have an unstable 30 - 400kb/s (avg 70-80) and around 10 - 35ms ping to my router (avg 31ms, power-savings on)

Things I've noticed:

I get longer periods of burst high/low speeds with power-savings on (can keep at 350kb/s for minutes, same with 1-5kb/s).

With power-savings off, the signal strength varies much more ( -72dBm to -89dBm, avg -75dBm), with it on it's ( -70dBm to -80dBm, avg -72dBm)

 

[fusion_power]

And again an repo-download crashed the entire PND Manager, happens from time to time, usualy at the last MB's of the Download. 

This time at least, the Download continued after I restarted the PND Manager, nice surprise. Usualy it starts from 0 again.  Was there something changed? It really helps to manage these WiFi instabilities if your repo downloads are continued after a break or after theyy just stopped out of mystery reasons. ^^

 

[Dimacus]

If there is an easier way of reverting back from the new driver (whole kernel?) other than reflashing, i'd be willing to do some further tests.