Greg's diary
March 2005
Translate this page
Select day in March 2005:
Su Mo Tu We Th Fr Sa
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
Select month:
2004 Sep Oct Nov Dec
2005 Jan Feb Mar Apr
2005 May Jun Jul Aug
Today's diary entry
Diary index
About this diary
Previous month
Next month
Greg's home page
Greg's photos
Network link stats
Greg's other links
Copyright information

Tuesday, 1 March 2005 Echunga
Top of page
next day
last day

A new month, and Darren from the printer repairs was back. The work he did last month didn't fix the jamming problem, but at least it was more consistent now: just before he arrived, it jammed on a single sheet printout, so I left it there for him to look at.

He didn't need that. He replaced a sensor, and the printer didn't work at all any more. It didn't even power up. It's unlikely that it was the sensor, and though leaving a printer jammed shouldn't do any harm, it currently looks like the most likely cause. As a result, once again, after he had been here I had no printer: he took it with him.

Fixed my last bug in my program pretty quickly this morning and set off for another long-running test, though not as long as last week. In the process managed to get some good statistics on how performance degrades as the system fills up. Plenty more work to be done.

Wednesday, 2 March 2005 Echunga
Top of page
previous day
next day
last day

Plenty of work today, some progress.

More cooking in the evening. I've bought a number of books in a series with names like “Asia: The beautiful cookbook”. They're well named: the photography is good, the recipes less so. Still, they have some interesting recipes that I haven't seen elsewhere, and today I decided to cook a purported Goanese dish, “Murgh Moelho”. It was pretty clear that the quantities were wrong; even the various pieces of chicken in the photo didn't match the recipe, which called for drumsticks only. Searched the web and found very few recipes, all word for word the same as in the book; even the photo was on the web. Ended up doing my own version, guessing at the quantities.

Thursday, 3 March 2005 Echunga
Top of page
previous day
next day
last day

More work on testing my program today. Speeds seem a bit variable. Then, during a comparison of two large (20 GB) files, saw this:

      tty             ad0              ad1              da0             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   76 64.00  59  3.71   0.00   0  0.00   0.00   0  0.00   1  0  3  1 95
   0   76 61.26  75  4.50   0.00   0  0.00   0.00   0  0.00   4  0  1  1 95
   0   76 64.00 137  8.54   0.00   0  0.00   0.00   0  0.00   5  0  2  1 92
   0   76 63.60 158  9.84   0.00   0  0.00   0.00   0  0.00   5  0  2  1 91
   0   76 63.91 347 21.63   0.00   0  0.00   0.00   0  0.00  12  0  9  1 78
   0   76 63.70 156  9.73   0.00   0  0.00   0.00   0  0.00   6  0  2  1 91
   0   76 64.00  57  3.59   0.00   0  0.00   0.00   0  0.00   3  0  2  1 95
   0   76 64.00  63  3.96   0.00   0  0.00   0.00   0  0.00   1  0  0  2 98
   0   76 64.00  56  3.53   0.00   0  0.00   0.00   0  0.00   2  0  0  3 95
   0   76 62.95 197 12.11   0.00   0  0.00   0.00   0  0.00   6  0  3  2 89
   0   76 63.76 395 24.60   0.00   0  0.00   0.00   0  0.00   9  0  5  2 84
   0   76 63.87 353 22.05   0.00   0  0.00   0.00   0  0.00  10  0  5  1 84
   0   76 64.00  75  4.70   0.00   0  0.00   0.00   0  0.00   3  0  1  1 95
   0   76 60.80  64  3.82   0.00   0  0.00   0.00   0  0.00   4  0  2  1 94

For no apparent reason, the I/O throughput was oscillating between 3.5 MB/s and 25 MB/s:

iostat MB/s

I wonder what's causing that. This was on FreeBSD; I'll certainly have to try that on Linux as well.

Friday, 4 March 2005 Echunga
Top of page
previous day
next day
last day

In the morning spent some time testing our existing program. It failed with a malloc failure. Further investigation showed that it was due to FreeBSDs data segment limit of 512 MB. Tried to reset that, but it proved very difficult: several places are involved:

Saturday, 5 March 2005 Echunga Images for 5 March 2005
Top of page
previous day
next day
last day

Managed to take it easy again today and watch some DVD+RWs (on a DVD player). The recording quality was marginal, and it reminded me that I still can't watch a DVD on any of my machines. Tried it with eucla, on which last weekend I had installed Fedora Core 3. In the meantime I had got X to work, so followed up on Tim Stoakes' suggestion that yum would do a better job of handling dependencies. It didn't get that far:

# yum install emacs
Traceback (most recent call last):
  File "/usr/bin/yum", line 8, in ?
  File "/usr/share/yum-cli/", line 51, in main
  File "/usr/share/yum-cli/", line 133, in getOptionsConfig
    self.conf = yumconf(configfile = yumconffile, root=root)
  File "/usr/lib/python2.3/site-packages/yum/", line 227, in __init__
  File "/usr/lib/python2.3/site-packages/yum/", line 299, in _doFileRepo
    doRepoSection(self, repoconf, section)
  File "/usr/lib/python2.3/site-packages/yum/", line 313, in doRepoSection
    mirrorurls = getMirrorList(mirrorlist)
  File "/usr/lib/python2.3/site-packages/yum/", line 390, in getMirrorList
    fo = urlresolver.urlopen(url)
  File "/usr/lib/python2.3/site-packages/urlgrabber/", line 427, in urlopen
    return default_grabber.urlopen(url, **kwargs)
  File "/usr/lib/python2.3/site-packages/urlgrabber/", line 555, in urlopen
    return self._retry(opts, retryfunc, url)
  File "/usr/lib/python2.3/site-packages/urlgrabber/", line 527, in _retry
    return apply(func, (opts,) + args, {})
  File "/usr/lib/python2.3/site-packages/urlgrabber/", line 554, in retryfunc
    return URLGrabberFileObject(url, filename=None, opts=opts)
  File "/usr/lib/python2.3/site-packages/urlgrabber/", line 703, in __init__
  File "/usr/lib/python2.3/site-packages/urlgrabber/", line 747, in _do_open
    fo, hdr = self._make_request(req, opener)
  File "/usr/lib/python2.3/site-packages/urlgrabber/", line 823, in _make_request
    fo =
  File "/usr/lib/python2.3/", line 326, in open
    '_open', req)
  File "/usr/lib/python2.3/", line 306, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.3/", line 491, in <lambda>
    lambda r, proxy=url, type=type, meth=self.proxy_open: \
  File "/usr/lib/python2.3/", line 498, in proxy_open
    if '@' in host:
TypeError: iterable argument required

This is on a machine with nothing special done to it. I wonder what causes that. In any case, after over a week I'm still no closer to watching DVDs on a computer.

More cooking in the evening. Tried a recipe for crispy oil-dripped chicken, but it didn't quite turn out the way I had intended.

Sunday, 6 March 2005 Echunga
Top of page
previous day
next day
last day

Five years today since I joined Linuxcare! Times have certainly changed.

Did some more investigation of the problems I had been having with yum yesterday. After some googling, it seems that it was related to the environment variable HTTP_PROXY. It seems that yum will talk to a proxy if it's set. That's a hell of a way to report an error with the proxy, though.

Reset that and I got a different error message:

=== root@naan (/dev/pts/2) /src/BLFS/Blockpool/trunk/blockpool 58 -> yum install emacs

You have enabled checking of packages via GPG keys.  This is a good thing.
However, you do not have any GPG public keys installed.  You need to download
the keys for packages you wish to install and install them.
You can do that by running the command:
    rpm --import public.gpg.key
For more information contact your distribution or package provider.

Again, no information about where to look for help. After some searching I discovered a file /etc/yum.conf with the following line in it:


That seeemed straightforward enough, so I commented it out. No change. Changed 1 to 0. No change. Then I found a directory /etc/yum.repos.d with lots more files, many with the same line. I suppose that's where I should be loading the public key, but I couldn't be bothered. Commented them out and I was finally able to start my install of Emacs: The problem is, I already had Emacs installed, and yum didn't seem to notice. Not only that, like the Sorcerer's Apprentice I found that it insisted on continuing no matter what I did. Hitting ^C only provoked it to retry: I had to kill the window to stop it. Strangely, though, it didn't happen when I tried the same thing on a different system running Fedora; the difference may be that the first one was running GNOME.

The problem is, I couldn't install vlc like that:

=== root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 5 -> yum install vlc
Setting up Install Process
Setting up Repo:  base
repomd.xml                100% |=========================| 1.1 kB    00:00
Setting up Repo:  updates-released
repomd.xml                100% |=========================|  951 B    00:00
Reading repository metadata in from local files
base      : ################################################## 2622/2622
updates-re: ################################################## 709/709
No Match for argument vlc
Nothing to do

real    0m14.779s
user    0m3.024s
sys     0m0.367s
=== root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 8 ->

It seems that every time you run yum you need to wait these 15 seconds before it comes up with anything of interest. Presumably the repo needs to be set up to handle this kind of installation, and VLC isn't set up. Following the instructions at that link, I downloaded the Fedora tarball and tried:

=== root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 2 -> rpm -U * --force
warning: V3 DSA signature: NOKEY, key ID e42d547b
warning: package libmodplug = 1:0.7-2vlc was already added, replacing with libmodplug <
= 1:0.7-3vlc
warning: package libpostproc = was already added, replacing with li
bpostproc <=
warning: package vcdimager = 0.7.20-1.1.vlc was already added, replacing with vcdimager <= 0.7.20-3
error: Failed dependencies: is needed by cdinfo-0.71-0.i386 is needed by cdinfo-0.71-0.i386 is needed by libvcd-0.7.20-3.i386 is needed by libvcd-0.7.20-3.i386 is needed by libvcd-0.7.20-3.i386 is needed by libvcd-0.7.20-3.i386 is needed by vcdimager-0.7.20-3.i386 is needed by vcdimager-0.7.20-3.i386 is needed by vcdimager-0.7.20-3.i386 is needed by vcdimager-0.7.20-3.i386 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386
        fribidi is needed by vlc-0.8.1-1.i386 is needed by vlc-0.8.1-1.i386 is needed by vlc-0.8.1-1.i386

Well, that seems par for the course. So can yum help me fix these missing dependencies?

=== root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 7 -> time yum install libcdio
Setting up Install Process
(usual messages and 15 second delay omitted)
No Match for argument libcdio
Nothing to do

Say what Tim will, yum doesn't seem to be even a useful tool in solving dependency issues; maybe better documentation will help there. Instead, took a look at the site and found a number of packages. But they still need to be installed :

=== root@eucla (/dev/pts/6) /src/Linux/tarballs 13 -> rpm -i libcdio-0.70-1.i686.rpm
warning: libcdio-0.70-1.i686.rpm: V3 DSA signature: NOKEY, key ID e01260f1
=== root@eucla (/dev/pts/6) /src/Linux/tarballs 14 -> rpm -U vlc/*rce
warning: vlc/ V3 DSA signature: NOKEY, key ID e42d547b
warning: package libmodplug = 1:0.7-2vlc was already added, replacing with libmodplug <
= 1:0.7-3vlc
warning: package libpostproc = was already added, replacing with li
bpostproc <=
warning: package vcdimager = 0.7.20-1.1.vlc was already added, replacing with vcdimager <= 0.7.20-3
error: Failed dependencies: is needed by cdinfo-0.71-0.i386
=== root@eucla (/dev/pts/6) /src/Linux/tarballs 16 -> rpm -U libcdio-0.70-1.i686.rpm
warning: libcdio-0.70-1.i686.rpm: V3 DSA signature: NOKEY, key ID e01260f1
        package libcdio-0.70-1 is already installed
=== root@eucla (/dev/pts/6) /src/Linux/tarballs 17 -> rpm -q libcdio-0.70-1.i686.rpm
package libcdio-0.70-1.i686.rpm is not installed

I tried again with --force, but it made no difference. One more failure for Linux.

Finally rebooted eucla and tried mplayer again. It seems that in the last week or so I blew away a number of dependencies, but after reinstalling the latest version, it worked. Not exactly a success: I've used mplayer before, but found it to be inadequate. Still, after two weekends I can now watch my DVD, sort of.

Monday, 7 March 2005 Echunga
Top of page
previous day
next day
last day

Things have been keeping me pretty busy for the past two weeks, and today I spent nearly all the day catching up on things that I had left behind as a result. Didn't even finish.

This DVD stuff is making some progress, but it's slow. Yesterday Yvonne rented some DVDs from Blockbusters, but we had difficulty watching them: they looked like they had been used as paperweights for sandpaper. Today spent some time trying to copy them so we could watch them at all. The good news is that the DVD drive was able to read them. Burning a new DVD was more of an issue: people told me that burncd doesn't support DVDs, so I had to install the dvd+rw-tools port and run a program with the the incongruous name growisofs. First, though, it seemed appropriate to format the DVD+RW disk I was going to use with dvd+rw-format (how I hate these complicated names!). Running that was less than edifying:

=== root@teevee (/dev/ttyp2) ~ 3 -> dvd+rw-format /dev/acd0
* DVD±RW/-RAM format utility by <>, version 4.10.
:-( unable to open("/dev/acd0"): Inappropriate ioctl for device
Looking at the operation with ktrace showed:
 40005 dvd+rw-format CALL  ioctl(0x3,CAMGETPASSTHRU,0xbfbfdc80)
 40005 dvd+rw-format RET   ioctl -1 errno 25 Inappropriate ioctl for device

It seems that I needed SCSI emulation, the atapicam device. Built a new kernel and booted it, but it appeared to make no difference. It seems that atapicam just adds a device to the existing one, so after installing it my DVD burner was visible as an ATAPI device at /dev/acd0 and as a SCSI device at /dev/cd0. I was able to burn a DVD+RW; but the DVD player could hardly read it at all. Back in eucla (a different machine with a different drive) I was able to read in the DVD and compare it to the original: no difference. But I couldn't play it there either. I suspect that there's some issue with the way the data is written to the DVD that makes it difficult to read. This material is really a minefield.

Tuesday, 8 March 2005 Echunga
Top of page
previous day
next day
last day

Eight years since I returned to Australia! How time flies.

No pressing work today, so spent some time cleaning up things I had left lying since last June: at the time, echunga, my main gateway system, blew up, and for one reason and another I haven't found time to upgrade it. In particular, since then my main NFS-mounted source disk in zaphod, my original SMP test machine. Well, sort of. zaphod's hardware became echunga (running as a single processor), and that's the way it still is.

It doesn't take that long to upgrade a machine, of course: the background was my intention to use it as a testbed for my system upgrade procedures, which are still in disarray. Spent some time working on that and discovered that I had duplicate scripts for doing the same thing in different ways; in general, it was a bit of a mess. Made some progress, but I'm not done yet.

In the afternoon took a breather and went to Meadows with Yvonne while she did some shopping at the “Barn”, the local supply shop. She found a 1 metre high copy of Michelangelo's David statue. She's been wanting one for over 20 years now, so we finally ended up buying it. Back home, it scared the hell out of the dogs, who wouldn't go within 5 metres of it. Interesting reaction; the cats don't appear to have paid it much notice.

In the evening more work on multimedia. I was able to get teevee to display multihead on a TV and a monitor, not for the first time, but that was about all. For some reason, mplayer was installing without the GUI. After some experimentation with the Makefile, discovered that, though it's documented that you can use it with gtk version 2, the build doesn't support it. It doesn't complain; it just doesn't build gmplayer. While experimenting with that, discovered that this time I wasn't able to get mplayer to do its thing:

=== root@teevee (/dev/ttyp6) /home/grog 1 -> mplayer dvd://1
MPlayer 1.0pre6-3.3.3 (C) 2000-2004 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

Playing dvd://1.
Reading disc structure, please wait...
There are 2 titles on this DVD.
There are 22 chapters in this DVD title.
There are 1 angles in this DVD title.
DVD successfully opened.
MPEG-PS file format detected.
VIDEO:  MPEG2  720x576  (aspect 3)  25.000 fps  7500.0 kbps (937.5 kbyte/s)
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
AC3: 5.1 (3f+2r+lfe)  48000 Hz  448.0 kbit/s
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, 16 bit (0x10), ratio: 56000->192000 (448.0 kbit)
Selected audio codec: [a52] afm:liba52 (AC3-liba52)
vo: X11 running at 800x600 with depth 24 and 32 bpp (":0.0" => local display)
vo_xvmc: X-Video extension 2.2
vo_xvmc: X-Video MotionCompensation Extension version 1.0
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 720 x 576 (preferred csp: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
VDecoder init failed :(
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2 (libmpeg2))
Checking audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 48000 hz, little endian signed int
AF_pre: 48000Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 48000Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit...
Starting playback...
VDec: vo config request - 720 x 576 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.

FATAL: Could not initialize video filters (-vf) or video output (-vo).

Exiting...  (End of file)
=== root@teevee (/dev/ttyp6) /home/grog 2 ->

At first that looked like what happened to me last time, but on examination it wasn't the same thing after all.

Tried to connect eucla, my Dell laptop, to the HiFi system, and managed somehow to turn off the UPS, taking down sat-gw, which had been up for 154 days (a record for Linux on this site). The HiFi connection didn't work properly due to lack of cables, so spent the evening watching it on the laptop screen. What frustration!

Wednesday, 9 March 2005 Echunga
Top of page
previous day
next day
last day

Continued work on upgrading echunga today. Getting the scripts together is more work than I thought.

Later, spent more time looking at the multimedia issues. Tried to repeat yesterday's problems with mplayer, but now it works:

VDec: vo config request - 720 x 576 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 1024x576 Planar YV12
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
New_Face failed.  Maybe the font path is wrong.  2 ??% ??% ??,?% 0 0
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.

About the only thing I can think of is that one of the attempts to install gmplayer last night led to the correct CSP being loaded. Further investigation revealed the problem with the fonts: it needs the /usr/ports/multimedia/mplayer-fonts port as well. It seems that the reason it's not installed automatically is because the (theoretical) possibility exists that the system might be running TrueType fonts instead. The possibility is theoretical because it's not configured to use them, as I discovered when I installed them. Installed mplayer-fonts and things looked better.

The next hurdle was the display format. For some reason, instead of setting the display to the standard PAL-B/G format of 720x576, it set 640x480. Investigating/var/log/Xorg.0.log showed that it didn't even try 720x576, presumably because (why?) it didn't have a mode line for 720x576. Spent some time looking for the PAL standard documentation to get the correct parameters for the mode line, and discovered that it appears to be too old to find documentation online. Found one at ETSI, but it related to wide-screen modifications of PAL to run 16:9. Also found other stuff at ITU, but nothing giving me the signal parameters. In the meantime, people dragged up at least one plausible mode line:

<Darius> ModeLine "720x576PAL" 15.125 720 770 842 968 576 579 607 625 Composite Interlace
That might be a basis for something that could work.

Also did some investigation of why the signal was so bright. Dragged out my old HP 1740A oscilloscope (must be 25 years old) and compared the video card output with the tuner output from a VCR and confirmed that the signal frequencies were correct (and that the HP was still correctly calibrated, something I'm sure I can't say about my Tektronix 555). The voltage levels were also roughly the same, but the white background of the X display made the overall level very different. To be investigated further.

Thursday, 10 March 2005 Echunga
Top of page
previous day
next day
last day

So today was the day, and I finally bit the bullet and upgraded echunga to the “new” (last September) motherboard and FreeBSD 5.4 prerelease. I had reason to be so careful. The first set of issues were with rebuilding the hardware:

Finally got the machine up and more or less running. The next step was to get X running. echunga has been running 3 monitors for several years now, and traditionally upgrading X has been a matter of trial and error, the error usually involving the system freezing and requiring the Big Red Button to continue. Modified /etc/fstab to not mount all non-essential file systems, and played around. It looks like the old Matrox G400 (also five years old) has finally had its day. It's a dual-headed card, but the second output had a maximum resolution of 1024x768, so I've never used it, and I couldn't find a way to get it to work with any of the four PCI cards I had at my disposal. Instead ended up with three identical SiS cards:

(--) PCI: (1:7:0) Silicon Integrated Systems [SiS] SiS315PRO PCI/AGP VGA Display Adapter rev 0, Mem @ 0xb0000000/28, 0xdf000000/18, I/O @ 0xc000/7

That seemed to start up quite well, so put the machine back in my office and connected up the monitors. The displays were rather surprising: :0.0 should have been 1920x1440, but came up as 1600x1200. :0.1 was the other ways round: it should have been 1600x1200, but came up as 1920x1440. This is the old iiyama monitor that has been dying for at least 2 years now, and it was getting a bit fuzzy. To my surprise it was sharper at 1920x1440 than at 1600x1200. Later testing showed that it wasn't the monitor at all that was so fuzzy, but either the cable length (I had relocated the machine, so didn't need so long cables) or the display card.

Still further investigation showed that the SiS cards aren't that spectacular: though they have 32 MB of memory, and even 2048x1536 at 32 bpp would only need 12 MB memory, the AGP card has a maximum pixel clock of 220 MHz. The PCI cards are identical, but one claims 195 MHz, the other 390 MHz. I suspect a bug in Xorg (6.8.1) here, but also noted problems with the second card when running at 1600x1200 in 24 bpp mode, so decided to put in a new nVidia card that I had bought last week. It claims a 350 MHz maximum clock, more than I need, and with that I was able to (finally) reinstate my X configuration.

Well, almost. When I restarted X I was unable to connect any clients at all, neither the window manager nor local or remote:

AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 3 rejected from IP
AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 7 rejected from IP
AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 6 rejected from IP

No indication of why, but when I stopped the server I got a message (now lost) indicating an inability to lock ./Xauthority. After further investigation discovered that the issue was because I had mounted /home read-only. After that, got things working normally.

The rest of the system still wasn't working too well, though. For some reason kernel PPP dialled and made a phone connection, but then dropped the connection before establishing a network connection. Hopefully I'll have DSL in the near future; in the meantime, started user PPP, which worked without problems.

Well, without immediate problems. I then had significant delays with DNS lookups, and I couldn't get reverse lookups done, though echunga is the primary name server for the zone. Further investigation showed that ppp had apparently overwritten my /etc/resolv.conf file. I'll have to find a way to stop it doing that.

After that, there wasn't much left to do (nor time to do it). Mail is still not running, but it's only a backup MX, so that shouldn't be an issue. The web server came up relatively well, but my own pages ( were inaccessible. It seems that something's different with Apache version 2, which is what I installed. That was enough for one day, though.

While waiting for fsck, also had time to look at the TV scan stuff. The following mode line seems to do the trick for PAL:

Section "Monitor"
        Identifier   "TV"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        HorizSync    15.625
        ModeLine     "720x576" 15.125   720 768 840 968  576 592 607 625   Composite  Interlace

I'm not out of the woods yet, though. Now mplayer detects the size and enlarges it:

Starting playback...
VDec: vo config request - 720 x 576 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 1024x576 Planar YV12

gmplayer then manages to position itself outside the screen. What a mess!

Friday, 11 March 2005 Echunga
Top of page
previous day
next day
last day

Friday is meeting day, so didn't get much done. Picked up my colour laser printer, now repaired after replacement of a motor board. I wonder how that happened.

In the evening finally put teevee in the HiFi cupboard, and managed to watch a DVD on the TV. I had probably the heaviest remote control ever: eucla, a Dell Inspiron 9100, which weighs in (according to Dell) at 4.05 kg. I ran x2x to directly control gmplayer on teevee:0.1, and—it worked! Even very well, within the limitations of gmplayer. One of the things that really annoy me about infrared remote controls is that they're not very reliable: the device often don't respond the first time. It wasn't until I used the laptop keyboard that I realized just how much that got on my nerves.

Next step is to get the tuner working and find an easier method of remote control.

Saturday, 12 March 2005 Echunga
Top of page
previous day
next day
last day

Another day spent chasing multimedia stuff, with little to show for it. My intention had been to get a Hauppauge tuner card working. First I had to find out how to use the thing at all: there's a driver, but no program to go with it. It seems that the only clients are in the Ports collection. It turned out that I already had mencoder, which is part of the mplayer port; others suggested to me to use xawtv and fxtv. Tried both of them without success.

xawtv says “If all else fails, RTFM”. All else failed. The application came up claiming an impossible combination of standards, NTSC and Western European TV frequencies (NTSC isn't used at all in Western Europe), and I couldn't change it. So I read the FM and discovered:

       xawtvrc -- TV apps config file

So I created a file /etc/X11/xawtvrc and ran things. No change. Then I ran ktrace and discovered:

  5996 xawtv    NAMI  "/usr/X11R6/lib/X11/xawtvrc"
  5996 xawtv    RET   open -1 errno 2 No such file or directory

So I moved the file there and yes, it seemed to accept it, using PAL and Australian frequencies. But still no signal. About the only message I got was, once a second,

bktr: sigalrm
bktr: sigalrm

fxtv is less verbose and even more difficult to understand, but there was no obvious difference there. On a hunch, looked at the sysctls that relate to the driver and found:

=== root@teevee (/dev/ttyp4) ~ 42 -> sysctl hw.bt848
hw.bt848.card: -1
hw.bt848.tuner: -1
hw.bt848.reverse_mute: -1
hw.bt848.format: -1
hw.bt848.slow_msp_audio: -1

This all suggests that the driver isn't finding things. dmesg told me:

bktr0: <BrookTree 878> mem 0xdddfe000-0xdddfefff irq 17 at device 6.0 on pci0
bktr0: Card has no configuration EEPROM.  Cannot determine card make.
bktr0: Pinnacle/Miro TV, Temic PAL I tuner.

Strange that it first says that it can't determine what it is, then gives the information that should have shown up in the sysctls. More important, though, is the IRQ number. As it suggests, investigation shows that this motherboard has an IO-APIC:

ioapic0 <Version 0.3> irqs 0-23 on motherboard

So maybe we're not getting interrupts. The driver should complain, of course, but nothing would surprise me any more.

In the evening, watched another rented DVD, “The affair of the necklace”. This one was completely confusing: it had 18 “titles”, and the first had four sound tracks, English, French, Italian and American. The American track was the default, and it was a commentary about the film rather than the dialogue. As a result, I got the impression that it was not the main feature. Wouldn't it be nice to have a directory on the DVD to say what's what? It seems that the DVD manufacturers are going out of their way to be confusing. This has nothing to do with my software problems, of course, but maybe it's indicative of the general confusion in the industry.

Sunday, 13 March 2005 Echunga Images for 13 March 2005
Top of page
previous day
next day
last day

I had a number of multimedia things to do today. The big one was to get the tuner card working, but first there were a couple of other packages to try. One person recommended ogle, which installed with a minimal man page that didn't even give information on the key bindings (you have to fight through the XML in the man page for the config file to find that). There also seems to be no way to specify the device you want to read from (apart from setting it in the config file). The default was also incorrect, so I got:

=== root@teevee (/dev/ttyp2) /usr/local/share/ogle 5 -> ogle
libdvdread: Can't stat /dev/acd0c
No such file or directory
ERROR[ogle_nav]: faild to open/read the DVD
DVDSetDVDRoot:: Root not set

The man page made some suggestions that looked like they might work, but obviously there are different views on what constitutes a path name:

=== root@teevee (/dev/ttyp2) /usr/local/share/ogle 6 -> ogle -u gui /dev/acd0
FATAL[ogle_ctrl]: init_decoder(): path: /usr/X11R6/lib/ogle/ogle_gui
execv: No such file or directory
Finally I had to set it in the config file:
--- oglerc      2005/03/13 00:20:17     1.1
+++ oglerc      2005/03/13 00:59:03
@@ -14,7 +14,7 @@
-      <path>/dev/acd0c</path>
+      <path>/dev/acd0</path>

After that it worked, but I couldn't find a way to run it in full-screen mode. In general it doesn't seem to have as many features as mplayer, and also nothing that mplayer doesn't have, so gave up on it.

Edwin Groothuis had suggested using vobcopy, which copies data from file system mounted DVDs. It didn't work quite the way I expected. In the following, I've omitted most of the copious output:

=== root@teevee (/dev/ttyp5) /home/dvd 5 -> vobcopy -v
Successfully copied file /home/dvd/DOUBLEWHAMMY2-2.vob
# of separate files: 2

Copying finished! Let's see if the sizes match (roughly)
Combined size of title-vobs: 7722770432 (7365 MB)
Copied size (size on disk):  3861385216 (3683 MB)
[Error] Hmm, the sizes differ by more than 2000
[Hint] Take a look with MPlayer if the output is ok

This is nonsense, of course. I don't know where it gets the size of 7.4 GB, but it's obviously wrong:

=== grog@teevee (/dev/ttyp1) ~ 16 -> du -sm /cdrom
3785    /cdrom/

It seems to do this every time. On another occasion, I got:

Used the linux statfs
In freespace_getter:for /home/dvd/ : 110952919040 free
In freespace_getter:part1 54176230, part2 2048

Outputting to /home/dvd/DVD_VIDEO1-1.vob

[Error] error opening file /home/dvd/DVD_VIDEO1-1.vob.partial

Doesn't that look like Microsoft? “Error”! What error? It proved to be a permission issue, but why doesn't the program report it?

On the up side, I was able to view the results with mplayer. I had tried to do this earlier, but it didn't work: it seems that the copied images were corrupted. In other words, as long as there are no problems, vobcopy seems to do the trick. I wonder what I should use to copy the sandpaper paperweights that I rent from Blockbusters. Somebody recommended dvdrip, but that required installing multiple ports:

=== root@teevee (/dev/ttyp2) /usr/ports/multimedia/dvdrip 3 -> ls -lrt /var/db/pkg/
drwxr-xr-x  2 root  wheel  512 Mar 13 12:33 svgalib-1.4.3_4
drwxr-xr-x  2 root  wheel  512 Mar 13 12:34 texi2html-1.76_1,1
drwxr-xr-x  2 root  wheel  512 Mar 13 12:42 p5-XML-Writer-0.530
drwxr-xr-x  2 root  wheel  512 Mar 13 12:42 p5-Gtk-0.7009_1
drwxr-xr-x  2 root  wheel  512 Mar 13 12:42 gdk-pixbuf-0.22.0_3
drwxr-xr-x  2 root  wheel  512 Mar 13 12:59 gsfonts-8.11_2
drwxr-xr-x  2 root  wheel  512 Mar 13 13:02 sdl-1.2.8,2
drwxr-xr-x  2 root  wheel  512 Mar 13 13:02 ffmpeg-0.4.9.p1_2
drwxr-xr-x  2 root  wheel  512 Mar 13 13:25 glib-2.4.8
drwxr-xr-x  2 root  wheel  512 Mar 13 13:26 libltdl-1.5.10
drwxr-xr-x  2 root  wheel  512 Mar 13 13:26 libfpx-
drwxr-xr-x  2 root  wheel  512 Mar 13 13:26 jbigkit-1.6
drwxr-xr-x  2 root  wheel  512 Mar 13 13:26 ghostscript-gnu-7.07_12
drwxr-xr-x  2 root  wheel  512 Mar 13 13:26 mpeg2codec-1.2_1
drwxr-xr-x  2 root  wheel  512 Mar 14 10:15 speex-1.0.4_1,1
drwxr-xr-x  2 root  wheel  512 Mar 14 10:15 libao-0.8.5
drwxr-xr-x  2 root  wheel  512 Mar 14 10:15 curl-7.12.3_2
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 vorbis-tools-1.0.1_3,3
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 pstree-2.25
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 p5-Storable-2.13
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 p5-GdkPixbuf-0.7009_2
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 p5-Event-1.02
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 ogmtools-1.4.1
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 mplayer-gtk-0.99.6
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 liveMedia-2005.03.11,1
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 fping-2.4b2
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 ImageMagick-
drwxr-xr-x  2 root  wheel  512 Mar 14 10:17 dvdrip-0.50.18_2

As a result, and as the modification times show, it took nearly 24 hours to install, along with various mishaps.

As if all that wasn't bad enough, I have been experiencing hangs during POST on reboot. Finally it got to the point where it wouldn't find the disk at all. Further investigation showed:

  1. For the second time this week, I have a dying disk.
  2. In the Good Old Days disks died with head crashes or other mechanical issues. That seems to be the exception nowadays. They seem to die with electronics problems.

  3. On a hunch, I put the dead disk back in as a slave to a good disk. It worked! I'm guessing that the failure was in a place that isn't needed by slave disks. It's interesting in that connection how many drives fail on reboot after having run reliably for months. I wonder what functions are performed, and why they should be so difficult.

    With that success in place, tried the dead disk from old echunga, which died earlier this week. Unfortunately that didn't work: although it was set as a slave, the BIOS didn't even detect the master device. Maybe the drive was holding on to the bus.

Working on the tuner card was less fruitful. It turns out my card has a little-known tuner (the metal box at top left of the following photo):

Image title: tuner card 1          Dimensions:          2048 x 1536, 528 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 13 March 2005, thumbnails          All images taken on Sunday, 13 March 2005, small
Diary entry for Sunday, 13 March 2005 Complete exposure details


It has the clear marking TVF-8533-B/DF, for which I found a number of hits, many in this part of the world. “Pablo” describes how to set it up under Linux, but it's not clear how to convert those instructions to FreeBSD. Ran the card with video input mode from a camera, and that worked perfectly, so at least we've narrowed it down. Spent some time putting debugging code in the driver (after removing it from the kernel and changing it to a KLD), but didn't get any conclusive results.

Monday, 14 March 2005 Echunga Images for 14 March 2005
Top of page
previous day
next day
last day

Woke up this morning and tried to turn the radio on. It didn't work: we had had a power failure 40 minutes earlier, and I had lost all systems with the exception of battunga. Grr. In addition, the new, expensive Opti UPS refused to accept the power input from the generator, so I had to turn it off. Strangely, the cheap Opti models did handle the generator power with no problems. Time for some new UPSs.

Spent the day working on a simple disk access test program. Tried the alternatives of stream I/O, system call interface I/O, andsystem call interface I/O with O_DIRECT. The results are not all in yet, but it almost looks as if O_DIRECT slows things down. We've seen a 10% improvement in performance in real-world programs by using O_DIRECT, so this may just be another indication that cartoon figure programs don't have much relationship with the Real World.

My TiVo still seems to be working since the power failure, but the Ethernet connection isn't, though the switch shows that the interface is up. I wonder what went wrong there, and how I installed the software in the first place.

Tuesday, 15 March 2005 Echunga Images for 15 March 2005
Top of page
previous day
next day
last day

Yvonne into town today and returned with a handful of cheap UPSs, not quite the same as the ones that performed well yesterday, also the motherboard, memory and CPUs for my new Opteron machine, and my father.

Putting the Opteron machine together was interesting: this motherboard, an MSI K8T Master2-FAR, does not seem to be the best board out there, but it is the cheapest. It looks like it's a dual processor add-on to the single processor version, and as a result it comes with two different heat sinks, and will not accept the standard AMD heat sinks:
Image title: opteron fan 1
Complete exposure details
Dimensions: 601 x 451, 64 kB
Dimensions of original: 2048 x 1536, 496 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Tuesday, 15 March 2005:
thumbnails    small images    diary entry

In particular, the cooler for the second CPU has mounting issues with the AGP slot, so it's off-centre:
Image title: opteron fan 4
Complete exposure details
Dimensions: 450 x 600, 46 kB
Dimensions of original: 1536 x 2048, 400 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Tuesday, 15 March 2005:
thumbnails    small images    diary entry

Got the machine put together, and powered it up, and it didn't get as far as a display on the screen: it just beeped, a single long beep every 5 seconds or so. Everything pointed to memory, but the memory itself was fine. Finally there were suggestions, not mentioned in the documentation, nor at the time of order, that this motherboard requires registered memory to work correctly. Tim Stoakes later confirmed that he had checked the docco and also not found any reference to such a requirement. That doesn't mean it doesn't exist, of course, just that the docco could be wrong.

Wednesday, 16 March 2005 Echunga
Top of page
previous day
next day
last day

More work on performance today. Does it ever take a long time! I'll be happy when I finally have the Opteron box up and running, though it's not clear how much difference that will make. Spent a lot of time working on graphical representations of the results, which seem to indicate that stream I/O is the most efficient and system call I/O with O_DIRECT is the least efficient. That may be different with different loads on the system; we'll have to find out. It's also interesting that more threads seem to cause I/O performance to deteriorate.

Thursday, 17 March 2005 Echunga
Top of page
previous day
next day
last day

Spent the morning playing around with POSIX.4 asynchronous I/O, not helped by the fact that I had lost the tutorials I had found on the web last month, and that I couldn't find them again. The concept's nothing new; I used similar constructs in Tandem's Guardian operating system over 25 years ago. All the more surprising that the current model is defective. In Tandem's TAL programming language you'd use a function (sorry, procedure) called AWAITIO to wait for completion of a specific I/O or of any I/O; in either case, the function returned information to identify the I/O that had completed. Looking at the FreeBSD man pages, it seems that aio_waitcomplete would do the same thing:

     The aio_waitcomplete() system call waits for completion of an asynchro-
     nous I/O request.  Upon completion, aio_waitcomplete() returns the result
     of the function and sets iocbp to point to the structure associated with
     the original request.  If an asynchronous I/O request is completed before
     aio_waitcomplete() is called, it returns immediately with the completed
I had got half way through writing my request code when I read:
     The aio_waitcomplete() system call is a FreeBSD-specific extension.

So back to POSIX.4. Why doesn't it have such an obviously useful function? The only things that are offered are:

What a mess!

Didn't get that finished: in the afternoon to two meetings, of the Board of Management of the ICT Council of Australia, followed by a full council meeting.

Friday, 18 March 2005 Echunga
Top of page
previous day
next day
last day

Meeting day today, so got very little done. At work, Tim gave me the memory for obelix, the new Opteron machine, but I didn't get round to installing it.

Got my flight ticket quotes to Montréal for the BSDCan; I've never seen such expensive flights. It looks like it would be considerably cheaper to fly round the world, but that imposes at least three stops in at least two continents. I wonder what I could do (and where) in Europe or Asia.

In town, bought a TV antenna masthead amplifier, supposedly offering 34 dB amplification. Once back home, tested it at the HiFi end and noted not too much difference; it's clear, though, that the marginal reception of Channel 7 is hampered at least by ghosts, which won't go away with an amplifier. Hopefully Channel 31 will be better when the amplifier is mounted in its correct place.

Saturday, 19 March 2005 Echunga
Top of page
previous day
next day
last day

More messing around today. In the morning into the roof to connect up the masthead amplifier I bought yesterday. What a mess these electricians make! Only a few weeks ago I had asked one to look at the antenna, and he told me that all was well, but when I got up there I found the antenna pointing down about 15° at the front. Back in 2001 they had attempted to justify the inordinate time they took by the careful cable routing they claimed to have used. What I found told a different story: I found cables laid across the ground. I also ended up bringing back down a number of bits of cable they had left behind. Anyway, the amplifier worked first time, despite my concerns, and we now get reasonable, if not good, reception of Channel 31.

Installed the memory in obelix, and it worked. So I had, indeed, been sold the wrong memory, and the claims that Opterons need registered memory seems to be true. That wasn't the end of the story, though: it was still running in i386 mode, and to run it in AMD64 mode seems to be the path less travelled. The FreeBSD release CDs don't appear to cater for AMD64 at all; indeed, they don't even mention the architecture in the documentation. Did some snooping around the net and found little of encouragement. Peter Wemm had written a mail message on the subject back in December, inviting documentation of a rational installation process, so got started on that. Ran into trouble pretty soon: it wanted the local system to have the users and groups of the target system. Pondered that and moved on to other things.

Gradually I'm coming to terms with mplayer, and in the afternoon watched TV without much difficulty. The evening was a different matter, though: for no apparent reason gmplayer started getting SIGSEGVs all the time. It would have suggested hardware problems, except that the SIGSEGVs were obviously related to specific actions, notably gmplayer menus, and though they actually occurred in mplayer, running mplayer directly was not a problem. Also there were no problems running anything else. I wonder what's causing that, but it confirms my opinion that mplayer, like most other multimedia software, is a real mess.

Sunday, 20 March 2005 Echunga
Top of page
previous day
next day
last day

Somehow I got nothing done today. It didn't help that I had to bottle some beer, and that got started late because of computer problems: decided to use Yana's old Dell Latitude laptop as a replacement for the Inspiron 9100 as TV remote control, but first tried to back up to teevee so that I could burn a DVD of the old contents. That led to a repeatable panic in NFS—at least until I set up a dumpdev, after which it no longer occurred.

As a result of that, finished bottling my beer too late to go riding, so spent a little time pottering around and watched TV. Confirmed that the SIGSEGVs from gmplayer yesterday were really a gmplayer issue, though I have a horror of putting the thing in the debugger: used mplayer instead, which has an interesting issue that it uses the PgUp and PgDown keys to move 10 minutes at a time; xterm also uses them, and it gets first cut, so they're no longer available to mplayer. I'll have to investigate how to handle that.

Monday, 21 March 2005 Echunga
Top of page
previous day
next day
last day

Back to work on obelix first thing this morning. After fixing the missing users in the host machine, ran into further problems: although told to build a world for amd64, some components were built for i386. It proved that many of the system Makefiles don't handle cross-compilation correctly. Also heard some reports that the cross-compiler didn't work correctly either, so even after installation it would be likely that the system wouldn't work anyway. Downloaded a boot CD-ROM image from and discovered that it was exactly that: just the kernel and klds. I wonder what use that is. Downloaded another “mini-installation” image and installed that, but couldn't boot: it looked as if the disk was dead. Tried a new disk, and that worked fine; but by then the day was over.

In the meantime working on aio, and finished modifying last week's test program to use it. The documentation is really pretty minimal, and rather frustratingly the program worked first time. I always get the feeling that something has gone wrong when that happens.

The results were interesting: it seems that, at least under Linux, aio does not offer any increase in parallelism, and the performance was independent of the number of concurrent I/Os. What a pity.

Tuesday, 22 March 2005 Echunga Images for 22 March 2005
Top of page
previous day
next day
last day

Back to work on obelix today, to install a real partitioning scheme on the new disk that I had installed. It failed in exactly the same way! On further (lengthy) investigation discovered that the FreeBSD amd64 implementation doesn't work well with boot partitions beyond a certain offset from the start of the disk, probably 8 GB. Moved it in front and it installed fine on the old disk. Spent most of the rest of the day upgrading to the latest version and installing things like X, which I need at least for the clients.

More work on the aio tests, without getting very far. Started running the tests on FreeBSD, which proved more difficult than I had expected: the original program (not mine) had allocated buffers of 100 kB on the thread stack, something that FreeBSD doesn't like. Also the first tests on obelix failed outright:

Program received signal SIGSYS, Bad system call.

Later found that that was because of missing aio on amd64; apparently it's buggy.

Today was harvest day for my hops. Ended up with 600g (before drying) of “Pride of Ringwood” hops:
Image title: hops 1
Complete exposure details
Dimensions: 602 x 452, 68 kB
Dimensions of original: 2304 x 1728, 544 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Tuesday, 22 March 2005:
thumbnails    small images    diary entry

Now to work out the best way to dry them. Initially I thought of a cool oven (40°), but I was worried that they might lose what little aroma they have. Decided to leave them to dry out at room temperature, which I suppose could take a couple of days.

Wednesday, 23 March 2005 Echunga
Top of page
previous day
next day
last day

More attention to the aio problems on obelix this morning. The reason is simple: by default aio isn't in the kernel. Had to load the kld (though of course it's in the kernel config file for the next build). Even then got the interesting message:

WARNING: Network stack Giant-free, but aio requires Giant.
    Consider adding 'options NET_WITH_GIANT' or setting debug.mpsafenet=0
It didn't stop the tests, though; I only found it after I had finished.

The tests themselves were interesting. The run time for each variant was:

Variant Run time User time System time
Syscall I/O 13.27 0.06 13.21
aio 34.15 0.11 33.36
Syscall with O_DIRECT 1067.35 0.01 17.05
Stream I/O 118.64 5.57 14.40

All of these speeds—even for O_DIRECT—were so much better than on the slower machines that something had to be wrong. Further investigation, as well as better stats produced by FreeBSD, showed that I wasn't performing any I/O in most cases, rather forcibly proving that it didn't make much sense to repeatedly test a 1 GB file on a machine with 4 GB of memory, so set to changing that. Tested again with a 150 GB file and got these results:

Variant Run time User time System time
Syscall I/O 1716.05 0.17 24.23
aio 2044.74 0.15 18.95
Syscall with O_DIRECT 1273.94 0.05 17.24
Stream I/O 1823.98 6.33 32.03

There are a few interesting things to note here:

In the afternoon, called Internode, Westnet and (finally) Telstra to find out what was going on with ADSL connections. None of them were helpful. Kerry at Internode (in Adelaide) had never heard of Echunga, only 30 km from where he was: “What state is that?” All three said that there was no DSLAM in Echunga, and [cw]ouldn't give me an date for it, though I have mail from somebody at Westnet pointing to their February newsletter, which states: “Broadband ADSL is coming soon to the following areas... Echunga”. Finally Chris at Telstra did some investigation and found that it would be installed next month. That's what they said in January: “next month”. I wonder when it will be “this month” or even “now”. Signed up with Telstra; at least they could give me the opportunity to do so.

Thursday, 24 March 2005 Echunga
Top of page
previous day
next day
last day

More work on my I/O performance tests today. Tried running them on a Vinum volume with 14 disks, first concatenated and then striped. These are the old disks from the Sun storage array that I bought years ago, and they're frantically slow by modern standards. Realised that even just writing the initial file (55 GB) would take more than all day, so changed to a striped array, which showed a significant performance increase, though not as much as I would have expected; I suspect that I/O scheduling issues are limiting things, and that FreeBSD does not expect a single file to be spread over 14 spindles. More investigation is needed, including whether Linux can do better.

After solving my cache issues by umounting and mounting the file system between each test, got very different results from yesterday:

Variant Run time User time System time
Syscall I/O 67.04 0.09 2.53
aio 66.14 0.04 0.27
Syscall with O_DIRECT 67.04 0.06 2.64
Stream I/O 91.63 0.80 4.14

These results aren't directly comparable with yesterday, since I was using different disks and a different number of iterations (so that I could finish at all before leaving for the outback). But suddenly aio looks like the best alternative instead of the worst. And for the first time stream I/O looks significantly worse. That's a long way from what I expected, and apart from confirming my expectations for stream I/O, posed more questions than they answered. Looks like even more work to be done the week after next.

Friday, 25 March 2005 Echunga → Mannum → Morgan → Burra → Hawker
Top of page
previous day
next day
last day
546 km

Today was the first day of our outback trip. When I got up this morning and opened the blinds, I was greeted by the sound of a couple of kookaburras, laughing their heads off in the gum tree outside the bedroom window. I've only had that happen once before, some years ago when I was in the middle of the most complicated parts of the Vinum code. As then, I wonder what they know that I don't.

Spent more time than expected with preparations, and finally left home at 11:30, heading not North but East. I wish we had better maps! By the time we got to Mannum we had already taken a wrong turn on a parallel road that took us on the other side of the river Murray. Not a big deal, we thought, until we discovered a queue of about 50 cars waiting to cross: there's a ferry there, not a bridge.

On through places with names like Cambrai and Sedan—the former was on the river Marne and used to be called Rhine Villa. A relatively permanent reminder of the stupidity people exercised here in the Great War.

By 14:00 we got only as far as Morgan, and were thus not much closer to the Flinders Ranges than we were when we left. From then on the road was pretty monotonous, though, and we made pretty good progress. It's strange to note that the side roads are in better condition than the main roads.

In Hawker to the Ghan restaurant again. This time we had what appeared to be a Flemish pair as company. Service could have been better, but the food was still OK.

Saturday, 26 March 2005 Hawker → Marree → William Creek Images for 26 March 2005
Top of page
previous day
next day
last day
606 km

Off pretty early this morning and had breakfast at the motel, where I also got some interesting information about visiting the Flinders with horses from Mick, the proprietor. Looks like the best time of the year for a visit is from right now to the end of April. Currently you can agist horses for free at the race track, which makes it sound particularly attractive.

Then off in the direction of Wilpena Pound, slightly marred by having to go back to pick up things we had forgotten. Wilpena was about as interesting as last time we visited. I suspect it would be a lot more interesting on horseback, but as it was, we drove in and out again in less than 10 minutes. On to Blinman this time, since last time round I had been down Brachina Gorge. This time took Parachilna Gorge, which was not nearly as interesting.

On to Marree, and 13 km before had a punctured tyre. That's the first time in a long time; it was pretty messed up, too, and we had to have it replaced in Marree (a place that used to be called Hergott [sic] Springs; another cultural casualty of the Great War), which was done in record time: within 30 minutes of the puncture, we had a new spare tyre in the back of the car, which included repacking the boot twice.

The records didn't stop there, unfortunately. 15 km outside Marree on the Oodnadatta track we had another flat, and back to pick up another tyre. The whole business, including lunch, took 2 hours, and we didn't finally leave for William Creek until 15:08. Fortunately our bad luck didn't hold out, and we made it to William Creek in about 2 hours.

Spent the night in the hotel; they have changed owners since last time, and they have a new cook, who doubles as bouncer, but he doesn't cook breakfast. Had more kangaroo to eat, in fact done better than last night at the Ghan, and talked to a number of European tourists who came in for a drink; they're in tour buses that include meals, so they didn't stay. Not exactly a recommendation for the cuisine at the pub, of course. One of the tourists was from Warendorf and had also worked for Bischof und Klein in Lengerich, where I did quite a bit of work 30 years ago.

Sunday, 27 March 2005 William Creek → Oodnadatta → Marla → Coober Pedy Images for 27 March 2005
Top of page
previous day
next day
last day
638 km

Today the clocks went back to winter time, and they're not in a hurry in William Creek anyway, so we couldn't get breakfast until 8 am (9 am yesterday). Breakfast would have been nothing worth mentioning if it hadn't been for its spectacular predecessor:
Image title: William Creek breakfast 1
Complete exposure details
Dimensions: 600 x 450, 85 kB
Dimensions of original: 2304 x 1728, 846 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Sunday, 27 March 2005:
thumbnails    small images    diary entry

Strangely, the place was completely empty except for us. Last time it was full. I wonder what story there is there.

Off then North on the Oodnadatta Track. I had been told at the hotel that the road was better that side of William Creek, but it wasn't for us. Despite my previous satisfaction with our Holden VT Commodore, the ground clearance is far too low for this kind of terrain, and we were continually grounding (well, hitting the exhaust pipe on the ground).

Oodnadatta wasn't much to see:
Image title: Oodnadatta 1
Complete exposure details
Dimensions: 600 x 450, 75 kB
Dimensions of original: 2304 x 1728, 1121 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Sunday, 27 March 2005:
thumbnails    small images    diary entry

On to Marla went through some interesting geological areas. Stopped in one place where there was a surprising number of green stones and picked one up; in the process discovered that the dust on the outside of the car was also green.

In Marla it became evident that Dad was not handling the journey well. It's obviously too tiring for him, and reluctantly started heading back. Made it as far as Coober Pedy (the next place would have been Port Augusta, another 537 km), where we had dinner at the same Greek place that we went to last time. There we bumped into the German/Canadian couple from Neanderthal who were in the room next to us last night in William Creek. As I had told people last night, such chance meetings are to be expected.

Monday, 28 March 2005 Coober Pedy → Coober Pedy → Woomera → Port Augusta → Echunga Images for 28 March 2005
Top of page
previous day
next day
last day
1051 km

Off early this morning South, not passing any petrol stations. Checked the indicators; 200 km to empty. A “major rest area” was coming up in 90 km, so pressed on. As I went, doubts assailed me: the next one beyond there would have been Glendambo, over 250 km and thus out of range. Finally checked my documentation, which showed no petrol before Glendambo. Back to Coober Pedy and filled up, losing somewhat over 100 km in the process. A good thing I did, though: a “major rest area” has a chemical toilet and a little bit of shade, neither food nor petrol.

Again a brief detour to Woomera, where the current lead attraction, the detention centre, has been closed down, then on to Port Augusta, where we had lunch and joined to long trek back to Adelaide: today was Easter Monday, and the traffic was worse than I have ever seen it. By the time we got to Port Wakefield, 100 km from Adelaide, it had slowed down to a crawl. Turned off east to Balaklava and was more than slightly astonished to discover that there was no traffic at all. Why are people such sheep?

On through Gawler and the Adelaide Hills, discovering in Kersbrook that I had a slow puncture in what had been the spare tyre until Marree. Pumped it up and on, getting held up at Oakbank by singularly incompetent traffic police, who blocked the main road for at least 10 minutes to let people out of the race meeting, which had just finished. All would have been well if they had merged the traffic, but they blocked it altogether. Turned around and back home via Nairne and Littlehampton. What an end to the journey!

Tuesday, 29 March 2005 Echunga Images for 29 March 2005
Top of page
previous day
next day
last day

Back to work today, with a lot to catch up on. The frame of my glasses broke just before leaving for the Outback, so I had to go to Stirling to have that attended to. Also took a look at the car, which had suffered quite a lot on the Oodnadatta track:
Image title: car 7
Complete exposure details
Dimensions: 601 x 451, 38 kB
Dimensions of original: 2048 x 1536, 304 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Tuesday, 29 March 2005:
thumbnails    small images    diary entry

The entire exhaust needs replacing; the dents on the transmission and differential are also indicative of a lot of luck. That's the last time I take a Commodore to the Outback.

I've been thinking about installing ADSL for some time now, and last week I applied with Telstra, but it has had a relatively low priority—until today. I replied to something last week that looked like a borderline scam/spam, and discovered that it included a Microsoft “Word” attachment telling me that my satellite service would terminate at the next month. It also asked if I wanted to arrange an alternative service with them. Some hopes! Their web site requires a plugin that I don't use, and they send messages barely distinguishable from spam.

Spent a bit of time checking the current status. Hopefully the Echunga exchange will still be provisioned on 18 April, but who knows when I will then get a connection: at the distance I am from the exchange, and given the condition of the phone lines here, it could be touch-and-go.

Wednesday, 30 March 2005 Echunga
Top of page
previous day
next day
last day

Gradually restarting last week's testing. All the I/O tests were done without any significant CPU load, so they were just testing the way the system dealt with the disk bottlenecks. The last one was a little different for two reasons: it ran over a RAID array with 14 disks, apparently more than the FreeBSD I/O system can handle, and it umounted and remounted the file system between the tests to minimize cache effects.

Decided today that it would be interesting to see how this varied under load, so started off essentially the same tests with eight looping processes sucking up all excess CPU time. The first of 36 tests ran forever: by the evening it was still running, so I stopped it and restarted with 1% of the previous iteration count. That should still be accurate enough.

In the meantime played around with obelix. I had previously had problems to boot it with 8 GB of memory (what a far cry from my university days, where the main university computer had 131 kB memory after an upgrade!). Tried again and had problems again. Lots of experimentation, but couldn't find the cause.

Apart from that, caught up (a little) on some documentation. A lot has arrived over the last few months, and I just haven't had time to read it.

Thursday, 31 March 2005 Echunga
Top of page
previous day
next day
last day

More investigation of the problems with obelix and 8 GB memory today. It's looking more and more like a software bug, though some people get quite heated about it. Interesting to note that the system reports 3.5 GB when booted with 4 GB memory (there's a 512 MB hole in the address space at 3.5 GB, and either the BIOS or the system just throws away the other 512 MB—more memory than any of my systems had in total until a couple of years ago. I suspect there's a way to fix that. Also, when reporting 8 GB, it's ignoring the 512 MB hole.

Apart from that, more testing. It's really difficult to keep the various tests apart, and somehow I managed to confuse the Linux and FreeBSD evaluation scripts (which differ because of the differing output of time(1)).

Top of page Previous month Greg's home page Today's diary entry Next month Greg's photos Copyright information

Valid XHTML 1.0!

$Id: diary-mar2005.php,v 1.50 2015/10/14 22:55:50 grog Exp $