Software and hardware annotations 2007 June

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.

[file this blog page at: digg del.icio.us Technorati]

070630 Sat Interesting cheap switch with high features

I don't really need a fast network at home, but it is nice for backups over the wire: the 10-11MB/s capacity of a 100mb/s network link limits backup speed to rather less than that of writing to an USB2, Firewire 800 or eSATA disk. Also I like to have a moderately sophisticated switch to be able to do some testing of recent features like jumbo frames and spanning trees, but most such advanced switches have been quite expensive so far.

But I have recently bought a D-Link DGS1216T for around £150 including VAT which has all these things and also two optical transceiver sockets (SFP GBICs). It works pretty well, and even has nice features like port mirroring.

The major defect I have noticed so far is that it has a rather noisy fan; in part because it is a slim 1U unit for racks, rather than homes, in part because it is cheap, and quiet fans are usually expensive.

070629 Fri SMLT and what it really does
Well, today I heard the claim that SMLT avoids entirely the issues associated with spanning trees, (which are particularly vexing when there are multiple VLANs with different topologies) and that is sort of perversely correct: if all switches in an internetwork are clustered using SMLT, then there is a single logical switch to which all other nodes are attached, and thus there can be no loops. It is perverse because it creates a fully virtual single LAN, centralizing all topology, even if the core has some distributed redundancy.
Another way to say it is that SMLT creates a virtual backbone LAN to which all other nodes are bridged, and the virtual backbone LAN is a subset of the physical links. In general this is preferred by those who like centralized structures; I prefer distributed ones with a degree of independence among parts, because I like flexibility and survivability, and resilience over redundancy.
070628 Thu Canonical network topologies
Part of my ongoing discussion of LANs and VLANs revolves around the idea of what is a good network topology, and this has changed over time. Initially, in ARPAnet, X25, UUCP or Berknet days a network was a mesh of point-to-point links, with three distinct layers: In effect not dissimilar from the POTS structure, on which it was largely modeled, and entirely based on routing, usually pretty static (as in periodically updated UUCP maps or BerkNET (a long forgotten project by Eric Schmidt 1, 2, 3) configuration files).
The biggest change happened when Ethernet style LANs became popular, as these provided for the elimination of a large number of single links by merging them into a shared LAN. This gave rise to internetworking among those shared LANs, which was achieved by either bridging the LANs or by routing among them.
As previously remarked, bridging is indiscriminate, as it connects networks by forwarding every Ethernet frame, thus every protocol contained therein, the only filtering being based on source and destination Ethernet addresses. Routing instead is far more selective and can make better decisions by looking at more information per packet.
The network topologies they imply are rather different: with bridging one tends to create fairly large base networks in which the logical topology is rather different from the physical one, with routing the phyhsical and logical topologies look very similar. In parrticular with bridged networks the logical topology has a much coarser shape, and for this reason it is both somewhat simpler to look at and more fragile.
But whatever the scale, eventually every network resembles the Internet, being a group of interconnected networks, and what matters is then the shape of the interconnections and how these map on the dependencies among services supported by each internet. Because networks don'[t exist for their own sake, but to support access to network services, and it is this purpose that drives network topologies.
070627 Wed More on the misuses of VLANs
Today I sat frowning as I listened to a smart guy repeating propaganda from a major switch and router manufacturer listing the advantages of VLANs and also making the usual (often seemingly deliberate) confusions between switch partitions, VLAN tags, and layer 2 routing and layer 3 switching or whatever. Which made me think that in my previous arguments about VLANs I did not make as explicit that it is not so much VLAN tagging that is a bad idea in itself, rather that what is bad are the two ideas for which VLAN tagging is an enabler: Of these the worst is having a single bridged LAN composed of segments, as it makes error propagation too easy and error analysis too hard. As previously remarked, bridging recreates a (messy) situation similar to that with thick or especially thin coaxial Ethernet setups.
The problems with multiple subnets on the same LAN are that they require some inter-subnet routing somewhere, and usually they are redundant. What's the point of multiple subnets on the same LAN? It amounts to assigning a subnet a functional role instead of a topological one, and that usually is both pointless and dangerous: access control by address range is weak, coarse and induces a false sense of security (especially if some LANs are based on radio). As to routing between subnets on the same LAN, in general that requires duplicating traffic, thus greatly increasing traffic (especially in the case of across-subnet broadcasts). Duplication is not required only in the inter-switch inter-subnet case, in which case in effect what happens is plain routing.
Compared to all this VLAN tags are not a big deal: they just formalize the distinction between subnets. In effect a VLAN tag is an Ethernet subnet prefix, as if Ethernet addresses were extended to 60-bit addresses, with the 12 top bits as the VLAN tag and the bottom 48 bits the original Ethernet address. Using tags also allows enforcing the separation of subnets by making it pointless for nodes to have interfaces with addresses on multiple subnets.
This discussion is framed in terms of LANs and subnets, but bridging and VLANs were created to address the needs of growing organisations using non routable (or non-routed) protocol families such as SMB, IPX, AppleTalk, which used to be very popular or even dominant in the past. The general upgrade to IP family protocols has removed the need to apply link level trickery to compensate for the lack of routing at the transport level. It is just sad that bridging etc. are still widely used despite IP supporting routing, and favouring the one lan, one subnet, one (or more) router type of design on which the whole internet philosophy is based.
Conversely using VLANs internally to a switch to partition it is not that bad an idea, because it has none of the downsides above. Partitioning a single LAN into multiple disjointed LANs poses none of the issues that extensive bridged LANs and multiples subnets over a LAN pose; it just creates some minor maintenance issue, as it turns a switch into a more complicated entity than one that supports just one LAN.
070609 Slow remote X display with Exceed and antialiases fonts
A colleague showed me how slow was the GNU/Linux version Eclipse when viewed on MS Windows via the Exceed X server. Since there was no good reason for this, and display using VNC seemed fast, I noticed that the GUI was using anti-aliased font rendering, and checking with 
xterm -fa 'mono:size=10:antialias=0 or 1
showed that antialiasing was indeed the issue. Even enabling the RENDER extension on the X server did not improve things. Strange.
070602 Software versus hardware RAID: bandwidth, latency, convenience
During an online help session someone asked about the advantages and disadvantages of software and hardware RAID. Well, they relate to performance and convenience, as well as price.
One of the major performance differences is about host bus traffic: for RAID arrangements with some redundancy (mirroring, parity, ...) a hardware host adapter saves transferring that degree of redundancy over the system bus. For example for mirroring under software RAID each written block must be transmitted over the system bus twice, but only once with a hardware RAID host adapter.
The same or more applies for example to RAID5 (n+1) in case of a read-modify-write transaction (for a partial stripe update) software RAID must read the other n-1 data members of the stripe and them write back the whole stripe over the system bus, but one needs to send only the single block to update to a hardware RAID host adapter.
Another major performance difference is often over latency: here usually software RAID has the advantage as usually the low power consumption, embedded CPUs used in hardware RAID host adapters are much slower than recent host CPUs. It is possible for a hardware RAID host adapter to add 2-3ms latency to each transaction.
As to convenience, hardware RAID usually is far nicer than software RAID, as often it provides a simple single virtual disk interface to the host operating system, which therefore can be configured with no special casing for RAID operation other than tuning. Software RAID instead requires boot loaders and kernels with special modules to handle the RAID operation. Fortunately kernels like Linux implement RAID1 in such a way that volumes which are members of a RAID1 have almost exactly the same layout as a non-RAID ones, which simplifies things like recovery. But software RAID still makes boot and configuration more fragile.
Hardware RAID is therefore more transparent to the operating system, but this means that it is harder to monitor and tune a hardware RAID setup, while all the usual and often extensive tools of the host operating system can be used for a software RAID. Some hardware RAID host adapters offer interfaces that provide some access to the status of the underlying array members, but this is often unsupported or not as well supported as access to native devices.
My impression is that hardware RAID is better for smaller systems where ease of setup is important; for larger systems perhaps software RAID is better, as system bus bandwidth concerns can be eased by having multiple system buses and other high end hardware features. But it is hard to imagine general cases. It is somewhat amusing to me that ease of setup is then what drives the adoption of strange RAID based things like SAN servers with virtual disk drives.