Diary of a geek

August 2006
Mon Tue Wed Thu Fri Sat Sun
 
     

Andrew Pollock

Categories

Other people's blogs

Subscribe

RSS feed

Contact me

JavaScript required


Thursday, 31 August 2006

A ramble about alternative energy and world affairs

Well John Howard said he wanted to start a nuclear debate in Australia. Seems it has already started on Planet Linux Australia.

I figure I might as well have a meandering blog post about alternative energy and current world events, since I've just been immersing myself in the best news I can obtain with my crappy cable package in a country not renowned for its awareness of world affairs.

Firstly, since there's been talk about nuclear power, I'd like to offer my thoughts on Iran, and how it's sounding like Iraq all over again.

People are getting in a flap about Iran enriching uranium. Iran says that they don't want "the bomb", they only want nuclear power to meet their energy demands. Now if this is true, then surely should applaud a country that sits on a chunk of the Middle East's oil reserves looking to use something other than oil for its energy needs. I for one don't know if you need to "enrich" uranium to use it for a nuclear reactor, or whether it's good enough "as is".

But let's just assume that Iran's intentions are as they have said, then it's going to be Iraq all over again. The US said Iraq had weapons of mass destruction. The US is saying Iran is enriching uranium for the purposes of making a bomb. So far the former claim hasn't been proven, so what's to say the latter is true either?

Let's say the nuclear debate in Australia determines that it'd be a good a thing for Australia to go nuclear. How is Australia enriching uranium for electricity generation any different to Iran doing it? (Other than Australia is in the Coalition of the Willing, and Iran is in the Axis of Evil).

Speaking of Iran being in the Axis of Evil, how is Iran supplying weapons to Hezbollah fundamentally any different to the US supplying weapons to Israel? Oh, and is anyone allowed to criticise Jewish people without being called anti-Semitic? Since when is invading a neighbouring country considered okay? I am so glad Australia is an island nation. These countries with land borders, sheesh...

Anyway, back to alternative energy. I'm a greenie, (with a lowercase "g") so I'm open to nuclear power, but it does frighten the willies out of me, with things like Chernobyl. I'd never heard of a Pebble Bed Modular Reactor until Paul wrote of it. It certainly sounds safer than previous methods of nuclear reaction.

But of alternatives. Wind, for example, doesn't need to be big and arguably ugly. These guys in the UK have made a very sexy and quiet wind turbine. I don't know how it stacks up in terms of cost or output to the traditional three-bladed wind turbines like what I've photographed in Southern California, but they're supposed to be quiet, which is apparently one of the (many) arguments that landowners like farmers have against wind generation in general.

This Australian company has come up with a very small, but less sexy wind turbine, that I believe to be fairly cheap.

Finally, in terms of generation, and I've written about this before, but I find the Tower of Power to be a fascinating concept in natural energy generation.

Where am I going with this ramble? No idea. I do think rapidly developing countries like China should completely leapfrog over the era of oil and move to renewably generated electricity. Maybe they can get the manufacturing costs down of the equipment, and it'll be less of a big deal in terms of cost for the rest of the world to adopt it.

Whew. What a ramble. Don't start me on flushing toilets with drinking water.

[22:30] [opinion] [permalink]

Metros I've travelled on

With apologies to Martin

sydney cr hongkong san
	francisco hong
	kong kcr san francisco muni los
	angeles
Got at b3co.com!

Yeah, where is the VTA Light Rail?

[16:22] [meme] [permalink]

Saturday, 26 August 2006

Mirror, mirror...

What feels like an eternity ago, at linux.conf.au 2005 in Canberra, AJ floated the idea of me being the Debian mirror coordination guy. I expressed interest in this, but somewhere along the line, I think there were some crossed-wires over whether I was interested or not, and nothing came of it.

The other day, I pinged AJ on a few things, and the mirror coordination role came up again. I re-expressed my interest in doing it, and so here I am.

So I'm now in the process of getting my head around exactly what the job entails, whilst I wade through 12 months of mail to mirrors@debian.org, that so far (for August 2005) appears to be about 95% spam. Yay.

I'll also go through all of the current bugs assigned to the mirrors pseudo-package, and try to validate them, and either act on or close them, depending on the current state of affairs and contactability of the submitters.

So I envisage it'll take a while to just get on top of the backlog, and then I'll look at any areas where we can automate mirror verification (I've got to look at what's currently in place). Helping run mirror.linux.org.au has been educational. I quite like the system that the Linux Kernel Archive Mirror System has in place, and wouldn't mind having something similar for Debian, if it's feasible.

But that sort of stuff is a little while down the track, I have to get on top of the backlog first.

[13:28] [debian] [permalink]

Wednesday, 16 August 2006

I love MythTV

Many, many years ago, I dreamed of making a VCR that had either a serial interface, or an Ethernet interface with a Telnet server. It would have been so useful for those times that I was out and about, and either knew I wouldn't make it home in time to watch a TV show I wasn't already recording, or heard about something on TV during the day that I'd like to record.

Many, many years later, with the installation of the MythTV web interface, I've now achieved that dream. Ah, the feeling of accomplishment!

Oh, and while I'm being geeky, I should mention how I can run a MythTV front end on my laptop, and watch TV in bed with no extra hardware required.

I've reached the pinnacle...

[22:20] [geek] [permalink]

Monday, 14 August 2006

How to mount ATA over Ethernet volumes with a minimum of grossness

Yesterday I discovered some inadequacies in the stock Debian Etch initscripts when it came to filesystems on ATA over Ethernet block devices.

Overnight I got a few emails, but it was a one Joshua J. Kugler who brought my attention to the _netdev mount option. The mount(8) manpage really is a treasure-trove of information that should be read often.

So, in a nutshell, here's what I'm doing:

  • added _netdev to the existing options for the filesystem that is on the ATA over Ethernet device in /etc/fstab
  • /etc/init.d/mountall.sh modified to call mount with an extra -O no_netdev argument. Also filed #383073 to get this fixed for real.
  • modified /etc/init.d/mountnfs.sh (I know this is a bit off-purpose, but the comments mention smbfs being mounted, even though there's no other traces in the file) to also mount devices with the _netdev option (essentially just mount -a -O _netdev). Also filed #383123 to get this fixed for real.
  • modified /etc/init.d/umountnfs to unconditionally call umount -a -O _netdev (so the filesystem is unmounted before the network gets hauled out from underneath it). Also filed #383124 to get this fixed for real.

Finally, I found I had to either load the aoe kernel module as a post-up operation for the Ethernet interface in /etc/network/interfaces or load it in /etc/modules and call /usr/sbin/aoe-discover as a post-up operation in /etc/network/interfaces, because just loading it from /etc/modules resulted in the driver being loaded a fair while before the network came up, and once the network had come up, it took the driver longer than the time for /etc/init.d/mountnfs.sh to be run to realise there were ATA over Ethernet devices on the LAN and arrange for the relevant entries to appear in /dev/etherd. I've currently opted for running aoe-discover from /etc/network/interfaces.

So I'm now very happy. I can reboot my MythTV server and everything comes back without any intervention whatsoever. Sweet.

It'd be nice if these fixes can make it into Etch, as all of the other components will be there for ATA over Ethernet support. The kernel is new enough to have the driver as standard, and vblade is in Etch. Just the support to mount it all properly isn't there. Oh, and nothing I've done (with the exception of the post-up stuff in /etc/network/interfaces) is ATAoE-specific. It'll work equally well for NBD for example, and presumably other SAN-like stuff.

I certainly find this approach far less gross than what Coraid suggests, and it'd also be cool if Debian were the first distro to do it the right way. I wonder if Red Hat/Fedora are already? I suppose I could fire up Xen or VMware and find out if I get curious enough.

[21:55] [tech] [permalink]

Sunday, 13 August 2006

Found one small problem with using ATA over Ethernet

And I can't believe I'm the only person who's struck this, but so far Google hasn't turned up any useful leads.

The problem is pretty obvious, when the system boots (well Debian Etch at least), it runs mountall.sh at priority 35 in /etc/rcS.d. That tries to mount all the local filesystems (it does the determination for what is locate or remote by the filesystem type in /etc/fstab, there's a hard-coded list of filesystem types to explicitly not try and mount). Then the network comes up at priority 39. The problem's rather obvious.

I did a reboot test tonight to see if everything would load and come up correctly on reboot, and well, it didn't even boot up properly, because /srv couldn't be fscked, let alone mounted, and that's my AoE volume.

My /etc/fstab contains:

/dev/etherd/e0.0        /srv    jfs     defaults        0       0

The problem is, as far as the init scripts are concerned, based on filesystem-type, this is a local filesystem. The init scripts don't have the concept of a remote block device. I tried moving all the networking initialisation scripts before the mountall.sh script, but think there's an inherent delay between the network coming up and the aoe driver figuring out what shelves and slots are actually available and creating the relevant entries in /dev/etherd

The thing is, this seems to be a rather essential thing that I'm trying to do, so I can't believe I'm the first person to run into this. I'll sleep on it and see if the lazyweb comes up with anything...

[23:32] [tech] [permalink]

MythTV in under 24 hours

Last night, the final component of my MythTV setup arrived - the TV tuner card, a Hauppauge WinTV-PVR-350. I'd had the other bits and pieces for about a week, indeed I'd already had MythTV installed and "operational", but there's really only so much you can do without a TV signal in the mix as well.

So I had a bit of a late night last night bashing on things and getting it all going. It was actually surprisingly trouble-free.

For some reason, I naively thought that the more contemporary 2.6 kernels had all the support required for the PVR-350. Not true. You need to grab the ivtv driver and build it separately. If I was less impatient, I would have worked with module-assistant to get it packaged, but I just threw it on. I have to run 2.6.17 to get the sound working, so I needed the 0.7.0 version of the driver. This built and installed fine, and I could run mplayer against /dev/video0 and see (and hear) TV fine. With a bit of tweaking of MythTV, it was happily using the card.

Getting the remote control to work was slightly more problematic. It turned out that I needed to get the latest greatest lirc from CVS in order to get everything to build correctly, and get a /dev/lirc that I could actually read from. After that, everything else just fell into place.

The last thing I spent a bit of time battling with today was guide data and channel tuning. It seems for some reason that channels greater than or equal to 14 didn't have their frequency set correctly, so I had to manually edit each channel and put in the frequency in kilohertz that ivtv-tune --list-channels provided. The Zap2it chaps also provide two different sets of guide data for Mountain View, and depending on which one you pick, you get a totally screwed up idea of the actual channels available. I also discovered the hard way that changing from one set of channels to the other without cleaning out the channels first leads to a complete mish-mash of channel data that correlates even less with reality than choosing one or the other by itself.

But within 24 hours of receiving the tuner card, I have everything up and running. The ATA over Ethernet disk array (that Myth tells me is good for over 600 hours of recording) seems to be holding up to the task alright. The current bandwidth utilisation for a few test recordings is interesting:

Graph of bandwidth utilisation for disks attached to the MythTV server
via ATA over Ethernet

So it seems that a TV show is a nice steady 5 mbits/sec, which everything seems to keep up with okay. The post-processing to flag commercials seems a bit more bandwidth-intensive. It seems to take about 40 minutes to flag the commercials for a 60 minute block of recording.

It's early days yet, but I'm fairly happy with how everything's operating so far. I can certainly leave things as they are for a while without needing to fiddle with things any further.

The one thing I do want to mention is the guide data. The fact that it's totally free, and designed to be used by the likes of MythTV is awesome. PVRs really live and die by the guide data, and it's so cool that Zap2it offer it completely gratis. Mad props to them.

Oh, and while I'm dishing out praise, I really must also thank Christian Marillat for http://www.debian-multimedia.org/ and for packaging up MythTV for Debian. If I had to build all of this myself, I'm sure it wouldn't have been so trouble free.

[00:01] [tech] [permalink]

Saturday, 12 August 2006

More benchmarking

When I did my Red Hat Certified Engineer training, the second time around (when I updated from Red Hat 7.1 to Enterprise Linux 3), the trainer mentioned this Ext3 vs Reiserfs benchmark that Gurulabs performed. Probably because it had such a memorable name, I've remembered it and referred people to it, and referred to it myself, a few times over the years since.

So it seemed only fair to try out their benchmarking methods (i.e. use NetApp's postmark with a few different settings) on the uber-disk as well, while I had it idle.

So I did.

Firstly, I ran it locally on minotaur, the piddling little 866Mhz Pentium III, with 320Mb of RAM (but with 1.5Tb of disk attached directly via USB), and then I ran the exact same tests from teevee, the box destined to become my MythTV server (3.0Ghz Pentium 4, 1Gb of RAM), with the disks mounted with ATA over Ethernet. This was with a JFS filesystem on a single logical volume striped across four physical volumes.

I ran the tests three times, just like the Gurulabs benchmark, first time around, it was with:

  • 50,000 transactions (set transactions 50000)
  • 2,000 simultaneous files (set number 2000)
  • files in the range of 1,000 to 9,000 bytes (set size 1000 9000)

The idea being that this will generate around 150Mb of data, which should all fit in the RAM (of either system)

The second time around was with:

  • 50,000 transactions
  • 2,000 simultaneous files
  • files in the range of 1,000 to 90,000 bytes

The idea being that this, generating 1400Mb of data, will exceed the RAM on both systems (but not uniformally, obviously).

The final run was a total thrash with:

  • 200,000 transactions
  • 4,000 simultaneous files
  • files in the range of 1,000 to 300,000 bytes

This one causes about 19Gb of data to be written, and absolutely hammers the living daylights out of the disks (or the network, and the disks, in the case of ATAoE).

So, now for the results:

Test case 1, with locally attached disks
Time:
        22 seconds total
        21 seconds of transactions (2380 per second)

Files:
        27170 created (1235 per second)
                Creation alone: 2000 files (2000 per second)
                Mixed with transactions: 25170 files (1198 per second)
        24986 read (1189 per second)
        24697 appended (1176 per second)
        27170 deleted (1235 per second)
                Deletion alone: 2340 files (2340 per second)
                Mixed with transactions: 24830 files (1182 per second)

Data:
        149.53 megabytes read (6.80 megabytes per second)
        161.85 megabytes written (7.36 megabytes per second)
Test case 1, with ATAoE attached disks
Time:
        27 seconds total
        25 seconds of transactions (2000 per second)

Files:
        27170 created (1006 per second)
                Creation alone: 2000 files (2000 per second)
                Mixed with transactions: 25170 files (1006 per second)
        24986 read (999 per second)
        24697 appended (987 per second)
        27170 deleted (1006 per second)
                Deletion alone: 2340 files (2340 per second)
                Mixed with transactions: 24830 files (993 per second)

Data:
        149.53 megabytes read (5.54 megabytes per second)
        161.85 megabytes written (5.99 megabytes per second)
Findings

A degradation in performance, sure, but not a huge one.

Graph of the results

Test case 2, with locally attached disks
Time:
        218 seconds total
        209 seconds of transactions (239 per second)

Files:
        27144 created (124 per second)
                Creation alone: 2000 files (400 per second)
                Mixed with transactions: 25144 files (120 per second)
        24830 read (118 per second)
        25094 appended (120 per second)
        27144 deleted (124 per second)
                Deletion alone: 2288 files (572 per second)
                Mixed with transactions: 24856 files (118 per second)

Data:
        1405.24 megabytes read (6.45 megabytes per second)
        1535.91 megabytes written (7.05 megabytes per second)
Test case 2, with ATAoE attached disks
Time:
        165 seconds total
        158 seconds of transactions (316 per second)

Files:
        27144 created (164 per second)
                Creation alone: 2000 files (1000 per second)
                Mixed with transactions: 25144 files (159 per second)
        24830 read (157 per second)
        25094 appended (158 per second)
        27144 deleted (164 per second)
                Deletion alone: 2288 files (457 per second)
                Mixed with transactions: 24856 files (157 per second)

Data:
        1405.24 megabytes read (8.52 megabytes per second)
        1535.91 megabytes written (9.31 megabytes per second)
Findings

Whoa, who'd have thought this? Better performance over the wire? I'm blaming the fact that minotaur is a bit of a weakling compared to teevee, and teevee had a better caching advantage with more RAM. Mind you, you'd expect to see the same for the first test as well, unless size is a factor. Inconclusive results I guess.

Graph of the results

Test case 3, with locally attached disks
Time:
        7356 seconds total
        7310 seconds of transactions (27 per second)

Files:
        104099 created (14 per second)
                Creation alone: 4000 files (117 per second)
                Mixed with transactions: 100099 files (13 per second)
        100246 read (13 per second)
        99560 appended (13 per second)
        104099 deleted (14 per second)
                Deletion alone: 4198 files (349 per second)
                Mixed with transactions: 99901 files (13 per second)

Data:
        18995.06 megabytes read (2.58 megabytes per second)
        19738.85 megabytes written (2.68 megabytes per second)
Test case 3, with ATAoE attached disks
Time:
        12320 seconds total
        12111 seconds of transactions (16 per second)

Files:
        104099 created (8 per second)
                Creation alone: 4000 files (32 per second)
                Mixed with transactions: 100099 files (8 per second)
        100246 read (8 per second)
        99560 appended (8 per second)
        104099 deleted (8 per second)
                Deletion alone: 4198 files (49 per second)
                Mixed with transactions: 99901 files (8 per second)

Data:
        18995.06 megabytes read (1.54 megabytes per second)
        19738.85 megabytes written (1.60 megabytes per second)
Findings

So presumably the network latency made its presence felt with data volumes of this magnitude.

Graph of the results

[17:35] [tech] [permalink]

Wednesday, 09 August 2006

Performance comparison between LVM and a straight disk

The beauty of having your hardware arrive in installments is you can do all sorts of fooling around with lots of storage that you wouldn't otherwise do because you'd be falling over yourself to get it all up and running yesterday.

So as I impatiently wait for my TV tuner card to arrive, I've been doing some "benchmarking" to see how various different configurations perform. One of the things I wanted to find out was how much overhead did LVM give you.

So I took one of the four disks in my non-redundant array of Bloody Huge Storage, and ran bonnie++ on it as a straight JFS volume on /dev/sda and as a logical volume in a volume group that used all of the logical extents provided by making /dev/sda into a physical volume.

Again, I ran bonnie++ as:

bonnie++ -d /mnt -s 2G -n 1024 -u nobody:nogroup

So here's the results of running it on a JFS filesystem straight on /dev/sda:

                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
minotaur         2G 13712  95 18561  21  9152  11 13874  94 20446  18 142.2   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
               1024  5999  37  7125  19  1604  12   616  12   168   0    61   1

And here's the results of running it on a JFS filesystem on a logical volume that used all of the free logical extents provided by a volume group consisting of a physical volume made from /dev/sda

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
minotaur         2G 13790  96 18566  21  9132  11 14202  96 20628  18 146.3   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
               1024  5989  37  7056  20  1605  12   611  12   167   0    61   1

Yup, that's right. It was actually slightly faster in a few cases. I can't explain that one. But it certainly goes to show that there is no noticeable performance impact of using LVM. Nice.

[20:39] [tech] [permalink]

An Inconvenient Truth gets bad press Down Under

Film at 11

My friend Andrew brought this article in the Sydney Morning Herald to my attention today.

I was initially mildly incensed by it, then someone at work pointed out the author's Wikipedia entry, which led onto this Bulletin article on her. So it seems she's just a professional right-wing shit-stirrer. This other article she wrote managed to stir up some ire amongst the cycling community.

Still, I am glad to see that An Inconvenient Truth is coming to Australia. Well worth the watch. Now I need to go find where Who Killed the Electric Car is screening...

[20:13] [opinion] [permalink]

Sunday, 06 August 2006

Initial bonnie++ results with the uber-disk

So I ran bonnie++ over my 1.5 terabyte, exported via ATA-over-Ethernet logical volume of extreme immensity. I don't really know what I'm looking at, but I'll record the results here before I lose them.

From both the MythTV front-end, and from minotaur, the box that has the disks attached, I ran bonnie++ twice:

bonnie++ -d /mnt -s 2G -n 1 -u nobody:nogroup

and

bonnie++ -d /mnt -s 2G -n 1024 -u nobody:nogroup

Firstly, I guess the results where the disks are directly attached (via USB):

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
minotaur         2G 13595  95 20652  24 10204  12 13625  92 21362   6 295.5   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

and

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
minotaur         2G 13646  95 20864  24 10195  12 13348  91 21377   6 288.8   2
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
               1024  6173  37  6090  17  2215  22  1032  22   184   0    93   2

The +'s indicate that the result occurred in an impossible to accurately measure, sub-500ms time.

From the MythTV front-end, so with the ATA-over-Ethernet overhead thrown in:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
teevee           2G  3789   7  3761   0  3138   0 10742  23 11445   0 152.9   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1 +++++ +++ +++++ +++  1029   2  1372   1 +++++ +++ +++++ +++

and

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
teevee           2G  3848   8  3862   0  2876   0  9871  31 11440   1 147.9   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
               1024  2488   7  4633   8  1752  15   752   8   444   1   159   1

Wow, I'm going to go away and analyse these numbers and update this post, but on the face of it, it looks like there's a significant performance impact (at least on my home network, I'm sure it's not optimal) in using ATA over Ethernet. Hmmm.

[11:20] [tech] [permalink]

Friday, 04 August 2006

I can only presume I am an idiot

So it seems I was a bit quick to declare the USB controller a dud last night.

Overnight, Simon Richter attested on IRC that he also had a USB controller bearing the same PCI ID, and his worked fine. (Although his had the option for extra power from the floppy drive power cable, which I find interesting. Mine does not).

So tonight I worked through the various combinations to get to the bottom of the problem. I put a Sun QFE card in that PCI slot to make sure the riser and the slot were working correctly. It worked fine.

Then I put the USB controller back in and tried a USB thumb drive, that worked.

So I immediately narrowed in on the hard drive itself, and the IDE-USB adapter. I tried it on my laptop. Nothing. Aha. So I tried the hard drive directly with IDE, and it worked. So I assumed that the IDE-USB adapter must have been faulty, and tried a different one. It worked. I cycled through the other three IDE-USB adapters, and they all worked. Then I tried again with the one from last night, and it too worked!

I can only presume that in my haste, or with my fuzzy head (I've got a cold or the 'flu or something), I managed to connect the IDE-USB adapter to the hard drive incorrectly. Don't ask me how, considering it's a keyed interface, but it's not the first time I've managed to screw up plugging in an IDE hard drive.

Anyway, with that hurdle behind me now, I made four physical volumes out of the disks (no partitions at all), and then made a volume group, and a single logical volume that is striped across all four physical volumes (yes, I know if I have a disk failure I can kiss the lot goodbye, but I'm in performance testing mode at the moment). I then exported that logical volume with vblade and mounted it on what will be my MythTV box.

apollock@teevee:~$ df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/mapper/Debian-root
              ext3    259M  156M   90M  64% /
tmpfs        tmpfs    502M     0  502M   0% /dev/shm
/dev/sda1     ext3    228M   25M  192M  12% /boot
/dev/mapper/Debian-home
              ext3     63G  295M   59G   1% /home
/dev/mapper/Debian-tmp
              ext3    368M  8.1M  340M   3% /tmp
/dev/mapper/Debian-usr
              ext3    4.7G  1.7G  2.8G  38% /usr
/dev/mapper/Debian-var
              ext3    2.9G  897M  1.8G  33% /var
tmpfs        tmpfs     10M  124K  9.9M   2% /dev
/dev/etherd/e0.0
               jfs    1.5T  2.2G  1.5T   1% /mnt

I've currently got bonnie++ hammering away at the "disk" to see what sort of performance I'll get, and whether it'll be fast enough to record TV.

Now I just need the TV tuner card to turn up, and I can start fiddling in earnest.

[21:38] [tech] [permalink]

Thursday, 03 August 2006

I always seem to buy lemons

I wish hardware printed the PCI ID on it, so you could at least do some homework on what's what.

Bought a HP branded four port USB 2.0 controller from Fry's tonight, and the sucker doesn't appear to work despite the page for a mighty similar device saying it should work.

Here's the relevant bits for posterity:

lspci output:

01:0a.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
        Subsystem: Unknown device 1631:0035
        Flags: bus master, medium devsel, latency 64, IRQ 10
        Memory at ff8f5000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2

01:0a.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
        Subsystem: Unknown device 1631:0035
        Flags: bus master, medium devsel, latency 64, IRQ 9
        Memory at ff8f6000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2

01:0a.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI])
        Subsystem: Unknown device 1631:1600
        Flags: medium devsel, IRQ 11
        Memory at ff8f7c00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 2

01:0a.0 0c03: 1033:0035 (rev 43)
01:0a.1 0c03: 1033:0035 (rev 43)
01:0a.2 0c03: 1033:00e0 (rev 04)

Relevant dmesg output:

0000:01:0a.2 EHCI: unrecognized capability 00
ACPI: PCI Interrupt 0000:01:0a.2[C] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:01:0a.2: EHCI Host Controller
ehci_hcd 0000:01:0a.2: new USB bus registered, assigned bus number 1
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ehci_hcd 0000:01:0a.2: irq 11, io mem 0xff8f7c00
ehci_hcd 0000:01:0a.2: startup error -19
ehci_hcd 0000:01:0a.2: USB bus 1 deregistered
ACPI: PCI interrupt for device 0000:01:0a.2 disabled
ehci_hcd 0000:01:0a.2: init 0000:01:0a.2 fail, -19
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
ohci_hcd 0000:01:0a.0: OHCI Host Controller
ohci_hcd 0000:01:0a.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:01:0a.0: irq 10, io mem 0xff8f5000
ACPI: PCI Interrupt 0000:01:0a.1[B] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ9
ohci_hcd 0000:01:0a.1: OHCI Host Controller
ohci_hcd 0000:01:0a.1: new USB bus registered, assigned bus number 2
ohci_hcd 0000:01:0a.1: irq 9, io mem 0xff8f6000
I knew I should have bought the VIA-based one instead. Red always goes faster.

[21:30] [tech] [permalink]

Wednesday, 02 August 2006

New computer

Since I lashed out on a metric fuck-ton of disk the other week, I figured I might as well continue with the trend, and get the PC that will be the MythTV box.

Last week there was some spam in the snail-mail from Dell, the offer that caught my attention was a Dimension 3100 for under $500. I got a RAM upgrade to 1Gb, and the cheapest nastiest shipping available (which incidentally got rebated away to nothing) and the thing still turned up in two days and only cost me around $500. Gotta be happy with that.

I installed Etch on it via a netboot installation with no dramas at all. I really like the automatic LVM partitioning. Very slick. My only complaint would be not to use all of the free extents, just because you can, and to put swap on an LV as well. Oh, and I think calling the VG consistently "Debian" is going to result in pain for people down the track when they try to move disks around.

GNOME 2.14 is also looking pretty slick.

The only specific problems I've had with running Debian on the machine so far have been that the hardware clock (/dev/rtc) seems a bit screwy, and the sound didn't work with the 2.6.16 kernel that was installed by default. (But works fine with 2.6.17). Oh, and I'm having some weirdness with audio CDs.

Now all I need is to get a TV tuner card, a four-port USB 2.0 controller for my old 1RU server, and the right right-angled PCI riser, and I have everything I need.

[21:49] [tech] [permalink]

Why I like Open Source

20:19 < Caesar> Where best should I file a bug about eject not being installed on an etch desktop system
20:20 < Caesar> Right clicking on a CD and ejecting fails
20:20 < Caesar> tasksel?
20:21 < joeyh> did you install from cd?
20:25 < Caesar> joeyh: netboot
20:25 < joeyh> yeah, that'll be why, it's only installed in cd installs and maybe floppy on powerpc or something
20:26 < Caesar> But GNOME clearly uses it
20:26 < Caesar> So shouldn't the desktop task drag it in?
20:26 < CIA-1> tasksel: joeyh * r1474 /trunk/ (debian/changelog tasks/desktop):
20:26 < CIA-1> tasksel: * Add eject to desktop task as it's not installed by d-i in all cases and is
20:26 < CIA-1> tasksel:  used by gnome.
20:27 < Caesar> heh

[20:30] [tech] [permalink]