Testing 802.11n

This posting is a follow-up to This Earlier Posting.

While I was testing 802.11n, I still had my router on “Mixed Mode”. In the meantime, the connection speed indicated on my laptop ‘Klystron’, using the command ‘iwconfig wlan0‘, had dropped from 72.2 mbps to 7.2 mbps. And while I could pull my hair out trying to figure this out, in reality the explanation for this seems simple. Since the previous posting, some WiFi device of mine established a regular, 802.11g connection, thereby dropping my whole network out of 802.11n mode.

I was able to solve this, by going back into my router settings, and instead of allowing b/g/n Automatic determination, set it to “N Only”. Doing so also rebooted my WiFi, and kicked all my devices off, so that everything needed to reconnect.

I suppose that one aspect of this which is not as pretty, is the fact that I generally need to reboot ‘Klystron’, and thus need to reload the kernel-module that runs its WiFi chipset, before that laptop indicates updated, 802.11n connectivity. But after doing that as well, I found that the command ‘iwconfig wlan0‘ indicated readiness to transfer data at 72.2 mbps again.

This time, I am on channel 6.

Having done so also implies, that if at some point in time I wanted to join my WiFi with an older device, that does not have this capability, that device will fail to connect.

The eventual result from this experimentation is, that I cannot find any practical way to achieve the data transfer speeds that 802.11n eventually permits, and this can be due to the fact that I am transferring data from and to an older, slower computer.

And while all this indicates performance issues, nothing so far indicates driver stability issues, on ‘Klystron’. I am still waiting for those to happen.



Testing 802.11n

I have done some reading, into the subject of 802.11n speeds, over the WiFi chipset of my laptop, which its Realtek driver, supposedly supports.

The main fundamental fact to know about this, is that whether 802.11n speeds are in fact enabled, is determined from the router, and not as much from the local driver, where for all I know, the support could be without error.

This feature requires, that all the access to the router is set for 802.11n enabled, including in my case, the Guest Network, which was not so previously. More specifically, the form of security must be WPA2, not WPA1 or WEP, even for any Guest Network.

Where previously my client was set to using Channel 11, it now registers as using Channel 1, which means that although the used frequencies are in the same band as before, they can now span a larger part of this band, to support a single download or upload.

Further, in this mode, the slowest device on the LAN, also determines the fastest speed at which 802.11n will work, even when active. Hence, if I had an older smartphone and a tablet with poor or no 802.11n support, too bad, that tablet would set the limit, on how fast my WiFi speeds are going to be. In fact, both my phone and tablet are relatively recent, and have not interfered much in this trial.

When I run the ‘iwconfig‘ command on the laptop ‘Klystron’ as root, it tells me that “802.11bgn” is enabled, but that the maximum speed available will be ~72mbps. What this states, is the hardware limit of my WiFi chipset. This number already falls short of what 802.11n should allow, but is nevertheless the limit of my chipset.

Because of the DSL package I subscribe to, downloads to my LAN from the internet are limited to a much slower speed. Thus, I cannot use the Internet to test this. But I can use transfers from one computer on my LAN to the other, to test what my WiFi speed has become.

It used to be, that if I synced files between ‘Phoenix’ and ‘Klystron’, this local transfer was limited to about 1.5 Megabytes per second, while now that I have changed my configuration as described, I can get this transfer to take place at 3-4 Megabytes per second.

This low bitrate should not be alarming, because it is partially determined by how fast ‘Phoenix’, the older of the two machines, can encrypt the data, and the decryption of the data at that rate already consumes about 25% of the CPU time, on all 4 cores, belonging to the faster computer ‘Klystron’. This is not a speed test.

I have been wondering, whether I could have been suffering from an additional problem on ‘Klystron’, to whatever its behavior was when I simply closed the lid. And 2 additional things which may have been going wrong, could have been repeated requests from ‘Klystron’, to my router, of IPv6 addresses, while another could have been some half-formed use of 802.11n.

The way I now have it, any use of global IPv6 addresses from my laptop have been disabled, in ways that are safer for the configuration than what I had before. And support for 802.11n is currently enabled. If there is going to be some sort of malfunction, associated with this latter, enabled feature, I would like it to happen now, so that I can determine with some certainty, that there was ever an 802.11n problem with this chipset and driver. Personally, I am skeptical.



Understanding The Intricacies Of KDE Logic

In This Posting, I was describing a problem with my Linux laptop named ‘Klystron’, in which the laptop would take itself off my WiFi, apparently every time I closed the lid.

In the short term, there was a solution to this problem. I was able to go into my KDE Power Management Settings, where I had set the action on closing the lid to “Lock Screen”, and I was able to change this setting to “Do Nothing”. The suspicion had never occurred to me, that there could be two distinct behaviors:

1) After (x) minutes, the screensaver can come on, and if the attempt is made to interrupt the screensaver after (y) additional seconds, that screensaver can ask the user for his password.

2) The user can ask KDE to “Lock The Screen”.

According to the way KDE works, (1) and (2) are as different as Night and Day. So apparently, Locking The Screen is also supposed to mean, Disconnect From WiFi. But the screensaver asking the user for his password to stop, does not mean Disconnecting The WiFi.

Live and Learn.

And actually, one main reason for which I do close the lid usually, is the fact that the laptop is more protected from dust etc., with the lid closed.


(Edit : ) This laptop setup uses Network Manager. So just this afternoon I left-clicked on the Network Manager icon while connected to my home WiFi, and then drilled deeper into its GUI, to adjust which settings would be displayed as additional information about the network I am connected to. Network Manager is somewhat flexible in this GUI layout adjustment, but does not really allow settings to be fine-tuned in the same way.

Some KDE setups use ‘WICD‘ instead of ‘Network manager‘.

What I saw, was that there was no specific parameter to display, for whether a WiFi network should disconnect, on locking the desktop.

The only relevant WiFi-related detail I was able to add to the display, was “WiFi Band”, which could plausibly have complemented “WiFi Security”, which was already included. For my home access point, WiFi Band now displays “b/g“, as a result of further troubleshooting steps of mine.

I have since disabled 802.11n from the kernel module…

This means in practice, according to my logic, that the behavior I described in this posting, of cutting out when I close the laptop lid, cannot be deliberate. If it was deliberate, it would also be something which can be configured differently. And thus, this can also not be due to any translation error.

Therefore, this is a bug, and one I can now reproduce any time I want to.


Still Having Issues with WiFi Going To Sleep

In This Posting, as well as This Posting, I wrote at length, about a misbehavior which the WiFi on my laptop ‘Klystron’ has, in which the WiFi seems to go to sleep, after periods of disuse. The individual applications and programs still seem to behave locally as though connected, including my ‘gkrellm’ widget (which shows a low level of activity), but in fact the external network shows that I am no longer connected.

This seems to be related somehow, to the fact that this laptop has the Realtek WiFi chipset, with the related Linux driver for ‘rtl8723be’.

I have just recently found out, that this behavior was triggered, by my closing the laptop lid, and by nothing else. Because I did not know at an earlier point in time, that closing the laptop lid triggered this condition, I was also not able to troubleshoot the problem better. For example, I had thought that maybe keeping the desktop manager locked with a screensaver, might have been triggering this, and so when next the desktop manager was able to stay locked for a full day – but with the laptop lid open – without this behavior setting in, I had thought prematurely that the problem was solved.

This problem persists. And I have also tried going into the KDE Advanced Power Settings, and unchecking the box that says “Never Prevent An Action On Lid Close”. On the distributions that I have used, this user-setting defaulted to checked. But even when this box is not checked, closing the laptop lid still causes the behavior.

I still do not have a working solution to this problem.