[FSO/SHR] Strange connection behavior with wifi

ykstortnilats ykstortnilats at yahoo.com.tw
Tue May 19 08:54:00 CEST 2009


I've never noticed this behavior before, everything looks fine until I try to
use linphone for VoIP with wifi connection. The voice quality is really bad
with a lot of latency. I've used linphone with USB network connection and it
works just fine. Then I ping the gateway and find out the following result:
PING 192.168.11.254 (192.168.11.254): 56 data bytes

64 bytes from 192.168.11.254: seq=0 ttl=64 time=145.278 ms

64 bytes from 192.168.11.254: seq=1 ttl=64 time=66.024 ms
64 bytes from 192.168.11.254: seq=2 ttl=64 time=80.936 ms
64 bytes from 192.168.11.254: seq=3 ttl=64 time=95.852 ms
64 bytes from 192.168.11.254: seq=4 ttl=64 time=121.809 ms

64 bytes from 192.168.11.254: seq=5 ttl=64 time=42.274 ms
64 bytes from 192.168.11.254: seq=6 ttl=64 time=57.221 ms
64 bytes from 192.168.11.254: seq=7 ttl=64 time=77.001 ms
64 bytes from 192.168.11.254: seq=8 ttl=64 time=96.020 ms
64 bytes from 192.168.11.254: seq=9 ttl=64 time=116.116 ms

64 bytes from 192.168.11.254: seq=10 ttl=64 time=30.772 ms
64 bytes from 192.168.11.254: seq=11 ttl=64 time=52.624 ms
64 bytes from 192.168.11.254: seq=12 ttl=64 time=72.326 ms
64 bytes from 192.168.11.254: seq=13 ttl=64 time=86.816 ms
64 bytes from 192.168.11.254: seq=14 ttl=64 time=99.788 ms
64 bytes from 192.168.11.254: seq=15 ttl=64 time=126.074 ms

64 bytes from 192.168.11.254: seq=16 ttl=64 time=46.254 ms
64 bytes from 192.168.11.254: seq=17 ttl=64 time=56.979 ms
64 bytes from 192.168.11.254: seq=18 ttl=64 time=80.869 ms
64 bytes from 192.168.11.254: seq=19 ttl=64 time=101.196 ms
64 bytes from 192.168.11.254: seq=20 ttl=64 time=116.231 ms

64 bytes from 192.168.11.254: seq=21 ttl=64 time=30.986 ms
64 bytes from 192.168.11.254: seq=22 ttl=64 time=50.692 ms
64 bytes from 192.168.11.254: seq=23 ttl=64 time=77.690 ms
64 bytes from 192.168.11.254: seq=24 ttl=64 time=98.521 ms

I don't know why the time keeps adding up to about 120ms and then drop to
30ms.
Pinging with different packet size up to 1024 bytes gives pretty much the
same result.
With TCP connections it can be acceptable (I opened up an photo album in
flickr with Dillo and it's pretty fast), but when using audio streaming with
UDP I think this latency makes the voice lags behind.

iwconfig result:
iwconfig eth0
eth0      AR6000 802.11g  ESSID:"NCTU"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:11:95:CA:DA:6B
          Bit Rate=54 Mb/s   Tx-Power=15 dBm   Sensitivity=0/3
          Retry:on
          Encryption key:off
          Power Management:off
          Link Quality:185/94  Signal level:-166 dBm  Noise level:-96 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:3  Invalid misc:0   Missed beacon:0

The link quality is good. I've also tried to connect FR to my notebook in
ad-hoc mode and the result is similar.

Haven't tried other distributions. I'm using shr-unstable image of May
9,2009.
kernel:
uImage-2.6.29-oe10+gitr119805+f656a97d946a2529630c9770a72c10a24dc397f9-r3.4-om-gta02.bin
rootfs:
openmoko-shr-image-glibc-ipk--20090509-om-gta02.rootfs.jffs2

Regards,
Scott
-- 
View this message in context: http://n2.nabble.com/-FSO-SHR--Strange-connection-behavior-with-wifi-tp2937826p2937826.html
Sent from the Openmoko Community mailing list archive at Nabble.com.





More information about the community mailing list