maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Nokia N810 (https://talk.maemo.org/forumdisplay.php?f=28)
-   -   Poor wifi performance? (https://talk.maemo.org/showthread.php?t=12898)

ag2 2007-12-09 01:25

Poor wifi performance?
 
If I ping my router from N810, I see fairly substantial delays:

/home/user # ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=64 time=8.6 ms
64 bytes from 192.168.0.1: seq=1 ttl=64 time=17.7 ms
64 bytes from 192.168.0.1: seq=2 ttl=64 time=17.7 ms
64 bytes from 192.168.0.1: seq=3 ttl=64 time=17.7 ms
64 bytes from 192.168.0.1: seq=4 ttl=64 time=67.9 ms
64 bytes from 192.168.0.1: seq=5 ttl=64 time=59.3 ms
64 bytes from 192.168.0.1: seq=6 ttl=64 time=41.8 ms
64 bytes from 192.168.0.1: seq=7 ttl=64 time=42.0 ms
64 bytes from 192.168.0.1: seq=8 ttl=64 time=44.9 ms
64 bytes from 192.168.0.1: seq=9 ttl=64 time=43.6 ms
64 bytes from 192.168.0.1: seq=10 ttl=64 time=103.1 ms
64 bytes from 192.168.0.1: seq=11 ttl=64 time=44.0 ms
64 bytes from 192.168.0.1: seq=12 ttl=64 time=44.9 ms
64 bytes from 192.168.0.1: seq=13 ttl=64 time=60.6 ms

I am literally 10 feet away from the router. Occasionally, there is also packet loss.

ifconfig reports some TX errors:

wlan0 Link encap:Ethernet HWaddr xx:xx:xx:xx
inet addr:192.168.0.80 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2525 errors:0 dropped:0 overruns:0 frame:0
TX packets:1379 errors:14 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1209590 (1.1 MiB) TX bytes:329245 (321.5 KiB)

For comparison, my Ubuntu laptop has a consistent ping time of 1.2 ms.

Things are even worse when pinging N810 from another device on the local network.

ping 192.168.0.80
PING 192.168.0.80 (192.168.0.80) 56(84) bytes of data.
64 bytes from 192.168.0.80: icmp_seq=1 ttl=64 time=168 ms
64 bytes from 192.168.0.80: icmp_seq=2 ttl=64 time=81.7 ms
64 bytes from 192.168.0.80: icmp_seq=3 ttl=64 time=107 ms
64 bytes from 192.168.0.80: icmp_seq=4 ttl=64 time=130 ms
64 bytes from 192.168.0.80: icmp_seq=5 ttl=64 time=153 ms
64 bytes from 192.168.0.80: icmp_seq=6 ttl=64 time=74.7 ms
64 bytes from 192.168.0.80: icmp_seq=7 ttl=64 time=98.1 ms
64 bytes from 192.168.0.80: icmp_seq=8 ttl=64 time=123 ms
64 bytes from 192.168.0.80: icmp_seq=9 ttl=64 time=147 ms
64 bytes from 192.168.0.80: icmp_seq=10 ttl=64 time=67.6 ms

This is pretty bad. I wonder if the problem is specific to my device, or if all N810's are affected. If anyone has root access, can you please ping your router a few times and post the results in this thread?

Thanks!

sparkling 2007-12-09 02:43

Re: Poor wifi performance?
 
Similar here: PC ping time 2ms, N810 ping 18ms or longer.

zerojay 2007-12-09 06:00

Re: Poor wifi performance?
 
The tablet's a much slower machine than your PC is, so it's normal that a ping is longer. Also, if you have QoS, it's possible that your ping packets are receiving lower priority than it really takes to go back and forth to the server, throwing the numbers off completely.

Moonshine 2007-12-09 06:12

Re: Poor wifi performance?
 
FWIW, I see 10-25ms ping times to my wifi router. I wouldn't worry about slightly elevated times, but packet loss is another story. You might want to try another wifi channel or see if any form of "turbo" mode can be disabled.

technut 2007-12-09 06:37

Re: Poor wifi performance?
 
N800 here, running OS2008 beta.

When pinging tablet to PC, I get times between 2.5 to 68ms, but mostly around 15ms.

However, when pinging PC to tablet, I'm seeing a pattern of increasing ping times up to 100ms or so, then the patterns starts over again. Nothing else running on the N800. Good Wi-Fi signal. And the pattern is unique to pinging the tablet, nothing else.

Weird.

Quote:

Pinging 192.168.1.121 with 32 bytes of data:

Reply from 192.168.1.121: bytes=32 time=24ms TTL=64
Reply from 192.168.1.121: bytes=32 time=32ms TTL=64
Reply from 192.168.1.121: bytes=32 time=54ms TTL=64
Reply from 192.168.1.121: bytes=32 time=78ms TTL=64
Reply from 192.168.1.121: bytes=32 time=101ms TTL=64
Reply from 192.168.1.121: bytes=32 time=20ms TTL=64
Reply from 192.168.1.121: bytes=32 time=44ms TTL=64
Reply from 192.168.1.121: bytes=32 time=67ms TTL=64
Reply from 192.168.1.121: bytes=32 time=90ms TTL=64
Reply from 192.168.1.121: bytes=32 time=10ms TTL=64
Reply from 192.168.1.121: bytes=32 time=33ms TTL=64
Reply from 192.168.1.121: bytes=32 time=56ms TTL=64
Reply from 192.168.1.121: bytes=32 time=79ms TTL=64
Reply from 192.168.1.121: bytes=32 time=102ms TTL=64
Reply from 192.168.1.121: bytes=32 time=22ms TTL=64
Reply from 192.168.1.121: bytes=32 time=45ms TTL=64
Reply from 192.168.1.121: bytes=32 time=68ms TTL=64
Reply from 192.168.1.121: bytes=32 time=91ms TTL=64
Reply from 192.168.1.121: bytes=32 time=11ms TTL=64
Reply from 192.168.1.121: bytes=32 time=33ms TTL=64
Reply from 192.168.1.121: bytes=32 time=56ms TTL=64
Reply from 192.168.1.121: bytes=32 time=78ms TTL=64
Reply from 192.168.1.121: bytes=32 time=100ms TTL=64
Reply from 192.168.1.121: bytes=32 time=20ms TTL=64

Ping statistics for 192.168.1.121:
Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 102ms, Average = 54ms

Milhouse 2007-12-09 06:58

Re: Poor wifi performance?
 
Ubuntu Gutsy Gibbon w/Intel 10/100 PRO NIC pinging N800:

Code:

neil@nm-tyan:~$ ping n8dev
PING n8dev (192.168.0.19) 56(84) bytes of data.
64 bytes from n8dev (192.168.0.19): icmp_seq=1 ttl=64 time=72.8 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=2 ttl=64 time=96.1 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=3 ttl=64 time=17.2 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=4 ttl=64 time=40.8 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=5 ttl=64 time=65.3 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=6 ttl=64 time=89.4 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=7 ttl=64 time=112 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=8 ttl=64 time=35.0 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=9 ttl=64 time=56.0 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=10 ttl=64 time=81.2 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=11 ttl=64 time=105 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=12 ttl=64 time=27.1 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=13 ttl=64 time=50.7 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=14 ttl=64 time=74.5 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=15 ttl=64 time=98.5 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=16 ttl=64 time=20.3 ms

--- n8dev ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15000ms
rtt min/avg/max/mdev = 17.254/65.246/112.847/30.098 ms


Ubuntu PC ----- [Gig Switch] ----- [WRT54GS AP] ~~~Wi-Fi~~~ N800

Average: 65ms

N800 pinging Ubuntu Gutsy Gibbon PC:

Code:

/home/user # ping 192.168.0.12
PING 192.168.0.12 (192.168.0.12): 56 data bytes
64 bytes from 192.168.0.12: seq=0 ttl=64 time=27.6 ms
64 bytes from 192.168.0.12: seq=1 ttl=64 time=20.5 ms
64 bytes from 192.168.0.12: seq=2 ttl=64 time=19.5 ms
64 bytes from 192.168.0.12: seq=3 ttl=64 time=20.6 ms
64 bytes from 192.168.0.12: seq=4 ttl=64 time=19.6 ms
64 bytes from 192.168.0.12: seq=5 ttl=64 time=19.8 ms
64 bytes from 192.168.0.12: seq=6 ttl=64 time=19.7 ms
64 bytes from 192.168.0.12: seq=7 ttl=64 time=20.7 ms
64 bytes from 192.168.0.12: seq=8 ttl=64 time=19.6 ms
64 bytes from 192.168.0.12: seq=9 ttl=64 time=20.5 ms
64 bytes from 192.168.0.12: seq=10 ttl=64 time=19.6 ms
64 bytes from 192.168.0.12: seq=11 ttl=64 time=20.5 ms
64 bytes from 192.168.0.12: seq=12 ttl=64 time=19.5 ms
64 bytes from 192.168.0.12: seq=13 ttl=64 time=20.6 ms
64 bytes from 192.168.0.12: seq=14 ttl=64 time=19.6 ms
64 bytes from 192.168.0.12: seq=15 ttl=64 time=20.5 ms
64 bytes from 192.168.0.12: seq=16 ttl=64 time=19.6 ms
64 bytes from 192.168.0.12: seq=17 ttl=64 time=20.9 ms

--- 192.168.0.12 ping statistics ---
18 packets transmitted, 18 packets received, 0% packet loss
round-trip min/avg/max = 19.5/20.4/27.6 ms


N800 ~~~Wi-Fi~~~ [WRT54GS AP] ----- [Gig Switch] ----- Ubuntu PC

Average: 20.4ms

Ubuntu Gutsy Gibbon pinging a TiVo Series 1 over a bridged wireless connection:

Code:

neil@nm-tyan:~$ ping tivo
PING tivo (192.168.0.7) 56(84) bytes of data.
64 bytes from tivo (192.168.0.7): icmp_seq=1 ttl=255 time=3.25 ms
64 bytes from tivo (192.168.0.7): icmp_seq=2 ttl=255 time=3.28 ms
64 bytes from tivo (192.168.0.7): icmp_seq=3 ttl=255 time=3.23 ms
64 bytes from tivo (192.168.0.7): icmp_seq=4 ttl=255 time=3.24 ms
64 bytes from tivo (192.168.0.7): icmp_seq=5 ttl=255 time=3.22 ms
64 bytes from tivo (192.168.0.7): icmp_seq=6 ttl=255 time=4.19 ms
64 bytes from tivo (192.168.0.7): icmp_seq=7 ttl=255 time=4.15 ms
64 bytes from tivo (192.168.0.7): icmp_seq=8 ttl=255 time=3.13 ms
64 bytes from tivo (192.168.0.7): icmp_seq=9 ttl=255 time=3.12 ms
64 bytes from tivo (192.168.0.7): icmp_seq=10 ttl=255 time=3.25 ms
64 bytes from tivo (192.168.0.7): icmp_seq=11 ttl=255 time=3.14 ms
64 bytes from tivo (192.168.0.7): icmp_seq=12 ttl=255 time=3.36 ms
64 bytes from tivo (192.168.0.7): icmp_seq=13 ttl=255 time=3.35 ms
64 bytes from tivo (192.168.0.7): icmp_seq=14 ttl=255 time=3.37 ms
64 bytes from tivo (192.168.0.7): icmp_seq=15 ttl=255 time=3.65 ms
64 bytes from tivo (192.168.0.7): icmp_seq=16 ttl=255 time=3.39 ms

--- tivo ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15005ms
rtt min/avg/max/mdev = 3.129/3.400/4.192/0.317 ms


Ubuntu PC ----- [Gig Switch] ----- [WRT54GS AP] ~~~Wi-Fi~~~ [WRT54GS Bridge] ----- TiVo

Average: 3.4ms

The TiVo Series 1 is using a 50mhz PowerPC processor, connected by wired ethernet to a Linksys WRT54GS (200mhz Broadcom CPU) which is bridged (11g, WPA PSK/TKIP) to another WRT54GS Access Point, to which the Ubuntu PC is connected via a Gig ethernet switch.

The TiVo connection is a far more convoluted route than that taken by the N800, yet the TiVo - a far less poweful device than the N800 - responds in a fraction of the time taken by the N800.

The N800 has a more powerful CPU than either of the Linksys wireless routers and the TiVo, so I can't believe the poor ping time is due to CPU issues on the N800.

Pinging *FROM* the N800 to the Ubuntu PC results in a better ping time - less than a third of that when going the other way - which suggests something odd is going on (power saving?)

I've suspected for some time that the WiFi speed on N800s (also 770s) is poor, but doubt we'll see any improvement due to the open/closed nature of the WiFi stack and the lack of apparent care/importance Nokia give to the wireless side of things. I don't think the problem is with the CPU, more likely a poor or duff implementation.

dblank 2007-12-09 08:16

Re: Poor wifi performance?
 
I think the latency is due to the power saving mode, I seem to remember ping times going down when I started a SIP call, or some other task that needed low latency.

Or maybe I had switched it into power sucking mode manually :)

fanoush 2007-12-09 08:21

Re: Poor wifi performance?
 
This is most probably caused by the power saving feature. If you are bothered by this try to increase PSM timeout to something longer than your ping interval.

EDIT: oops, dblank was faster

Milhouse 2007-12-09 09:06

Re: Poor wifi performance?
 
Ping results for different power saving settings (from Ubuntu Gutsy Gibbon w/Intel 10/100 PRO NIC to N800).

Power Saving OFF

Code:

neil@nm-tyan:~$ ping n8dev
PING n8dev (192.168.0.19) 56(84) bytes of data.
64 bytes from n8dev (192.168.0.19): icmp_seq=1 ttl=64 time=11.8 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=2 ttl=64 time=5.43 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=3 ttl=64 time=5.78 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=4 ttl=64 time=6.01 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=5 ttl=64 time=6.03 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=6 ttl=64 time=6.03 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=7 ttl=64 time=5.89 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=8 ttl=64 time=6.01 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=9 ttl=64 time=14.0 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=10 ttl=64 time=5.93 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=11 ttl=64 time=5.82 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=12 ttl=64 time=6.85 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=13 ttl=64 time=5.79 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=14 ttl=64 time=5.94 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=15 ttl=64 time=6.33 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=16 ttl=64 time=6.51 ms

--- n8dev ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15000ms
rtt min/avg/max/mdev = 5.433/6.894/14.073/2.349 ms

Average: 6.8ms

Power Saving On (INTERMEDIATE)

Code:

neil@nm-tyan:~$ ping n8dev
PING n8dev (192.168.0.19) 56(84) bytes of data.
64 bytes from n8dev (192.168.0.19): icmp_seq=1 ttl=64 time=72.0 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=2 ttl=64 time=4.92 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=3 ttl=64 time=5.55 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=4 ttl=64 time=5.73 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=5 ttl=64 time=6.25 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=6 ttl=64 time=5.18 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=7 ttl=64 time=6.37 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=8 ttl=64 time=5.56 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=9 ttl=64 time=6.19 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=10 ttl=64 time=5.21 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=11 ttl=64 time=5.34 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=12 ttl=64 time=5.33 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=13 ttl=64 time=5.05 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=14 ttl=64 time=5.13 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=15 ttl=64 time=5.33 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=16 ttl=64 time=5.72 ms

--- n8dev ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15000ms
rtt min/avg/max/mdev = 4.926/9.686/72.044/16.106 ms

Average: 9.6ms

Power Saving On (MAXIMUM)

Code:

neil@nm-tyan:~$ ping n8dev
PING n8dev (192.168.0.19) 56(84) bytes of data.
64 bytes from n8dev (192.168.0.19): icmp_seq=1 ttl=64 time=61.8 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=2 ttl=64 time=94.9 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=3 ttl=64 time=109 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=4 ttl=64 time=31.5 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=5 ttl=64 time=54.5 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=6 ttl=64 time=74.9 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=7 ttl=64 time=102 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=8 ttl=64 time=24.2 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=9 ttl=64 time=48.2 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=10 ttl=64 time=72.6 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=11 ttl=64 time=95.5 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=12 ttl=64 time=17.3 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=13 ttl=64 time=41.0 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=14 ttl=64 time=66.9 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=15 ttl=64 time=88.9 ms
64 bytes from n8dev (192.168.0.19): icmp_seq=16 ttl=64 time=115 ms

--- n8dev ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 14999ms
rtt min/avg/max/mdev = 17.389/68.824/115.931/29.966 ms

Average: 68.8ms


So it's definitely due to the power saving feature - with the default maximum power save setting (200ms?) latency increases dramatically. It's hard to say how much battery life is gained by using the maximum setting, but I guess increased latency is the price to be paid for a slight increase in battery life. If low latency is required, reduce or disable the power saving setting. Turning the power saving feature off entirely probably isn't a good idea but it's interesting to note that with power saving disabled entirely the latency of the N800 is still twice that of a TiVo.

technut 2007-12-09 10:18

Re: Poor wifi performance?
 
Same results here. Thanks!

jaark 2007-12-09 11:02

Re: Poor wifi performance?
 
Can this account for shockingly unreliable browsing?

I can pull down maybe a page or two and then it seems to only connect and get data very occasionally, while my 770 can be merrily browsing the same sites using the same WLAN at the same time.

Milhouse 2007-12-09 11:20

Re: Poor wifi performance?
 
Quote:

Originally Posted by jaark (Post 106324)
Can this account for shockingly unreliable browsing?

I can pull down maybe a page or two and then it seems to only connect and get data very occasionally, while my 770 can be merrily browsing the same sites using the same WLAN at the same time.

Your access point may not play nice with power saving mode (PSM) - you can reduce or disable the level of power saving in Connections->Advanced. PSM was added in later versions of OS2007 and caused problems for some routers (the minority fortunately) - OS2008 adds a GUI option to disable/reduce PSM if it isn't compatible with the users wireless router.

jaark 2007-12-09 11:24

Re: Poor wifi performance?
 
Thanks, I'll give that a try.. if I ever get the thing turned on again.

I've set it to intermediate and things look a lot better. Cheers.

fanoush 2007-12-09 11:52

Re: Poor wifi performance?
 
Quote:

Originally Posted by jaark (Post 106324)
Can this account for shockingly unreliable browsing?

If you have buggy or misconfigured wlan router than yes. Powes saving mode support should be nowadays pretty normal thing but still some APs don't support it correctly or have it misconfigured by default. For misconfiguration look for parameters "Beacon interval" and "DTIM interval". Don't set it too high, something like 100 1 or 100 2 or 200 1 should be fine.

AFAIK devices in power saving mode wake up once per (DTIM*beacon interval) to check for new packets. On my AP I have beacon interval 100(ms) and DTIM set to 2 so the tablet periodically wake up each 200ms to get packets waiting for it in AP's buffer. So if the device is not sleeping when someone is sending packet to it, it will get the packet directly off the net and react immediately (like seen in those ping tests with power saving off or not effective). If not, access point will buffer it for the device and wake it as configured and resend all waiting packets in one go.

As for those ping tests - well this is pretty artificial test. If you really have such traffic (1 packet per second) and still require minimal latency then disable power saving or set sleep timeout interval above one second. And if traffic is continuous like this your device will not turn wi-fi chip off at all and will die in hour or so (but with low latency :-).

The worse latency seen in test proves that the tablet managed to sleep between those 1 second packets (and waked up in next beacon*DTIM period) which is a good thing for battery. This is actually a feature, not bug. It allows you listen to internet radio, browse web etc. while the wi-fi chip still manages to sleep most of the time.

If you want additional details, google for "wlan PSM" "wlan powersaving mode" or search also this forum or maemo lists for PSM timeout, or PSM interval.

Rocketman 2007-12-09 13:48

Re: Poor wifi performance?
 
Quote:

Originally Posted by Milhouse (Post 106328)
Your access point may not play nice with power saving mode (PSM) - you can reduce or disable the level of power saving in Connections->Advanced. PSM was added in later versions of OS2007 and caused problems for some routers (the minority fortunately) - OS2008 adds a GUI option to disable/reduce PSM if it isn't compatible with the users wireless router.

Where is this GUI option in 2008? I haven't been able to find it anywhere. I have noticed that several other configuration options from 2007 are now missing as well. While my WAP supports PSM just fine, I am kinda curious about what effect the higher latency is having on overall bandwidth and if that in turn is having negative effects on media streaming, (ORB) in particular.

Serge 2007-12-09 14:43

Re: Poor wifi performance?
 
Quote:

Originally Posted by Rocketman (Post 106356)
I am kinda curious about what effect the higher latency is having on overall bandwidth and if that in turn is having negative effects on media streaming, (ORB) in particular.

Theoretically wlan chip should never go to sleep if you are pumping a lot of data through it and trying to get maximum bandwidth. Anyway, overall wlan bandwidth is not very good. IMHO it is mostly caused by inefficient code in wlan driver which causes it to eat all the cpu resources on heavy wlan transfers. That's especially bad for media streaming, as video player has less cpu resources left on decoding. The higher is video bitrate, the more cycles get eaten by wlan driver thus starving the decoder. This looks like a purely software problem and hopefully it can be fixed later.

Some tests show that Nokia 770 wlan chip can transfer up to 2MB/s over McBSP bus, but I'm not sure if it can sustain such rate over a long period of time or can just do occasional burst transfers. A lot of things still need to be investigated and we don't have a complete picture yet.

Some more wlan performance related details can be found here (discovered while investigating Nokia 770 memory corruption bug): https://bugs.maemo.org/show_bug.cgi?id=2006
The sources of wlan driver (an open part of them) can be found here: https://garage.maemo.org/projects/cx3110x/
This cx3110x project also has a mailing list: https://garage.maemo.org/mailman/listinfo/cx3110x-devel

PS. Please don't treat this post as a source of reliable information. It just reflects my current (definitely incomplete) vision of the problem and may be wrong.

gemniii42 2007-12-09 16:50

Re: Poor wifi performance?
 
Quote:

Originally Posted by Rocketman (Post 106356)
Where is this GUI option in 2008? I haven't been able to find it anywhere. I have noticed that several other configuration options from 2007 are now missing as well. While my WAP supports PSM just fine, I am kinda curious about what effect the higher latency is having on overall bandwidth and if that in turn is having negative effects on media streaming, (ORB) in particular.

control panel --> connectivity -->connections --> (select connection) --> next, next, advanced --> other tab

Milhouse 2007-12-09 17:29

Re: Poor wifi performance?
 
Quote:

Originally Posted by Serge (Post 106370)
Theoretically wlan chip should never go to sleep if you are pumping a lot of data through it and trying to get maximum bandwidth. Anyway, overall wlan bandwidth is not very good. IMHO it is mostly caused by inefficient code in wlan driver which causes it to eat all the cpu resources on heavy wlan transfers. That's especially bad for media streaming, as video player has less cpu resources left on decoding. The higher is video bitrate, the more cycles get eaten by wlan driver thus starving the decoder. This looks like a purely software problem and hopefully it can be fixed later.

Remember how Flash would (and still does) stutter while a Flash video is downloading, yet it plays fine once the download is complete? I wonder if this is due to the download over WiFi unecessarily sapping CPU cycles - I realise that some CPU cycles will be needed to download the Flash data, but I was surprised to see that enough cycles were taken to screw up Flash playback.

As a test I just disabled PSM on my N800/OS2008 (Linksys WRT54GS access point Beacon/DTIM set to 100ms/1ms respectively) and it seems (it's hard to quantify this scientifically) that browsing is faster with PSM disabled - pages seemed to download their resources much more quickly, the progress bar displaying "139/142" (or whatever) seemed to churn through each resource with much less delay. Anyone able to confirm this? My battery just died on me! :)

Any improvements to WiFi performance would be greatly appreciated - I feel that there is some "fat" in the WiFi stack which could be trimmed to the benefit of us all.

TA-t3 2007-12-09 17:55

Re: Poor wifi performance?
 
But the wi-fi driver is closed-source, propriaretary code.. therefore it must be good, no? ;)

luca 2007-12-09 23:01

Re: Poor wifi performance?
 
Quote:

Originally Posted by TA-t3 (Post 106428)
But the wi-fi driver is closed-source, propriaretary code.. therefore it must be good, no? ;)

My opinion is that it's either too badly written that they're ashamed of showing it, or the device is so crappy that they're ashamed of showing it. However usually it's both :D

fanoush 2007-12-10 08:55

Re: Poor wifi performance?
 
Quote:

Originally Posted by luca (Post 106518)
My opinion is that it's either too badly written that they're ashamed of showing it, or the device is so crappy that they're ashamed of showing it. However usually it's both :D

Usually it is due to licencing terms. But still it may be crappy :-)

Some parts are closed, the glue between kernel and proprietary parts is open (mainly due to GPL requirements), see some details here http://garage.maemo.org/pipermail/cx...er/thread.html

As for cx3110x (the glue) - its quality is not exactly stellar, 770 version being much worse with CPU. For N800 version CPU consumption it the open part should be fine/better but it is hard to say without benchmarks. The wi-fi chip is connected over SPI bus, OMAP2 has SPI interface which handles SPI communication without needing much CPU, 770 uses McBSP chip (serial port) for SPI and busy-loops waiting for each result from the chip which eats a lot of CPU.

AndyG 2007-12-15 14:38

Re: Poor wifi performance?
 
This PSM tip has resulted in much improved browsing performance for me, thanks!

brontide 2008-03-13 14:42

Re: Poor wifi performance?
 
Has there been any movement on the WiFi performance? Developer list said they have gotten the 770 up to 1.2mB/s download which would be 2 or 3 times the download performance I'm seeing on my 810 ( Usually 500kB/s over 802.11g ).

I've tried tuning the kernel, turning energy savings on and off, and many other tricks without any change. There is some other ceiling that I'm hitting and I have no idea where it is.

I think this is the problem has been discovered, but no word on if the n8x0 has actually gotten the patches to prevent network busylooping

https://garage.maemo.org/pipermail/c...ry/000012.html

Quote:

A while ago I looked for various kernel docs to see what's happening in the
wlan driver and what can be done to reduce cpu load. My impression was that
tasklet can be only preempted by hardware interrupts, so it is impossible to
sleep in it and give cpu resources to userland applications. If that is true,
no matter if n800 driver looks nicer, it must end up busylooping too.

Though on Nokia 770 cpu usage is attributed to the application doing (for
example wget) and on N800 it is attributed to 'OMAP McSPI/0' process.
So no matter how much I try in userland I will always be hamstring by bad programming in the kernel.

jamesc760 2008-03-13 22:25

Re: Poor wifi performance?
 
no, Linux kernel's fine, it's the nokia driver and how they've implemented their wifi device power saving mode that's causing the poor performance. Setting IT's PSM to intermediate or none really improved web browsing, combined with brontide's optimization tips.

brontide 2008-03-13 22:55

Re: Poor wifi performance?
 
Yea, my tips would be a whole lot faster if we can break this speed wall on the wifi. Maybe even allow a few more connections without swamping the cpu.

I'm not expecting to peak at over 200MB/s like some of my work systems, but being able to clear 1MB/s without consuming 100% of the CPU would be nice. The wifi chipset is another whole arm chip! you think they could do something with that extra power.

Serge 2008-03-14 08:38

Re: Poor wifi performance?
 
Quote:

Originally Posted by brontide (Post 154419)
Has there been any movement on the WiFi performance? Developer list said they have gotten the 770 up to 1.2mB/s download which would be 2 or 3 times the download performance I'm seeing on my 810 ( Usually 500kB/s over 802.11g ).

Performance depends on the way you are downloading data to the device. That ~1.2MB/s was measured as pure download speed, even without storing the received data on memory card. Saving data to memory card (that's natural for normal use) will drop the performance to ~1MB/s, using scp will decrease it even more because of extra load on cpu introduced by encryption. Poorly written download client may screw up the performance too. What have you used in your tests?

Quote:

I've tried tuning the kernel, turning energy savings on and off, and many other tricks without any change. There is some other ceiling that I'm hitting and I have no idea where it is.

I think this is the problem has been discovered, but no word on if the n8x0 has actually gotten the patches to prevent network busylooping

https://garage.maemo.org/pipermail/c...ry/000012.html
Have you checked followup messages in the cx3110x-devel mailing list? It was later explained that N800/N810 wlan driver does not do busylooping anymore and can sleep while DMA transfer is in process, giving cpu to other tasks. That does not improve peak performance, but makes it more friendly to other applications. So the current N800/N810 driver already is an improvement over the default driver from 770.

If you are interested in getting answers to your wlan driver related questions, it is better to subscribe to cx3110x-devel mailing list and post to it. Kalle Valo prefers to keep the discussion there (he mentioned that several times) and he can easily miss this thread on ITT.

Quote:

So no matter how much I try in userland I will always be hamstring by bad programming in the kernel.
Cheer up :) The wlan driver does get improvements over time. If you can't wait, you or anybody else can also hack the driver yourself.

There is still a lot of potential in improving performance of both Nokia 770 and N800/N810 driver.

brontide 2008-03-14 11:39

Re: Poor wifi performance?
 
Quote:

Originally Posted by Serge (Post 154871)
Performance depends on the way you are downloading data to the device. That ~1.2MB/s was measured as pure download speed, even without storing the received data on memory card. Saving data to memory card (that's natural for normal use) will drop the performance to ~1MB/s, using scp will decrease it even more because of extra load on cpu introduced by encryption. Poorly written download client may screw up the performance too. What have you used in your tests?

time wget -q -O /dev/null http://a.b.com/10mbrandomdata

With my best tuning it runs into a hard wall ( where nothing you throw at it makes a difference ) at around 5000kbps / 625kBps. Downloading to memory is actually the way the browser works, so it's not an unfair test.


All times are GMT. The time now is 05:38.

vBulletin® Version 3.8.8