[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