Klystron Kernel Update Ends Suspend To RAM Experiments.

Only a few days ago, because that laptop is fully subscribed to Kanotix, the computer with the network name ‘Klystron’ received another kernel update, this time to version ‘4.4.0-34-generic‘, which for some reason also goes by the name ‘4.4.0-35Kanotix‘. This has had slightly sad, but also good consequences:

  1. I can no longer allow Klystron to Suspend To RAM, as by now, doing so sets the time-last-modified of the super-block of its FS into the future. In fact, after a recent reboot, the log-in manager also reported to me, that it was unable to enter the home directory of the main user. This gave me quite a shock, until I noticed, that I was still able to log in as the auxiliary user, after which a full reboot also fixed the super-block. What this means is that all my experiments with Suspend To RAM must end, including hoping that its WiFi chip-set will work after resuming. But, I had written several times, that the performance of the WiFi had improved, as long as I do not suspend the laptop…
  2. I can now focus on a user-configuration, by which closing the laptop lid locks it, but hopefully, the WiFi will stay connected. In hopes of improving the chances of that, in addition to the fact that support may have already been improved in the latest kernel versions, I have additionally set my router only to use a signal-width of 20MHz, i.e. not to use ‘channel bonding’. My logic behind that is, that higher speeds might look good, as long as the signal strength is good. But to cope with the possibly weaker signal of the lid being closed, a narrower WiFi signal-width, as set from the router, may help improve reliability.

But whether that pans out, only time will be able to tell. Even if it does not, simply having the WiFi disconnect and then reconnect, as I reopen the lid, should not be the end of the world.



Firmware Update Today

One subject which I have written about at length, is the apparent instability of the Realtek WiFi chipset, on my laptop named ‘Klystron’. If anything is likely to improve that, it would be a firmware update.

Well just today, a firmware update was installed, to ‘linux-firmware’ version 1.158, and this was also followed by a reboot.

After the reboot, I tried to test whether my 802.11n WiFi performance had improved. One main test which I did, was to transfer a 500MB file to the local laptop, from a Samba server on another computer on my LAN. And what I found, was some improvement in peak speed, to 2.0 Megabytes per second, corresponding to 16 mbps.

Before I could obtain that speed however, I first needed to restart the Samba server, which had been running on the originating computer since April 17. And this detail helps show, how speed limitations in transferring, may be due to numerous problems, other than the actual link quality of the WiFi client.



My Linux Laptop ‘Klystron’ And 802.11n Again

The Linux laptop I name ‘Klystron’ has been running in a single session, for 1 day and 7 hours so far, and with its lid in the open position, and remained connected to my WiFi in 802.11n mode.

Further, the last time there has been any real issue with this mode, occurred several days ago, and several reboots ago. On the rare occasion where the connection simply quit while in use, there were error messages in my ‘syslog’, that vaguely pointed towards an 802.11n problem, according to my having Google-d those error messages.

But the behavior was introduced more recently, that simply closing the laptop lid would cause it to lose contact with my WiFi, without the actual connection being reported as ‘down’ by ‘Network Manager’, and without resulting in any error messages. This situation would typically reverse itself, within seconds of my unlocking an active session, and would also reverse itself, without resulting in any Notifications. The laptop would simply never know, that overnight, there was no data received and transmitted over WiFi.

Similar but not identical results were obtained, while connected in 802.11g mode.

Given that nobody has ever asked me the question, of whether maybe my WiFi signal could already be weak where this laptop is situated, I would say that it remains unproven, that this setup has any 802.11n issues per se. And so, because I know how frustrating it can be to do so, I would also not encourage coders to start looking for errors very carefully, which might not even exist in the software, or in the firmware.

You see I still have this peculiar notion, that there can be something impeding the efficiency of the actual WiFi antenna, which could account for most of the instability I have reported. And I also have this peculiar notion, that the performance of an antenna is based on wave dynamics, and not on the dynamics of Quantum-Mechanical particle representations, of radio signals.