Steve Dougherty’s Blog

It seems we now have five cats. I’m looking into options for filters so my heatsinks aren’t clogged with all the cat hair. It’s far easier to brush things off a filter than blow them out from between heatsink fins. I should also renew my efforts to get our machines off the ground so they act less like vacuums. I really don’t understand the thought that went on in this decision, and in some ways doubt it occurred.

In other news, Zombie 6 started making an alternating tone, and it was only when I installed a sensor kernel module that I discovered:

$ sensors

acpitz-virtual-0

Adapter: Virtual device

temp1: +60.5°C (crit = +65.0°C)

w83697hf-isa-0290

Adapter: ISA adapter

VCore: +1.74 V (min = +0.00 V, max = +0.00 V) ALARM

+3.3V: +1.52 V (min = +0.14 V, max = +2.05 V)

+5V: +4.78 V (min = +0.05 V, max = +1.72 V) ALARM

+12V: +12.16 V (min = +0.43 V, max = +0.49 V) ALARM

-12V: +2.11 V (min = -3.07 V, max = -13.59 V) ALARM

-5V: +0.33 V (min = -7.71 V, max = -7.71 V) ALARM

V5SB: +5.59 V (min = +0.22 V, max = +0.00 V) ALARM

VBat: +3.07 V (min = +0.00 V, max = +0.00 V) ALARM

fan1: 5192 RPM (min = 168750 RPM, div = 2) ALARM

fan2: 0 RPM (min = 8881 RPM, div = 2) ALARM

temp1: +33.0°C (high = +12.0°C, hyst = +16.0°C) ALARM sensor = thermistor

temp2: +60.5°C (high = +60.0°C, hyst = +55.0°C) ALARM sensor = thermistor

beep_enable:enabled

I really hope either the default rail voltage ranges are somehow wrong, that the CPU overheating was leading to strangeness, or that I’m misunderstanding something, because if those are the rails’ actual voltages, I’m surprised the machine was still running and not on fire. Ranges including 0 seem weird, I don’t know if it’s listing acceptable variance from the stated voltage, and if so it seems in some cases too wide a range for normal operation. It’s probably not seeing a rotation speed for fan 2 because if I recall correctly it’s running off molex. I should add some sort of temperature monitoring to my machines. I will probably have to reseat a heatsink in the near future. For now the machine is off and unplugged – it’s unplugged just in case the PSU is really that broken and the 5V rail might do something nasty.

When I went downstairs to check for water leaking into the basement during the storm last night, Zombie 1 was making weird noises. I powered it down and today found that it seemed that the PSU, not the optical drive or hard drive, was making the weird noises. This is a shame for many reasons. I don’t really need an optical drive in the thing, I have many spare 3.5″ IDE hard drives, and the PSU is a weird one that’s the wrong shape. Even if I bought a normal PSU and connected it from outside the case or something crazy like that, it would likely cost more than the machine cost me in the first place. At this point I’ve turned it back on and I guess we’ll just see how long it will last. This feels oddly sad.

EDIT: It is no longer making strange noises, at least for now.

It turns out to be rediculously easy. I plan to use it so that the backup machine can log into the server without a password, but not the other way around.

Behold! We made this during robotics. Click for the original. It’s somewhat messy, but still amusing.

Today I learned that the proper way to check system mail on a Linux box is not by moving or deleting files from /var/mail, but using the mail command. Imagine that! I had to read the man pages to figure out how to use it, which is to be expected for a command line utility. I’m also looking at rdiff-backup to see if I can use it for real, scheduled and incremental backups instead of the current full-backups-when-I-remember system. (Please don’t hurt me for admitting it! I’m not proud to say it!)

EDIT: Daily backups are now scheduled.

XFX sent me back a replacement for my PCI-E 7600 GT with 256MB RAM. I was delighted to find that the replacement was a 9500 GT with 512MB RAM!

Benchmarks – average of FPS of two runs unless otherwise stated:

Lost Coast Stress Test:

1280×1024 Recommended: 68.92

1280×1024 Maximum: 52.54 (three runs)

1024×768 Recommended: 66.83

1024×768 Recommended with color correction and vsync: 52.52

Counter-Strike Source Stress Test:

1280×1024 Recommended: 126.49

1280×1024 Maximum: 59.48 (three runs)

1024×768 Recommended: 126.40

I suppose I ran the max tests three times each because they were so very pretty. It’s weird that a lower resolution with vsync and color correction would run more slowly than a higher resolution set to that and more. In the past, every time I ran maxed tests, its reflections contained the easily recognized purple checkers of missing textures. When I went from maxed to recommended settings and the purple checkers persisted, I realized that the missing textures never had anything to do with the abilities of the machine, and were indeed missing textures. I restarted the game to reload the textures, although I think mat_reloadtextures might do the same thing faster. (Found here.)

It is interesting to note that dropping to 1024×768 doesn’t provide too much of a boost in framerate, if any. This may be because 1280×1024 is the native resolution of the LCD, so no scaling is needed. After running tests, the console had an error about bench_upload being a cheat command. I enabled cheats in the hope that it would successfully upload my benchmark statistics. I could probably run a packet sniffer to see if it’s actually uploading. In Counter-Strike:  Source, sv_cheats 1 made the benchmark’s movements accelerated: the camera moved faster, the blocks spun faster, the water flowed faster, the flames flickered frantically – and the overall framerate was lower.

Windows fell back to software rendering when first booting with the new card. When my card died, Linux fell back to open source drivers for the onboard. I installed ATI’s propritory drivers in the hope that they would make the thing slightly more useful. It seems although NVIDIA’s drivers stepped aside when their card was unaccessable, ATI’s did no such thing, reducing X to an unsettling and intermittently flickering blank screen. The uninstall script in /usr/share/fglrx was nowhere to be found, which was odd because I manually installed the drivers from ATI’s installation script. Removing xorg.conf had no effect as it seemed to still use fglrx. I had not installed the propritory drivers from the repos. I ended up starting in single user (aka recovery) mode, starting an ssh server, resuming the boot process with telinit 3, logging in from elsewhere to stop gdm, then installing NVIDIA’s driver and rebooting. It works quite well now. I was even informed of telinit 3 by the NVIDIA driver installer itself, which was very nice!

EDIT: I found the uninstall script in /usr/share/ati.

The site was down due to a power outage. I took the downtime as an opportunity to move the shelving the machines are on a foot or two away from the wall so I can get to the back of them. One of the zombies’ networking didn’t come up properly, even with a /etc/init.d/networking stop and restart, but upon reboot it worked correctly. I wish I knew the underlying cause of that.

I am delighted to discover that PBS’s Scientific American Frontiers has an online archive of shows.

This is an amazing Flash applet. You draw on a grid and it makes really nice music. Strangely enchanting… ToneMatrix!

Newer drivers have less bugs and better performance, right? Not in this case, at least if you’re running an AGP GeForce 6800XT like me. The device fails to properly start, the device manager complains, and falls back on very ugly software rendering. Installing previous drivers – in my case 178.24 – fixed the problem. I learned that EVE will not launch with software acceleration.

On my eMachine where I am currently using my onboard card, (sigh) the fitting screen in EVE took what felt like several seconds to finish the intro animation, but on my machine at mom’s, it takes a fraction of a second or so. I find it amazing just how bad onboard graphics card performance is.