Software and hardware annotations, 2004

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

December 2004

I have been trying to get my ill-fated USR 5410 wireless card to work with Linux. Unfortunately the manufacturers of the chipset on which the card is based, Texas Instruments, have chosen to shun the open source community, and to support a proprietary Linux wrapper for their proprietary MS Windows driver.
There is an effort to develop a partial/experimental free software driver but this is held back by the unwillingness of Texas Instruments to cooperate, to the point that the first thing the driver prints on loading is this:
acx100: It looks like you've been coaxed into buying a wireless network card
acx100: that uses the mysterious ACX100/ACX111 chip from Texas Instruments.
acx100: You should better have bought e.g. a PRISM(R) chipset based card,
acx100: since that would mean REAL vendor Linux support.
acx100: Given this info, it's evident that this driver is quite EXPERIMENTAL,
acx100: thus your mileage may vary. Visit for support.
which does not sound very encouraging. Well, the driver almost works under 2.6.10, which however seems to have stability problems, but I could not try it under 2.4.29-pre3 as the yenta_socket PCMCIA driver for my Toshiba S2800-500 laptop just locks up the system.
More bad news with the 2.6.x Linux kernel series: inexplicably after 10-20 minutes of use of 2.6.10 both my USB mouse and networking connection suddely stop working, and this did not happen with 2.6.10-rc2 (I did not use 2.6.10-rc3). As far as I have noticed there are no other symptoms. I have tried to reset/reinitialize things but neither the USB mouse nor my network connection work until I reboot. I suspect some kind of memory corruption. I have switched back to the 2.4.x series for now, using the 2.4.29-pre3 version. Since the report of a user on IRC that GNU C 3.3.5 seems to generate erroneous code in some cases, I have recompiled both 2.6.10 and 2.4.29-pre3 with GNU C 3.4.4, but this does not change the problem with 2.6.10
It has been my habit to enable all the internal checks in the Linux kernel, following Hoare's observation that to disable checks in production is like keeping a lifejacket on when swimming in a pool and removing it when swimming in the ocean. One of these checks has been to enable the memory allocator's internal checker. Well, the bad news is that in the 2.6.x kernel it makes things so much slower that it is nearly intolerable, cutting not only network and disk performance to less than half (because of increased system time) but also X usage, I guess as X uses the IPC heavily to update the screen. Howevert the good news is that so far no memory problems have been detected.
An interesting warning about a little known but important drawback of WiFi:
> Most of the time everything behaves as expected (iwconfig reports
> back Link quality of 88/92, -16dbm signal type figures), but
> occasionally the connection dies and iwconfig reports 0/92 link
> quality and shows something like 107/153 for signal level. It
> normally connects again within a minute or so.

I think I've already said this in this august forum, but here it is again...

WiFi is free of license fees because nobody else wants to use the 2.4ghz
band, being as it is, full of interference from microwave ovens. So if one
of your neighbours has a faulty microwave oven, your connection will die
whenever they microwave something.
Fascinating discovery about recent Linux 2.6 kernels: the usb-storage driver load but does not register itself with the SCSI subsystem. One has to use the ub driver to handle flash USB storage devices.
There are however two interesting and vitally important details which can only be learned from a thread in the linux-kernel mailing list:
  • If the ub driver is compiled, the usb-storage code stops handling the devices handled by the ub driver, that is all USB storage devices that implements the bulk only subset of the transparent SCSI protocol, in other words usually flash devices.
  • The ub driver is still highly experimental, it supported by DEVFS but not in legacy device name mode, and is meant to be more reliable than usb-storage for slow devices (like flash card readers).
This may be a good development, as so far USB mass storage devices have been notoriously unreliable, in particular as to error handling (under MS Windows too...).

November 2004

In the advice pages of an ASP with the usual cool to look but slow to load pages I have noticed some surprising advice, that to improve page loading times one should have a browser cache that is as small a possible, both for Mozilla and Firefox, and in particular for MS Internet Explorer. The same notes then give a series of steps to reduce the cache to the minimum size possible for those browsers.
If this advice makes sense, it must be because browsers search through their caches sequentially, which of course is goin to happen is they just keep them in one or a few directories and then merely open the right path.
Indeed this is what happens with Mozilla and similar browsers: all cached objects are in a single directory. Fortunately in my case I changed the default cache size to something like 12MiB, so I end up with only around 140 objects in the cache, for an average object size of around 8KiB.
With MS Internet Explorer the default cache size is a fixed percentage of the size of the partition in which MS Windows is installed, and on a modern disk with large partition sizes that can amount to hundreds of megabytes (and one person I work with found that MS Internet Explorer had defaulted his cache size to 1050MB).
That would imply, assuming an 8KiB object size, something like hundreds of dozens of thousands of objects in the cache. I looked and at least in very recent versions of MS IE the Temporary Internet Files directory has subdirectories, but that's always and only four, which helps only a bit, one can still end up with a dozens of thousands of cached objects per directory.
While I think that no cache or a minimal size disk cache are not a good idea, a cache of a few megabytes and a hundred objects should be fairly fast and still be useful for caching.
Also, the SharpDevelop search bug mentioned before seems to have been fixed as version 1.0.2 at least/last.
I have been experimenting quite a bit with wireless under Linux, and that has been quite instructional. One has to be very, very careful in choosing exactly the right model of card, and there is lots of especially shoddy stuff in wireless.
The other point is that it is ever more apparent that the 2.6.x vanilla kernel series is a development series, and that stable kernels are only the specially selected and heavily tested and patched kernels in distributions.
I have for now finished some experiments in making my deskside PC quieter, even if it has a fair bit of stuff in it. The two main conclusions are:
  • The biggest factor in noise is the speed of rotation of fans, and the related speed of air through them. It is much better to have wide fans rotating slowly. Other details also matter, more below.
  • The second most important factor is the whirring noise of hard disks. The clacking noise made when seeking seems a lot less objectionable. Other details also matter, see below.
  • The third biggest factor is vibration. especially hard disks, but fans too, impart vibration to the case, if it is not deadened, and that can produce a bit of rattle.
As to fans, some of the details are:
  • At least 80mm wide fans rotating at not more than 2500rpm, and possibly at not more than 1500rpm. 120mm rotating at 2000rpm are particularly good, but they don't always fit (for example in my case they don't).
  • Slower, wider fans can be of lower quality and still be quiet. Narrow, fast fans that are quiet requires a lot of good quality engineering, and that is in short supply.
  • Multiple wider, slower fans can be much quieter than a single small fast fan, and ensure better air circulation.
  • Beware of sleeve bearing fans, their bearings need to be cleaned and relubricated, with something like WD40, every 6 months of continuous operation, or more frequently; however sleeve bearing fans are usually quieter than ball bearing fans, which can rattle. I have read that best fans are ceramic sleeve bearing based, which don't need lubrication (but I guess they still need occasional cleaning).
  • The noise made by a fan can significantly increase with time.
  • A single front front case fan and a single back case fan seem to be quite enough, and the front one may not be totally necessary, but in my case it does not add to noise, and improves air circulation and temperature a bit.
  • Reducing the speed of one 80mm fan switching it to 7v (wiring it between the 5v and 12v lines instead of ground and 12v) from 2500rpm to 1500rpm reduced noise quite a bit for my back case fan. Most of the noise reduction was reduction in the whooosh due to the speed of the air passing through it. The reduction in speed in my case caused no increase in temperature.
As to hard disks, some details:
  • There is, or at least was, some wide variation in the noise output of various disk brands and types. Some, usually slightly older Maxtor and Western Digital disks, tend to have fairly noticeable whine. Recent Seagate and Hitachi DS disks tend to be noticeably quiet.
  • The noise made by the arm when seeking can be loud but not annoying like a whirr, and on deskside machines disk activity is usually rare, while the disk whirrs all the time; putting a non laptop disk on power management and making it sleep often is not good for it.
  • Acoustic management, now present on most disks, which trades higher access times for less noise doing seeking, can be very effective at reducing the noise of arm movement while not increasing access times a lot.
  • Fewer bigger disks can produce less noise than more smaller disks.
  • Disks that have lower rotation speed can be quieter if only because of less vibration.
  • Laptop, 2.5", disks are much much quieter than desktop, 3.5", disks but cost more and are noticeably slower. They also run cooler, but that does not really decrease heat enough that reduces the noise to cooling.
Vibrations are a big problem too. Putting in dampeners, and ensuring rigid mountings especially for the hard disk, helps. Also, some CD and DVD readers and writers at top speed rotate too fast and are very noisy, as well as potentially dangerous. Choosing units with better balancing and the ability to limit speeds can be a good idea.
These have been long notes, I shall transfer them to another more topical document.
I am doing quite a bit of work doing XML based data conversions using C# and .NET, and I am fairly plased with both. There are quite a few bizarrities though with both, but they are fundamentally fairly sound. I also like the fairly recent and decent availabity of tools for C#/.NET development. For example SharpDevelop is a pretty good free software development environment. I have read whining about it not having an integrated debugger, but that is really a minuscule problem, as a debugger is usually just a crutch for bad programmers (unfortunately there are many). But the search command is buggy, which is far more of a disappointment. Still, the bug is not too grave.
I just noticed that two operations I commonly do are heavily CPU bound in the 2.6.9 kernel:
  • Transferring data over a 100MHz Ethernet Intel EEPro 100 interface takes 100% of CPU (system time) on a 800MHz PIII at a transfer rate of somewhat less than 10MHz.
  • Copying between two 40-50MiB/s disks is limited to approximately 24MiB/s when CPU (system time) hits 100% on an Athlon 2000+.
These seem to point to severe performance problems in the buffer cache manager, and the network stack (the EEPro 100 problem happens with both the e100 and the eepro100 drivers, so perhaps it is not the driver).
Some interesting very rough testing on how much memory is consumed by Konsole and URXVT:
Application First instance Futher instances Further tabs
Konsole 5.0MiB 2.5MiB 0.25MiB
URXVT 1.2MiB 1.2MiB -
The memory usage profiles are very different; Konsole has much bigger fixed costs, but tabs are very cheap.
I typically use 3-4 virtual desktops each containing with 1-3 terminals, so i would need either about 8 instances of URXVT or 3-4 of Konsole with a couple of tabs each on average. In my case URXVT is chaper.
Whichever one prefers, I can only feel outrage at the obscenely high memory usage numbers for both of them. URXVT is also considered to be one of the lightest X11 terminal emulators. Bad programmers rule!

October 2004

Ah, lots of amusing discoveries in the past week...
I was doing some bandwidth tests FTP'ing between by home PC and laptop across a 100MHz switch, and getting only about 400KiB/s. So I looked into it and discovered that CPU usage was around 100%. Strange, FTP is anything but IO bound.
After a bit of investigation I discovered that vsftpd was doing a sendfile(2) call. I used the use_sendfile=NO configuration option and I got double the transfer rate, at the same speed. Still only about 1MB/s, and still 100% CPU usage.
So I tried to change the driver for the laptop (my desktop with 3C905B card has no such problem if I disable sendfile) between e100 and eepro100. No improvement. Ha! I suspect it is a 2.6.x related issue, when using 2.4.x it was doing the usual 6-7MB/s. Mystery though..
Trying to make a ZyDAS 1201 wireless USB gizmo work with kernel 2.6, this implies loading the firmware using the dodgy hotplug subsystem, kernel panics. Giving up... I suspect that as usual it is the dodgy USB system in 2.6.x, which seems to be changing a fair bit.
Done some C#/VB.NET/COM/XML databased extraction and conversion program, using the free-of-charge .NET SDK from Microsoft and SharpDevelop which looks pretty good, as well as other C#/.NET oriented editors, including XEmacs, VIM, and jEdit, which has a pretty good C# mode. Also Eclipse has a nice C# plugin. It is ironic that jEdit and Eclipse are written in Java.
One of the more amusing aspects of SharpDevelop is that it supports both C# and VB.NET, and it has a menu entry that allows translating a C# source project into a VB.NET source project and back. Quite impressive, but less than it appears. By looking at the converted source it is readily apparent that VB.NET is actually almost exactly the same language as C#, feature for feature, with just a different, vaguely Basic like syntax (no braces, no semicolons, slightly different keywords). Probably the compilers for the two languages are identical except for the parser.
I have finally bought myself an ADSL/Ethernet/wireless modem/router to replace the USB ADSL modem I had, and in particular its damnable driver that also depends on two dodgy Linux kernel subsystems (USB and ATM), and would need a fair bit of updating to fit into kernel 2.6.x.
So finally I switched to a 2.6 kernel. First I tried, and got the usual hard crashes because of bad memory allocation and/or improper locking in various places, but usually in the some ACPI module.
So I tried 2.6.9-rc3, and disabled the loading of ACPI modules, and all seems fine so far. I was keen to try the new 2.6 kernel series and its new features, especially the elevator.
Also, I reckon that the vanilla kernel is now too large and complicated to be maintained by volunteers, and I think that Linus is fully aware of this.
My expectation is that the only parts that will reliably work in vanilla kernels will be those that are needed on the workstations that kernel developers use.
There has been a definite shift in that: it used to be that kernel developers were mostly riff-raff working at poor universities or for hobby, using small old computers with a bewildering array of dodgy configurations.
Now mostly they have been hired on huge salaries by big corporations, and they can now afford by default really nice corporate style workstations, lots of memory, really fast CPUs, and huge Ethernet bandwidth and to the outside world.
Typically I would expect they look like Dell high end workstations. Well, the kernel subsystems exercised on such machines will be those that work. They won't be laptops, have ATM, IPv6 or ADSL, or much in the way of ACPI or USB peripherals, usually they will not have AMD CPUs, and they will virtually never swap, or need much in the way of optimization. Power to spare. What a change!
Spotted on LinuxToday a link to an interesting update on SATA support in the Linux kernel.
Lockups with Linux 2.4.27 and the USB cxacru driver. From the stack backtrace it turns out that the lockup is trigged by cxacru but actually is a bad pointer inside the sctp code:
Adhoc e091bbc2 <[sctp]sctp_make_heartbeat_ack+12/70>
Adhoc e0b1098c <END_OF_CODE+1a2c9/????>
Adhoc c02144a8 <uhci_call_completion+1b8/200>
Adhoc c021453c <uhci_finish_completion+4c/70>
Adhoc c010a558 <handle_IRQ_event+48/80>
Adhoc c010a713 <do_IRQ+83/e0>
Adhoc c010cbe8 <call_do_IRQ+5/d>
I had loaded the sctp module thinking I would experiment with it, but it does also actually run, and it seems the interrupt time code is not quite bug free yet. Using two newish half maintained interacting drivers together is pushing it... I have just disabled sctp.
Getting ever more annoyed with Debian, and in particular the bootup script situation. I think that the sysvinit package is really aweful, and the idea of having non-daemon initialization scripts in /etc/init.d/ particularly dumb.
But what really upset me is the idea of mounting virtual filesystems in /etc/init.d/mountvirtfs, and that /etc/init.d/ (why do some of the scripts end in .sh and some don't?) calls it unconditionally even if it is disabled in /etc/runlevel.conf or the usual symlink forest.
The script itself as so many others seems to be to quite shoddily and badly written, with the love of clever complexity that seems to me the hallmark of Debian stuff, and is full of what I think are dumb/noddy/fragile bits.
My favourite is that it half-assedly parses /etc/fstab itself, to extract the mount options, and then issues the mount command. Why not just do the mount and let the it get the options?
In the end I could not bear to look at it any more, and I replaced what was making me nauseated with something a lot simpler:
#! /bin/sh

for M in '/proc' '/sys' '/tmp' '/dev/shm' '/dev/pts' '/proc/bus/usb'
do grep -q "$M" /proc/mounts 2> /dev/null || mount "$M"; done
The whole structure of the boot sequence still feels very wrong.
Ah well, one of my nice USB2/FW external boxes was getting a bit too quiet. So I checked and it was getting hot, because the little 40mm fan in the back was rotating quite slowly.
I cleaned and lubricated the engine rotor with a spray of WD 40, and the fan is back to is usualy whine. In other words, yet another sleeve bearing fan.
Sleeve bearing fans usually seize up after a few months operation, and putting them on things that might get damaged if overheating is mad. Hard to avoid them: the fan on my bargain priced GF3 Ti200 is sleeve bearing too, but I have seen server (that is, usually on 24x7) motherboards that had sleeve bearing fans on their chipsets, and would randomly crash after a few months of operation.
I have put in my diary a note to relubricate all the sleeve bearing fans I am aware of every few months.
Note that cheap ball bearing fans don't need to be relubricated every few months, but they are noisier to start with, and become much noisier with time, as the balls start rattling as they get deformed/worn down with time.
At least if regularly cleaned and relubricate sleeve bearing fans will keep quiet for quite a long time.
Looked at aGNUla, an EU sponsored project with Italian and Swedish partners to develop a high quality music oriented Linux distribution for free use. It is amazing what a little public money and some wise work can do.
They have actually done two distributions, one Debian based, one Fedora based, quite well packaged and with lots of interesting applications.
The web site is very well designed and neat, and just the documentation is worth the project. The wisdom of the introduction to the documentation section is in itself notable:
Documentation is an important part of being able to effectively use any piece of software. That's true for proprietary as well as for Libre Software. Historically, Libre Software has suffered from a certain lack of well-organized documentation, which has somewhat limited its usefulness for new users.
That's why Centro Tempo Reale has hired Dave Phillips, the renowned author of "Linux Music and Sound", as chief technical writer for the AGNULA project. Dave is working on a set of tutorials for the various applications which are already or will become part of the AGNULA distributions, as well as on a `hands-on' tutorial which will guide the user throught the whole installation, set-up and production process using the AGNULA distributions.
As the Debian project continues to produce and maintain at a good pace a package collection but less effectively a distribution, many others have produced alternatives ways to install a recent Debian package collection based distribution.
Some good person has made a rather useful lists of Debian alternative methods of installation.