"ext Benno Senoner" <[EMAIL PROTECTED]> writes: > 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.
I'm always happy to hear any experiences users have, good or bad. Even though how much we test internally, the best feedback we get is from you users. There is no substitute for that, and I guess that's why Open Source works so well. I want to thank you in advance for writing this excellent report about your problems and how you have tried to solve it. It's very easy for me to understand what's happening after reading your mail. Hopefully I can help you here. > 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) What encryption settings? It makes a difference here. > 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. If I recall correctly, the current threshold for backround scanning is -85 dBm and the interval is 60 seconds. I think you suffer from these settings. > 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. I doubt that this is a WLAN power saving problem. > 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. That's bad, but I guess not a WLAN problem per se. Applications running in mobile devices, like N800, need to be prepared for total connection drop, always. > VNC uses a single TCP socket to exchange data between server and > client. This is important, good that you mentioned it. It helps me to understand the problem. > 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. > 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. That's a bit hackish, let's try to find better solutions first. > 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. Good, motivation always keeps one's mind fresh ;) > 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 iwconfig is handy. Also checkout iwevent, for example you can easily follow whenever roaming to different AP happens. > testing the follwing commands: set_scanthres (scan threshold) and > set_scanint (scan interval) wlancond overwrites these settings, so you have to be really careful when testing these. Otherwise you don't know what you are testing. It's better to change the settings for wlancond by writing them to gconf. Here's an example where threshold is changed -70 dBm and interval is 20 seconds: gconftool-2 --set --type int '/system/osso/connectivity/IAP/bgscan_threshold' '70' gconftool-2 --set --type int '/system/osso/connectivity/IAP/bgscan_interval' '20' Reboot the device after changing the settings, just in case. I don't remember how wlancond reads the settings from gconf. > iwconfig sens seems to have no effect at all Yeah, forget that one. > 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. Better to change settings for wlancond (see above). > the default value is 60000 which means as far as I understand that > the wlan card in the N800 tries to scan for new APs each 60 secs. Correct. > I tried to lower this value to 25000 , it sometimes leads to faster > roaming I think you should change the bg scan threshold -70 dBm and bg scan interval to 20 s. I think we used those numbers in OS2007 and roaming should work better. > 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. Yes, that's an annoying problem as well. Currently the scanning parameters in the WLAN driver cx3110x are really conservative. If you can recompile the driver, you might want to try different scan parameters found in sm_drv_open(): struct obj_scan scan_params = {-1, 80, 200, 60000, 80, 140}; The unit is TU, meaning 1024 microseconds. You want to try with the two last values, 80 (amin) is the minimum time spent on a channel and 140 (amax) is the maximum. Change them to something like 10 and 30, for example. > 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. I think it's easier if you try to make scan parameters smaller. Especially if you don't have any other APs on the area and you change amin to something ridicously small. Practically that should have the same effect as disabling some of the frequencies. > 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. Sorry, but I don't buy the idea. It's an ugly workaround for a problem and I'd rather solve the real problem. > Any other wlan software parameters that I perhaps missed which could > improve the situation. You might want tune TCP as well. As I already mentioned, TCP is not really suitable for wireless connections. We just to have live with it, I guess :/ I'm far from a TCP expert, but I'll to give you some hints. First idea which comes to mind is to change the congestion control algorithm. I have heard that Westwood might one possible choise http://en.wikipedia.org/wiki/TCP_Westwood http://en.wikipedia.org/wiki/TCP_Westwood_plus I personally use that whenever having bad GPRS connection on trains, but I have no clue if it really helps or not. In my laptop I can enable with this: # sysctl -w net.ipv4.tcp_congestion_control=westwood I don't remember if it's already included OS2008 kernel. If not, kernel recompile is quite straightforward. Also changing TCP parameters like tcp_frto and tcp_keepalive_time might help (or not, I don't have any experience of those). See tcp(7) manual page for more. Better yet, try to find a TCP expert :) > Imagine if an N800 user roams through an university campus and wants > to listen web radio or stream a video from the web. If the N800 > behaves like in my case (which is a simple network with 2 APs) the > radio and the vide owill constantly freeze leaving the user pissed > off. The same happens if the user wants to use some VOIP client like > skype, SIP clients etc. I know that for pure web page viewing roaming > speed is not that important but the N800 is a multimedia tablet and > smooth multimedia performance is a must. You are the first person I have heard complaining about roaming with OS2008. If someone has had roaming problems, I would like to hear about it. But basically this is a compromise between power consumption and connection quality. Currently we have strived for better power consumption and unfortunately your use case suffers from that. I don't know if it's correct decision or not. I'm all ears. > I hope the N800 hardware is not flawed and that a fix can be found, > thanks everyone in advance for your advices and help ! This is not a hardware problem, if that's what you are referring here. > I think this kind of roaming performance tuning is important to many > others too 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. > and I hope that they can profit from the discussion that will come > out too. At least I will certainly benefit from the discussion. -- Kalle Valo _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
