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:
- 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
disk. Also I like to have a moderately sophisticated switch to
be able to do some testing of
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
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
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
avoids entirely the issues associated with
(which are particularly vexing when there are multiple
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
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
revolves around the idea of what is a good network topology, and
this has changed over time. Initially, in ARPAnet, X25,
or Berknet days a network was a
mesh of point-to-point links, with three distinct layers:
In effect not dissimilar from the
structure, on which it was largely modeled, and entirely based
on routing, usually pretty static (as in periodically updated
(a long forgotten project by Eric Schmidt
- Leaf nodes with a single (or a few) links.
- Intermediate nodes with many incoming links from leaf
nodes, and a few other links to the network core, with most
trafic paths to and from the leaves to the network core.
- Core nodes with many incoming and outgoing links, and
traffic being simmetrical and many-to-many.
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
- 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
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.
- A bridged single virtual LAN over multiple LANs.
- Multiple subnets on the same (real or virtual) LAN.
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
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
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.
Slow remote X display with Exceed and antialiases fonts
- A colleague showed me how slow was the GNU/Linux version
when viewed on MS Windows via the
X server. Since there was no good reason for this, and display
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.
Software versus hardware RAID: bandwidth, latency, convenience
- During an online help session someone asked about the
advantages and disadvantages of software and hardware
Well, they relate to performance and convenience, as well as
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
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
servers with virtual disk drives.