Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Benno Senoner wrote: 2008/2/14, Kalle Valo [EMAIL PROTECTED]: Most probably the connection would recover after a while, and the while here being several minutes with the default TCP settings. You think those time outs are really that long ? Yeah, they are quite long. I have heard about long timeouts with other applications using TCP. An easy way to confirm, if this is a TCP problem or something else, is to run ping in the background and see how long timeouts (ie. how much you see packet loss) you get with it. ICMP ping does not have any of problems that TCP has. Yes I did and indeed ping works much better. i tried ping -s 1024 mylocalgatewayip (1024 byte long packets) and indeed it works ok. sometimes it loses 1-4 packets while roaming but afterwards the number of packet loss is usually small. when roaming around the wlan it is about 3-4% but the nokia wlan lockup remains, see below. the strange thing is if I go around the area with my Dell Laptop (under Windows) with VNC open it does not suffer from those extreme slow downs. I'm guessing that the laptop is roaming more aggressively than the N800 and TCP works fine because of that. yes could be. I usually run 'iwevent ' to get it running in the background so that I can easily see what's happening. Very handy. thanks. Sorry, I made a mistake here! Unit of bgscan_interval is milliseconds, not seconds as I say above. So the correct way to set background scan interval is this: gconftool-2 --set --type int \ '/system/osso/connectivity/IAP/bgscan_interval' '2' I'm sorry about this. no problem, thanks, i will try it out. As for the network lock ups we are experiencing (you have to disable,enable wlan on the n800 to make it work again) Does ping work when that happens? For example, you could try to ping your gateway. Also can you send me the output from dmesg after you experience this, please? when it locks up even ping stops responding, I get a message connection lost (from maemo). I just tested it today with an xterm open running a constant ping and walking around the area. after 10min it stopped working (I was out of coverage area and returning) I did unfortunately not look at the dmesg output, I will try again and report my findings. other users reported it too as Luca Olivetti pointed out. and it seems like the problem and fix is described here: http://internettablettalk.com/forums/showpost.php?p=134914postcount=15 at least for the 770 the fix seems to exist, What I read from the link, someone had written a workaround to try again whenever the chip is responding. That would good a feature, but I would like to get more information about what's happening in this case. i will investigate this issue and will look at the sources of the patch and see if it can be adapted to the n800 wlan driver (I can ask for help on the project's mailinglist) i hope it will solve the issue as this problem occurs several times per day in my wlan environment. 770 has quite old software, so I would prefer if you can send me more information with N800. of course, I will do it, we will buy more n800,n810 for our purposes certainly not 770 : With WLAN driver changes ASAP usually means quite a long time due to all the risks, testing and certification involved. Yes, but I am willing to run my patched driver if needed, this is not a problem. I will investigate all the issues and report all my findings. PS: meanwhile in order to automate WLAN lockup recovey, how could I write a script which basically does the same like clickingon the connectivity icon, basically bring down wlan and then bring it back up. I tried with ifdown wlan0 ; ifup wlan0 but it does not work it says no such device. any hints ? some commands to send to wcond ? thanks and best regards, Benno ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers I have faced the same problem with rooming. In addition, my situation was complicated by presence of others wireless networks. So basicaly I'm using sort of ping over UDP to determine existence/quality of wireless link. I'm also using this simple script to force connection to specified network ( and force disconnect before if it is actually connected to wrong network ). You can easily adapt it to suit your needs #get authorized network name E3G_NET=`cat bindata/authorized_network` NET=`dbus-send --type=method_call --system --print-reply --dest=com.nokia.icd /com/nokia/icd com.nokia.icd.get_ipinfo | grep string | head -1 | cut -d'' -f2` if [ x$NET != x$E3G_NET ] then # echo disconnecting $NET dbus-send --system --dest=com.nokia.icd /com/nokia/icd_ui com.nokia.icd_ui.disconnect boolean:true fi #echo connecting to #E3G_NET
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
ext Siarhei Siamashka [EMAIL PROTECTED] writes: With a simple patch that just retries operation on such error, wireless connection got stable. After a long test with the test script, no problems were detected. The following lines could be occasionally seen in dmesg log and it proves that there were potential connection drops encountered, but they all did not cause any troubles in reality (MD5 of downloaded file was always OK): [50559.494232] Dynamic PSM [50559.494323] PSM timeout 1000 ms [50622.038146] We haven't got a READY interrupt from WAKEUP. (firmware crashed?) [50622.038269] Try again... [50622.038330] succeeded!!! Yeah, sounds like the SPI bus is not reliable because retransmitting the frame succeeds. I'm attaching the same patch here. It is not very clean, but it does the job (for Nokia 770). Thanks. I'm sure this patch helps with SPI problems. And I have encountered other problems with WLAN driver that are yet to be solved. For example, sometimes speed drops to ~30KB/s (that's still an unresolved mystery to me). Do you see this only with 770 or also with N800/N810? Also CPU usage is very high because of busyloop when waiting till DMA transfer is done. Tasklet, which executes the code can't be easily preempted, as far as I understand kernel documentation. Maybe it is possible to split tasklet into several parts, one of them could be responsible for initiating DMA transfer, the other could be activated on DMA transfer completion? This all is important for video streaming as any excessive CPU resources consumption by WLAN driver negatively impacts video playback performance. Sorry, I'm not familiar with OMAP 1710 McBSP, so I can't comment. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
ext Benno Senoner [EMAIL PROTECTED] writes: An easy way to confirm, if this is a TCP problem or something else, is to run ping in the background and see how long timeouts (ie. how much you see packet loss) you get with it. ICMP ping does not have any of problems that TCP has. Yes I did and indeed ping works much better. i tried ping -s 1024 mylocalgatewayip (1024 byte long packets) and indeed it works ok. sometimes it loses 1-4 packets while roaming but afterwards the number of packet loss is usually small. when roaming around the wlan it is about 3-4% but the nokia wlan lockup remains, see below. Ok, 3-4% packet loss with ping implies that roaming per se is working quite well. Though I don't know how well TCP handles 3-4% packet loss, but my guess is that it's not a problem. But the lock ups you are describing is a different issue. Is that the real problem here? Not the roaming performance but the fact that WLAN connection gets stuck very easily and no data is transfered after that. I would like to get more information about the lockup situation so that I can understand what's really happening: o You earlier mentioned that disabling WLAN Power Save Mode does not help, so we can rule that out. That's good. o Does the lockup happen with only one AP as well? I'm just wondering if the lockup is related to roaming. o Does the lockup happen with other APs (different make and model)? o What does UI show? Any errors? As for the network lock ups we are experiencing (you have to disable,enable wlan on the n800 to make it work again) Does ping work when that happens? For example, you could try to ping your gateway. Also can you send me the output from dmesg after you experience this, please? when it locks up even ping stops responding, I get a message connection lost (from maemo). I'm sorry, but I want to be clear here. Do you mean that N800 UI displays connection lost banner? Please be very specific, because all minor details count here. But if you really see connection lost in UI, that's not a lockup but an indication that the N800 lost the connection to the AP. And a properly ported maemo application would handle that situation just fine (ie. it would receive disconnected signal from libconic, would close the TCP connections and the UI would not block etc.) I just tested it today with an xterm open running a constant ping and walking around the area. after 10min it stopped working (I was out of coverage area and returning) I did unfortunately not look at the dmesg output, I will try again and report my findings. dmesg output is very important here. If you can get one, please send it here. Also please describe, in detail, what UI shows you at the time when dmesg output was saved. other users reported it too as Luca Olivetti pointed out. and it seems like the problem and fix is described here: http://internettablettalk.com/forums/showpost.php?p=134914postcount=15 at least for the 770 the fix seems to exist, What I read from the link, someone had written a workaround to try again whenever the chip is responding. That would good a feature, but I would like to get more information about what's happening in this case. i will investigate this issue and will look at the sources of the patch and see if it can be adapted to the n800 wlan driver (I can ask for help on the project's mailinglist) i hope it will solve the issue as this problem occurs several times per day in my wlan environment. If you create a patch, please send it to cx3110x-devel. I would like to see all patches (even if it's just for testing or just a quick hack) on that mailing list so that others, including me, can easily find them. But I would like to remind here that even if other people see similar symptoms somewhere else, it does not automatically mean that the problem is the same. Lots of different WLAN problems have the symptom, that is data transfer gets stuck. So a fix helping someone else does not necessarily mean that it will fix your problem. This is the reason why I need some much information so that I can really analyse the problem and I can be sure that I'm fixing the correct problem. PS: meanwhile in order to automate WLAN lockup recovey, how could I write a script which basically does the same like clickingon the connectivity icon, basically bring down wlan and then bring it back up. I tried with ifdown wlan0 ; ifup wlan0 but it does not work it says no such device. any hints ? some commands to send to wcond ? 'ifdown wlan0' doesn't work because wlan0 is not specified in /etc/network/interfaces. You need to run 'ifconfig wlan0 down', but that doesn't work because wlancond does not follow wlan0 interface status. I think the easiest would be to send disconnected signal to wlancond using D-BUS, for example with dbus-send commandline tool. Unfortunately I don't have any examples at hand, but osso-wlan sources might help you. -- Kalle Valo
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
ext Frantisek Dufka [EMAIL PROTECTED] writes: [50622.038146] We haven't got a READY interrupt from WAKEUP. (firmware crashed?) [50622.038269] Try again... [50622.038330] succeeded!!! I'm attaching the same patch here. It is not very clean, but it does the job (for Nokia 770). Not seeing whole code now but I wondered before - isn't it possible just to increase timeout inside 'if (time_after(jiffies, timeout))' instead of two passes in loop? I also haven't seen the full code, only took a quick look at the patch. But what I saw is that the whole frame is retransmitted, instead of just waiting for the WR_READY interrupt from the firmware. In other words, if the frame is lost during the tranmission to firmware, the firmware won't receive the frame and it will not assert the WR_READY interrupt. So it doesn't help even if the driver waits longer, only frame restransmission helps. The N800 code looks nicer, where the CPU is burnt there? The N800/N810 driver uses omap2_mcspi and SPI framework for accessing the SPI bus. Basically omap2_mcpi waits for DMA interrupts to know when the transfer has finished. But there are lots context switching between cx3110x and omap2_mspi threads, that might consume some extra CPU cycles. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Kalle Valo wrote:
Also CPU usage is very high because of busyloop when waiting till
DMA transfer is done. Tasklet, which executes the code can't be
easily preempted, as far as I understand kernel documentation. Maybe
it is possible to split tasklet into several parts, one of them
could be responsible for initiating DMA transfer, the other could be
activated on DMA transfer completion? This all is important for
video streaming as any excessive CPU resources consumption by WLAN
driver negatively impacts video playback performance.
Sorry, I'm not familiar with OMAP 1710 McBSP, so I can't comment.
I think you don't have to. From the code (sm_drv_spi_io.c) it looks like
McBSP is setup to use dma transfer with callback when it finishes
omap_request_dma(OMAP_DMA_MCBSP2_TX, McBSP TX, dma_tx_callback, ...
omap_request_dma(OMAP_DMA_MCBSP2_RX, McBSP RX, dma_rx_callback,
and the dma_tx/rx_callback() code just sets variable
spi_dma.dma__tx/rx_done to 1.
But the code that sends/receives the frame busyloops for it like this
omap_start_dma(spi_dma.dma_rx_ch);
omap_start_dma(spi_dma.dma_tx_ch);
while(!spi_dma.dma_rx_done) {
udelay(5);
}
while(!spi_dma.dma_tx_done) {
udelay(5);
}
spi_dma.dma_rx_done = 0;
spi_dma.dma_tx_done = 0;
So there is this nice dma architecture with callback used but the code
still spins up the cpu waiting for the done flag instead of sleeping.
So you need to be familiar with the driver and tell us if it is possible
to sleep inside cx3110x_spi_dma_read and cx3110x_spi_dma_write. And one
also needs to be familiar with kernel programming and waiting primitives
to suggest how to sleep and wait for the callback (if possible in this
context) and how to wake up the sleeping code from the dma callback.
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
ext Siarhei Siamashka [EMAIL PROTECTED] writes: 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. Nope, on N800 cx3110x and omap2_mcspi do not busyloop during the DMA transfer. They use workqueues to allow sleeping, and completions for signalling. To be exact both cx3110x and omap2_mcspi do busyloop on certain occasions (waking up the chip etc.), but they do not busyloop during DMA. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
On 22 February 2008, Frantisek Dufka wrote:
Kalle Valo wrote:
Also CPU usage is very high because of busyloop when waiting till
DMA transfer is done. Tasklet, which executes the code can't be
easily preempted, as far as I understand kernel documentation. Maybe
it is possible to split tasklet into several parts, one of them
could be responsible for initiating DMA transfer, the other could be
activated on DMA transfer completion? This all is important for
video streaming as any excessive CPU resources consumption by WLAN
driver negatively impacts video playback performance.
Sorry, I'm not familiar with OMAP 1710 McBSP, so I can't comment.
I think you don't have to. From the code (sm_drv_spi_io.c) it looks like
McBSP is setup to use dma transfer with callback when it finishes
omap_request_dma(OMAP_DMA_MCBSP2_TX, McBSP TX, dma_tx_callback, ...
omap_request_dma(OMAP_DMA_MCBSP2_RX, McBSP RX, dma_rx_callback,
and the dma_tx/rx_callback() code just sets variable
spi_dma.dma__tx/rx_done to 1.
But the code that sends/receives the frame busyloops for it like this
omap_start_dma(spi_dma.dma_rx_ch);
omap_start_dma(spi_dma.dma_tx_ch);
while(!spi_dma.dma_rx_done) {
udelay(5);
}
while(!spi_dma.dma_tx_done) {
udelay(5);
}
spi_dma.dma_rx_done = 0;
spi_dma.dma_tx_done = 0;
So there is this nice dma architecture with callback used but the code
still spins up the cpu waiting for the done flag instead of sleeping.
So you need to be familiar with the driver and tell us if it is possible
to sleep inside cx3110x_spi_dma_read and cx3110x_spi_dma_write. And one
also needs to be familiar with kernel programming and waiting primitives
to suggest how to sleep and wait for the callback (if possible in this
context) and how to wake up the sleeping code from the dma callback.
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.
A solution that I tried to suggest might be to start DMA transfer, schedule
another tasklet to run after DMA transfer is done and exit from the first
tasklet. That another tasklet should get activated and do the rest of the job.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Kalle Valo wrote: ext Siarhei Siamashka [EMAIL PROTECTED] writes: 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 Thanks for enlightement to both of you, that was the part I was missing. 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. Nope, on N800 cx3110x and omap2_mcspi do not busyloop during the DMA transfer. They use workqueues to allow sleeping, and completions for signalling. How is it so when you cannot sleep inside cx3110x_spi_dma_read and cx3110x_spi_dma_write? There appears to be same code for N800 too just the body of those functions does not use McBSP but SPI API: spi_message_add_tail(t[1], m); spi_sync(lp-spi_device, m); Does it mean we can wrap McBSP usage into similar api and leave cx3110x otherwise alone without restructuring it? But still I don't get it, either spi_sync bysyloops or the semantics of cx3110x_spi_dma_write changed and it can return when the transfer is not yet done (??). Frantisek BTW, let's remove maemo-developers@maemo.org and move just to [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
On Feb 14, 2008 8:43 AM, Kalle Valo [EMAIL PROTECTED] wrote: [...] other users reported it too as Luca Olivetti pointed out. and it seems like the problem and fix is described here: http://internettablettalk.com/forums/showpost.php?p=134914postcount=15 at least for the 770 the fix seems to exist, What I read from the link, someone had written a workaround to try again whenever the chip is responding. That would good a feature, but I would like to get more information about what's happening in this case. I'm sorry. For some unknown reason, I thought that I notified you about this problem long ago, but appears that we only discussed this issue privately with Frantisek Dufka :( I encountered this problem when I was checking what is the maximum McBSP clock frequency that could be used reliably on Nokia 770 to speed up WLAN performance. To do this stability test, I just put the device on charger, established wlan connection and started a test script which repeatedly executed wget to download a large file, piping it to md5sum and verifying that the file always gets received correctly. That's probably one of the most simple stress tests that can be done :) People on ITT, who are suffering from this disconnection problem are running bittorent client software which probably stresses network to a much higher extent. Having kept this simple test running, I noticed that wlan network is getting stuck eventually. Sometimes very soon and sometimes after a long time. Checking dmesg log revealed the following lines: [84936.145721] We haven't got a READY interrupt from WAKEUP. (firmware crashed?) [84940.419342] TX dropped [84940.419433] TX dropped The symptoms are similar to what other people reported as https://bugs.maemo.org/show_bug.cgi?id=329 Initially I thought that it was the effect of overclocking, but could reproduce the problem even after going back to the standard frequency. With a simple patch that just retries operation on such error, wireless connection got stable. After a long test with the test script, no problems were detected. The following lines could be occasionally seen in dmesg log and it proves that there were potential connection drops encountered, but they all did not cause any troubles in reality (MD5 of downloaded file was always OK): [50559.494232] Dynamic PSM [50559.494323] PSM timeout 1000 ms [50622.038146] We haven't got a READY interrupt from WAKEUP. (firmware crashed?) [50622.038269] Try again... [50622.038330] succeeded!!! I'm attaching the same patch here. It is not very clean, but it does the job (for Nokia 770). And I have encountered other problems with WLAN driver that are yet to be solved. For example, sometimes speed drops to ~30KB/s (that's still an unresolved mystery to me). Also CPU usage is very high because of busyloop when waiting till DMA transfer is done. Tasklet, which executes the code can't be easily preempted, as far as I understand kernel documentation. Maybe it is possible to split tasklet into several parts, one of them could be responsible for initiating DMA transfer, the other could be activated on DMA transfer completion? This all is important for video streaming as any excessive CPU resources consumption by WLAN driver negatively impacts video playback performance. n770_wlan_retry_on_wake_error.diff Description: Binary data ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Siarhei Siamashka wrote: I'm sorry. For some unknown reason, I thought that I notified you about this problem long ago, but appears that we only discussed this issue privately with Frantisek Dufka :( I think it was discussed also in the Memory corruption during WLAN use bug too - http://bugs.maemo.org/show_bug.cgi?id=2006 [50622.038146] We haven't got a READY interrupt from WAKEUP. (firmware crashed?) [50622.038269] Try again... [50622.038330] succeeded!!! I'm attaching the same patch here. It is not very clean, but it does the job (for Nokia 770). Not seeing whole code now but I wondered before - isn't it possible just to increase timeout inside 'if (time_after(jiffies, timeout))' instead of two passes in loop? Also CPU usage is very high because of busyloop when waiting till DMA transfer is done. Tasklet, which executes the code can't be easily preempted, as far as I understand kernel documentation. Maybe it is possible to split tasklet into several parts, one of them could be responsible for initiating DMA transfer, the other could be activated on DMA transfer completion? This all is important for video streaming as any excessive CPU resources consumption by WLAN driver negatively impacts video playback performance. I wonder about this too. Sadly I am not so skilled in kernel and don't know rules for interrupts, sleeping in kernel, bottom halves etc. so splitting the code at least in 770 version (bit banging over McBSP and ugly udelay() busylooping for DMA transfer) is too much for my abilities. The N800 code looks nicer, where the CPU is burnt there? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Using OpenVPN over wifi (was: Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?)
Hi, on Roaming: I have quite good experience with roaming when using unencrypted wifi and securing it with OpenVPN. In this setup you have your access point connected to a firewall (with OpenVPN installed) and do encryption from wifi device to the OpenVPN enabled firewall instead of to the AP. What encryption settings? It makes a difference here. So here my short hint to people who use an unencrypted AP and have OpenVPN set up to secure the communication of their own devices. Do not use OpenVPN over TCP for the reasons Kalle already mentioned. TCP thinks that paket loss is a) a faulty connection b) bandwith is exceeded So TCP will slow down the connection to a minimum and raise the speed slowly until there are errors. TCP is good for wire networks but does not perform that well in wifi networks in the default setup. So if you use UDP for you OpenVPN there is no TCP messing with your connection and due to the UDP Protocol OpenVPN needs to handle the retransmissions which it does quite well :) I get about 20 to 30 Mbit (802.11g) throughput when using OpenVPN over UDP instead of about 5 Mbit throughput when using OpenVPN over TCP (this is measured using nload on my laptop when down and uploading files from/to my samba fileserver) Why not use WPA? Cheap access point to not allow for virtual APs So you can't have WPA for your devices and still offer free unecrypted access to the internet for anyone else. Why connecting the APs to the Firewall and not to the internal network? On the Firewall you can block all traffic from the wifi devices to your internal network and allow it if they are connected by openvpn. You still could allow non-openvpn devices to connect to the outside world (internet) but not to your hosts. HTH somebody :-) cya, Michael PS. I have read VNC many times already, in most cases I wonder why not using FreeNX for that?! Has anyone ported the client, yet? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
ext Benno Senoner [EMAIL PROTECTED] writes: The question is could it be that the socket remains stuck due to the roaming and is not able to recover ? TCP doesn't fit wireless networks that well, it usually takes a long time to cover from packet lost. Most probably what happens for you is that some packets are lost due to roaming, and TCP thinks that there's congestion and stops sending packets for a while. Most probably the connection would recover after a while, and the while here being several minutes with the default TCP settings. You think those time outs are really that long ? Yeah, they are quite long. I have heard about long timeouts with other applications using TCP. An easy way to confirm, if this is a TCP problem or something else, is to run ping in the background and see how long timeouts (ie. how much you see packet loss) you get with it. ICMP ping does not have any of problems that TCP has. the strange thing is if I go around the area with my Dell Laptop (under Windows) with VNC open it does not suffer from those extreme slow downs. I'm guessing that the laptop is roaming more aggressively than the N800 and TCP works fine because of that. iwconfig is handy. Also checkout iwevent, for example you can easily follow whenever roaming to different AP happens. so does iwevent emit an event when the n800 roams ? Yes. yes it could be useful, tanks for the tip I wil try. I usually run 'iwevent ' to get it running in the background so that I can easily see what's happening. Very handy. Aaah, I did not know that wlancond would overwrite those values, thanks alot I will try to use the method you proposed, perhaps it will help. gconftool-2 --set --type int '/system/osso/connectivity/IAP/bgscan_threshold' '70' gconftool-2 --set --type int '/system/osso/connectivity/IAP/bgscan_interval' '20' Sorry, I made a mistake here! Unit of bgscan_interval is milliseconds, not seconds as I say above. So the correct way to set background scan interval is this: gconftool-2 --set --type int \ '/system/osso/connectivity/IAP/bgscan_interval' '2' I'm sorry about this. As for the network lock ups we are experiencing (you have to disable,enable wlan on the n800 to make it work again) Does ping work when that happens? For example, you could try to ping your gateway. Also can you send me the output from dmesg after you experience this, please? other users reported it too as Luca Olivetti pointed out. and it seems like the problem and fix is described here: http://internettablettalk.com/forums/showpost.php?p=134914postcount=15 at least for the 770 the fix seems to exist, What I read from the link, someone had written a workaround to try again whenever the chip is responding. That would good a feature, but I would like to get more information about what's happening in this case. I hope it is not hard to implement this on the N800 too. I have a few 770 too so I can try to apply the fix described in the forum and see if my wlan lockup problems disappear. 770 has quite old software, so I would prefer if you can send me more information with N800. Since the 770 is out of production and we will buy n800 and successors it is fundamental that the n800 (OS 2008) gets this fix ASAP. With WLAN driver changes ASAP usually means quite a long time due to all the risks, testing and certification involved. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
ext Frank Banul [EMAIL PROTECTED] writes: I'm a home user with two access points. I've noticed that the N810 holds on to the connection with the established AP far longer than the 770 seemed to. I expect to never see low strength signals as the two APs cover my home nicely. But I have not noticed any problems associated with this apparent change in behavior. If you don't see any problems (slow connections etc.) I'm happy. The low signal itself isn't a problem. Thanks for the feedback. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
I'm a home user with two access points. I've noticed that the N810 holds on to the connection with the established AP far longer than the 770 seemed to. I expect to never see low strength signals as the two APs cover my home nicely. But I have not noticed any problems associated with this apparent change in behavior. It's also entirely possible that since I never manually disconnected the 770, rather I put the cover on, that I would not have noticed low signal strength even if it did exist. Frank On Feb 4, 2008 1:37 PM, Kalle Valo [EMAIL PROTECTED] wrote: It would nice to get real statistics about this, but my guess is that most of the people don't need roaming (think home users). Or if they need it, they need very rarely. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
ext Luca Olivetti [EMAIL PROTECTED] writes: Sometimes it even happens that the operator when roaming and wanting to use the N800 the VNC session got stuck and nothing works, so he has to power cycle it. This also happens with no roaming at all (i.e. the connection manager show the tablet as associated but it's not possible to transfer any data). It's random and not related to activity/inactivity (I can work for a whole day or get stuck after 10 minutes). Usually I just re-connect to the access point, I don't need to power cycle the tablet. I think that this is a different problem than what Benno is having. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
On Sat, 2008-02-02 at 23:18 +0100, Benno Senoner wrote: Any suggestions ? I find this wlan freeze problem a grave bug is this a defect in the N800 or a software bug ? One thing you could try is setting up openvpn: N800 as client, the VNC machine as server: it will secure your VNC connection, your connection will even survive the N800 changing its IP and since openvpn works over UDP it might help for network freeze. I use openvpn+VNC on my N810 to get access to complex applications running on my home PC from wherever I get wifi but I'm not roaming though. Sincerely, Laurent ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Hi all, I am trying to solve a big WLAN roaming problem which the N800 experiences and I think it is of interest to many as good WLAN responsiveness for the N800(and successors) is the key for smooth user experience, so please chime in with your experiences, ideas how to solve those problems etc. Some background: As WLAN access points we use 2 Buffalo Technology WHR-HP-AG108 http://www.buffalo-technology.com/products/wireless/wireless-ag-mimo-performance/wireless-ag-mimo-performance-broadband-router-and-access-point-with-high-gain-antenna/ using only the 802.11g radio (802.11a is disabled) We are trying to use the N800 with OS2008 for a data entry application which runs on a linux server. Basically in order to keep things simple we run the maemo vncclient on the N800 and the linux server simply provides a 800x480 VNC screen where the app runs in. It works fine and the speed is more than adequate BUT since the area the data entry operators work in cannot be covered by a WLAN single access point we set up 2 APs on different frequences (for example 1 and 11). The problem we have is that even though within the working area you always get a strong signal from at least 1 AP the N800 sometimes behaves very erratic. For example when moving from AP1 to AP2 It seems like the N800 tried to stay associated as long as possible with AP1 even though AP2 is much stronger and AP1 can barely exchange any data at all with the N800 as it is at the border of the coverage area. VNC will become very slow and impossible to work with. Sometimes it takes 1-2 minutes for the nokia to realize that it should roam, totally unacceptable for smooth operation. I disable wlan power saving (in the maemo control panel) in order to avoid problems when the n800 wakes up from standy, keep in mind the operators move alot on the area and often they will not touch the n800 for several minutes. I even ping the IPs of the n800 from the linux server in order to make sure that they don't sleep. Sometimes it even happens that the operator when roaming and wanting to use the N800 the VNC session got stuck and nothing works, so he has to power cycle it. VNC uses a single TCP socket to exchange data between server and client. The question is could it be that the socket remains stuck due to the roaming and is not able to recover ? I could try to add an external watchdog which keeps a socket open with the server and in case that this happens restart the vnc client, but I am not sure if this will work. Keep in mind that using a Windows laptop and the same vnc client code in the same area where the N800 are employed works perfectly, so the network coverage, bandwidth and server speed is excellent. I tried to install wireless-tools and play with both iwconfig sens (sensivity) parameter http://maemo.org/development/documentation/man_pages/iwconfig.html and with iwpriv parameters: http://maemo.org/development/documentation/man_pages/iwpriv.html testing the follwing commands: set_scanthres (scan threshold) and set_scanint (scan interval) iwconfig sens seems to have no effect at all iwpriv set_scanthres as well does not seem to produce any improvement (tried with values ranging from -100 to 0) set_scanint seems to make some difference but it does not solve the problem. the default value is 6 which means as far as I understand that the wlan card in the N800 tries to scan for new APs each 60 secs. I tried to lower this value to 25000 , it sometimes leads to faster roaming but since the scanning takes about 1 sec it is very disturbing that during that time you cannot transmit any data (because the radio tries all frequencies from 1 to 11) and the VNC GUI thus freezes. Is it possible to specify which frequencies the N800 should scan when roaming ? i think this is a very important feature as it can speed up roaming speed considerably. There are only 3 non overlapping frequencies anyway (1,6,11) and usually 2 frequencies are enough so if the n800 had a setting scanfrequencies=1,11 we could scan much more frequently without disrupting the data flow for a long time. if the seleciton of scan frequencies is not implemented in maemo yet please do it ASAP as it make it more smooth to use of the N800 in larger WLANs. Any other wlan software parameters that I perhaps missed which could improve the situation. So any idea how to make sure that the N800 roams smoothly ? What are your experiences ? I can change the access point model without problem if you tell me what access points provide good roaming performance in conjunction with the N800. Any access points brands,models which gave you good experience while roaming ? years ago I used a HP IPAQ and regular 802.11g access points (DI serie) and the roaming was excellent, so I can hardly believe that Nokia did not do its homework and did not think about this problem. After all the N800 is an internet tablet and good and smooth WLAN connectivity is the key selling point for smooth internet experience.
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
En/na Benno Senoner ha escrit: Sometimes it even happens that the operator when roaming and wanting to use the N800 the VNC session got stuck and nothing works, so he has to power cycle it. This also happens with no roaming at all (i.e. the connection manager show the tablet as associated but it's not possible to transfer any data). It's random and not related to activity/inactivity (I can work for a whole day or get stuck after 10 minutes). Usually I just re-connect to the access point, I don't need to power cycle the tablet. Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Thanks for your information Luca ! what do you mean with t's not possible to transfer any data ? you mean VNC gets stuck or the whole network layer of the n800 ? So basically once it gets stuck you cannot even open the brower and access a webpage ? Please elaborate. And with reconnect the the access point you mean click on the wlan icon, disconnect and reconnect ? Can wlan disconnect, reconnect sequence be automated in some way ? for example can I do the following: run watchdog, detect whether vnc is still transfering data if not then kill vncviewer and do ifdown wlan0 ifup wlan0 --- Any suggestions ? I find this wlan freeze problem a grave bug is this a defect in the N800 or a software bug ? thanks everyone for your suggestions, regards, Benno 2008/2/2, Luca Olivetti [EMAIL PROTECTED]: En/na Benno Senoner ha escrit: Sometimes it even happens that the operator when roaming and wanting to use the N800 the VNC session got stuck and nothing works, so he has to power cycle it. This also happens with no roaming at all (i.e. the connection manager show the tablet as associated but it's not possible to transfer any data). It's random and not related to activity/inactivity (I can work for a whole day or get stuck after 10 minutes). Usually I just re-connect to the access point, I don't need to power cycle the tablet. Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
En/na Benno Senoner ha escrit: Thanks for your information Luca ! what do you mean with t's not possible to transfer any data ? that you can't ping, cannot resolve hostname, ssh sessions hangs, can't load webpages, etc., you get the idae you mean VNC gets stuck or the whole network layer of the n800 ? I don't use vnc, but I guess it would stop working too, yes So basically once it gets stuck you cannot even open the brower and access a webpage ? Please elaborate. see above And with reconnect the the access point you mean click on the wlan icon, disconnect and reconnect ? Yes. [...] I find this wlan freeze problem a grave bug is this a defect in the N800 or a software bug ? I don't know. See http://internettablettalk.com/forums/showthread.php?t=15336 Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
