|
| Greg's diary |
| March 2005 |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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:
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:
$ ulimit -d 1048576But it doesn't. It doesn't complain, just nothing happens: the 512 MB (524288 kB) limit is the system-wide hard limit.
Then there's the entry in the /etc/login.conf file, which specifies a limit for a particular login class. This one's easy: it's set to not restrict anything.
Then there are the man pages for the setrlimit system call and friends. They don't help either.
Looking at /usr/src/sys/conf/NOTES, one of the inputs for the LINT configuration file, reveals:
# Certain applications can grow to be larger than the 512M limit # that FreeBSD initially imposes. Below are some options to # allow that limit to grow to 1GB, and can be increased further # with changing the parameters. MAXDSIZ is the maximum that the # limit can be set to, and the DFLDSIZ is the default value for # the limit. MAXSSIZ is the maximum that the stack limit can be # set to. You might want to set the default lower than the max, # and explicitly set the maximum with a shell command for processes # that regularly exceed the limit like INND. # options MAXDSIZ=(1024UL*1024*1024) options MAXSSIZ=(128UL*1024*1024) options DFLDSIZ=(1024UL*1024*1024)
maxdsiz = MAXDSIZ;
TUNABLE_ULONG_FETCH("kern.maxdsiz", &maxdsiz);
############################################################## ### Kernel tunables ######################################## ############################################################## #hw.physmem="1G" # Limit phyiscal memory. See loader(8) #kern.dfldsiz="" # Set the initial data size limit #kern.dflssiz="" # Set the initial stack size limit #kern.hz="100" # Set the kernel interval timer rate #kern.maxbcache="" # Set the max buffer cache KVA storage #kern.maxdsiz="" # Set the max data sizeThat looked like the one. Looking at the example of hw.physmem I set kern.maxdsiz to 2G and rebooted. No change.
kern.maxdsiz="2147483648" # Set the max data size
It works. But what a pain. Yes, having the kernel source is a great advantage if you also have broken documentation; under these circumstances I probably would have had to give up with Microsoft. But anybody who thinks it should be this difficult needs his head read.
| 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 ?
yummain.main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 51, in main
base.getOptionsConfig(args)
File "/usr/share/yum-cli/cli.py", line 133, in getOptionsConfig
self.conf = yumconf(configfile = yumconffile, root=root)
File "/usr/lib/python2.3/site-packages/yum/config.py", line 227, in __init__
self._doFileRepo(fn)
File "/usr/lib/python2.3/site-packages/yum/config.py", line 299, in _doFileRepo
doRepoSection(self, repoconf, section)
File "/usr/lib/python2.3/site-packages/yum/config.py", line 313, in doRepoSection
mirrorurls = getMirrorList(mirrorlist)
File "/usr/lib/python2.3/site-packages/yum/config.py", line 390, in getMirrorList
fo = urlresolver.urlopen(url)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 427, in urlopen
return default_grabber.urlopen(url, **kwargs)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 555, in urlopen
return self._retry(opts, retryfunc, url)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 527, in _retry
return apply(func, (opts,) + args, {})
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 554, in retryfunc
return URLGrabberFileObject(url, filename=None, opts=opts)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 703, in __init__
self._do_open()
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 747, in _do_open
fo, hdr = self._make_request(req, opener)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 823, in _make_request
fo = opener.open(req)
File "/usr/lib/python2.3/urllib2.py", line 326, in open
'_open', req)
File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain
result = func(*args)
File "/usr/lib/python2.3/urllib2.py", line 491, in <lambda>
lambda r, proxy=url, type=type, meth=self.proxy_open: \
File "/usr/lib/python2.3/urllib2.py", 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:
gpgcheck=1
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 vlcSetting 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: a52dec-0.7.4-7.1.fc3.fr.i386.rpm: 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 = 1.0-0.11.pre5.1.fc2.fr was already added, replacing with li
bpostproc <= 1.0-0.12.20041025.1.fc3.fr
warning: package vcdimager = 0.7.20-1.1.vlc was already added, replacing with vcdimager <= 0.7.20-3
error: Failed dependencies:
libcdio.so.0 is needed by cdinfo-0.71-0.i386
libiso9660.so.2 is needed by cdinfo-0.71-0.i386
libcdio.so.0 is needed by libvcd-0.7.20-3.i386
libcdio.so.0(CDIO_0) is needed by libvcd-0.7.20-3.i386
libiso9660.so.2 is needed by libvcd-0.7.20-3.i386
libiso9660.so.2(ISO9660_2) is needed by libvcd-0.7.20-3.i386
libcdio.so.0 is needed by vcdimager-0.7.20-3.i386
libcdio.so.0(CDIO_0) is needed by vcdimager-0.7.20-3.i386
libiso9660.so.2 is needed by vcdimager-0.7.20-3.i386
libiso9660.so.2(ISO9660_2) is needed by vcdimager-0.7.20-3.i386
libcdio.so.0 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386
libcdio.so.0(CDIO_0) is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386
libiso9660.so.0 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386
libiso9660.so.0(ISO9660_0) is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386
fribidi is needed by vlc-0.8.1-1.i386
libfribidi.so.0 is needed by vlc-0.8.1-1.i386
libsysfs.so.1 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 Rpmfind.net 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.rpmwarning: 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/*rcewarning: vlc/a52dec-0.7.4-7.1.fc3.fr.i386.rpm: 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 = 1.0-0.11.pre5.1.fc2.fr was already added, replacing with li bpostproc <= 1.0-0.12.20041025.1.fc3.fr warning: package vcdimager = 0.7.20-1.1.vlc was already added, replacing with vcdimager <= 0.7.20-3 error: Failed dependencies: libcdio.so.0 is needed by cdinfo-0.71-0.i386 (etc)=== root@eucla (/dev/pts/6) /src/Linux/tarballs 16 -> rpm -U libcdio-0.70-1.i686.rpmwarning: 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.rpmpackage 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 <appro@fy.chalmers.se>, 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://1MPlayer 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 InterlaceThat 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:
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 192.109.197.1 AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 7 rejected from IP 192.109.197.145 AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 6 rejected from IP 192.109.197.134
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 (http://www.lemis.com/grog/) 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
EndSection
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:
NAME
xawtvrc -- TV apps config file
SYNOPSIS
/etc/X11/xawtvrc
$HOME/.xawtv
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: [GIANT-LOCKED] 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 @@
</defaults>
</nav>
<device>
- <path>/dev/acd0c</path>
+ <path>/dev/acd0</path>
</device>
</dvd>
<audio>
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:
DVD-name: DVD_VIDEO 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-1.2.0.12
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-6.2.0.5
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:
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.
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):
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:
|
|||||||||||||||||||||||
In particular, the cooler for the second CPU has mounting issues with the AGP slot, so it's off-centre:
|
|||||||||||||||||||||||
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
request.
I had got half way through writing my request code when I read:
STANDARDS
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:
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 ftp://ftp.FreeBSD.org/ 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:
|
|||||||||||||||||||||||
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 |
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 |
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 |
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:
|
|||||||||||||||||||||||
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:
|
|||||||||||||||||||||||
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 |
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:
|
|||||||||||||||||||||||
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)).
Do you have a comment about something I have written? This is a diary, not a “blog”, and there is deliberately no provision for directly adding comments. It's also not a vehicle for third-party content. But I welcome feedback and try to reply to all messages I receive. See the diary overview for more details. If you do send me a message relating to something I have written, please indicate whether you'd prefer me not to mention your name. Otherwise I'll assume that it's OK to do so.
| Top of page | Previous month | Greg's home page | Today's diary entry | Next month | Greg's photos | Copyright information |
