Another great opinion on Net Neutrality which closely (if not exactly) mirrors my own. For those too lazy to go and read for themselves, here's a quick snippet.

We need policy to help cut a path for more competition, rather than protecting incumbents -- a Bandwidth Competition Act of 2008, not bogus net neutrality. All takers should be allowed access to poles or underground conduits. This is where neutrality should be enforced, instead of being a choke point.

As I've long said, a government bureaucracy isn't going to solve the problem. It's going to create less incentive for Internet companies (like mine, full disclosure) to even toss their hat in the ring. Try forming your own telephone system and you'll know what I mean. The rules are ridiculously complicated and it takes an army of lawyers to sort through them. Please please please don't turn the Internet into the phone system.

The question came up today about relative speeds of scp, tar and rsync (the latter two using ssh as a transport mechanism). While anecdotes and rumors are great for defining security policy (think TSA), I wanted some more concrete numbers so I ran a test.

I set up a script to copy a directory 5 times from my laptop to a server on the same subnet. I routinely pull 3MB/s from that server (over wifi), so bandwidth wasn't an issue. I used /var/lib/dpkg as my source directory. It weighed in a 57MB and contained 6896 files. Because rsync will compare changes between source and destination, I made sure to nuke the directory off the server after every run.

Method:            scp  rsync+ssh   tar+ssh
Average Time:  269.75s      33.6s    24.43s
Bandwidth (mbps): 1.69      13.57     18.66

The results are what I expected, at least as far as scp is concerned. It does not do well with large numbers of small files. It copied each file over completely before it started with the next one. Tar of course put the whole thing together and then shipped it off. Rsync read all the files first, then compared them to the server and then shipped them all in one go. Apparently there were some significant I/O savings to be had that way.

One other important item of note is that scp did not handle symlinks the way tar and rsync did. It dereferenced the symlink and copied the contents of that link rather than copying the link itself. That was a problem because I had picked some self-referential directories before I settled on /var/lib/dpkg.

For your reference, here are the commands I ran to test:

for i in 1 2 3 4 5; do time scp -qrp /var/lib/dpkg [server]:/tmp; ssh [server] rm -fr /tmp/dpkg; done
for i in 1 2 3 4 5; do time rsync -ae ssh /var/lib/dpkg [server]:/tmp; ssh [server] rm -fr /tmp/dpkg; done
for i in 1 2 3 4 5; do time tar -cf - /var/lib/dpkg |ssh [server] tar -C /tmp -xf - ; ssh [server] rm -fr /tmp/dpkg; done

Last year we bought some Dell PowerEdge 2850 servers with a PERC 4e/DC RAID controller. It's based on the LSI MegaRAID chipset which we really liked. It's fast which is great, although so far it hasn't be entirely stable, which is greatly annoying. To that end, I was tasked with get a Nagios script in place to monitor the array and alert us if it fails (again!).

With the server came a disk with some utilities. One of those is the MegaServ and its corresponding MegaCtrl. It seems like a good idea, but the blasted thing doesn't work in any sane manner. It generates alerts for things like how many percent a rebuild is at and when the battery starts charging. It can get bad. Worse still is that it stopped sending any alerts.

But today I found another utility for Dell. It's an extension to snmpd, named percsnmp that polls a daemon for the current status of the controllers. It's great and so full of good info. For now I'm just looking at the online state, but given all these other fields I may have further uses for it. Most especially I'm interested in the settable rebuildRateInPercent field since rebuild rate can't be set through the megamgr (a copy of the BIOS-level tool).

Today I found myself needing to save packets from tcpdump to a file but also view them on screen. I've wanted to do that in the past, but today it became more important. It was suggested to me to use two instances of tcpdump, but I thought there had to be a better way. Luckily there is.

# tcpdump -U -s 1500 -w - <bpf> |tee <file> | tcpdump -lnr -

Ever heard of publicaster.com? Yeah, me neither. Apparently one of our customers has as he attempted to send an email to them last week. Unfortunately, it got stuck in the queue because of a combination between a weird configuration in publicaster.com's DNS and Exim 3.