Tuesday, March 20, 2007

Writing to video memory

Jay and I were having a discussion about directly writing to video memory. Being the adventurous type I ordained to try it. The device I had to use to accomplish anything was /dev/fb0current. The first picture is simply /dev/mem > /dev/fb0current. The second one is from writing the video memory to a file and then rewriting it back after moving around windows...it pretty much restored the state it was in including the AIM conversation. The third one is of something weird I found...I loaded a picture during one of these runs and found that it was permanently screwed up...even after restoring everything(By going to a VT and back to X), and refreshing the image it stayed the same, no clue why. The last one was simply switching to a vt and issuing sleep 3; cat /dev/urandom > /dev/fb0current; DISPLAY="0:0" ksnapshot and then switching to X(Rather bland but I put up anyway). All this was done in a Knoppix live CD. As always click pictures for higher res photos:






Edit: Jay pointed out to me that the last picture is gigantic(~2MB) compared to the other files (~0.2MB). This is due to the fact that since the data is random there is no way to compress it down, so every single pixel has to be accounted for.

Tuesday, March 06, 2007

XMMS in Gentoo

The Gentoo maintainers in media-snd decided to hard mask *everything*(Including plugins etc) for XMMS recently. Well, since I like XMMS and it's the only thing that handles the plugins I like, I spent a little while getting it working. I didn't really want to do make install just to keep it from screwing with anything, but for now this works just fine:

1) Go here and download both gtk1.2.10 and glib.1.2.10 tarballs
2) Untar the packages and cd into the new glib directory
3) run ./configure for glib
4) Fire up your favorite text editor(vi of course ;) and open up gstrfuncs.c
5) Find every instance of g_warning and add a comma(,) after every instance of G_GNUC_PRETTY_FUNCTION
....so for example you will have: g_warning (G_GNUC_PRETTY_FUNCTION ,
6) There should be 4 of these in total
7) Now run make, and if that goes well make install
8) Now set your LD_LIBRARY_PATH to /usr/local/lib
....LD_LIBRARY_PATH="/usr/local/lib"
9) Now run the ldconfig command
10) Go out of the glib directory and over to the gtk directory
12) Run ./configure for gtk
13) Now do a make, and make install
14) Finally grab the xmms tarball here
15) Untar it and cd into the directory
16) Run ./configure
17) Open up your editor and goto General/ir/ir.h
18) Comment out the lines for extern of pthread_t and gboolean(Line 52 and 53 in my version)
....//extern pthread_t irapp_thread
....//extern gboolean keepGoing
19) And finally run make and make install

For me none of these steps were superfluous, even the final make install. Eventually I want to make a tarball for my own future use that will take care of this automatically as well as do something like isolating these(gtk1.2, glib1.2, xmms) to their own space in opt automatically(Which IMO seems like what the Gentoo maintainers should have done).

Saturday, March 03, 2007

Travel Bunny Cage

I made it a long time ago but keep forgetting to post the details.
First the materials used were:
  • a cheap piece of 2'x2' plywood for the base
  • rabbit fencing for gardens
  • pre-cut boards for the runners(Which was a mistake)
  • Carpeting
  • Wood staples
  • Wood screws
I had my wife stain and paint the runners as well as put in the carpeting. Originally tried to use carpet tacks but they kept coming out of the plywood too easily, ended up using a staple gun with wood staples which worked perfectly(You can't see them in their or anything, and pretty sturdy). Construction was simply drilling guide holes for the wood screws, I just made marking for the runners to baseboard, but should have made a jig, even though that went okay. One thing is that the plywood was only 3/4" thick so my slightly unstraight holes were a problem since they bowed the wood. I need to make a jig sometime just for doing straight down holes. I was thinking of maybe taking 3 boards attached to a block with a drill hole in it, the boards would stick up and act as a guide for the drill body, and to use it you could just keep it flush against the back and work it down through the hole. One good idea that came from this was attaching the fencing to the baseboard with staples first and then sandwiching it with the runner using woodscrews. It makes it seem very solid and I can't imagine the fencing coming off, even though the baseboard is crap wood. Another problem was the pre-cut boards, they aren't precise and left a small gap...I now own a decent hand saw(For $7) that I use which would have been perfect. The door isn't attached since when it's not in use as a travel cage we cover it with an old yoga mat so it provides a hiding spot and a place to climb. I will probably attach the door with just some cable ties and maybe 'lock' it with velcro(Since during travel my rabbit doesn't attempt escape), so I can take off the door easy later on.

The pics, although not the best since they were taken as an afterthought:

Thursday, March 01, 2007

Filesystem Speeds

Overview

This was a precursor to my Encrypted Filesystem Tests, to check the effects of filesystem operations on CPU. After reading a couple of very good articles here and here(Which seem to conclude to use either JFS or XFS). I decided to do my own benchmarking specifically geared towards CPU utilization. While not terribly rigorous it did seem to pretty much follow their findings. The results below are from an average of 3 runs per each type of test. Also I didn't try Reiser4 but instead included FAT ;)

Results

Copying between drives:
..ext2 = 16s
..ext3 = 11s
..jfs = 14s
..xfs = 8s
..fat = 18.2s
..reiser = 8.5s
..Winner = xfs

CPU usage after the copying:
..ext2 = 1m 23s
..ext3 = 1m 27s
..jfs = 1m 13s
..xfs = 1m 24s
..fat = 1m 19.5s
..reiser = 1m 29.6s
..Winner = jfs

Copying a file to same drive:
..ext2 = 12s
..ext3 = 13.5s
..jfs = 20.6s
..xfs = 11s
..fat = 18s
..reiser = 2.5s
..Winner = reiser

Removing data
..ext2 = 0.21s
..ext3 = 0.20s
..jfs = 0.19s
..xfs = 0.22s
..fat = 0.57s
..reiser = 1.78
..Winner = jfs

CpuProg time during copying:
..ext2 = 1m 36s
..ext3 = 1m 37s
..jfs = 1m 25s
..xfs = 1m 30s
..fat = 1m 37s
..reiser = 1m 36.5s
..Winner = jfs

Copy time with CpuProg running:
..ext2 = 16.5s
..ext3 = 15s
..jfs = 17.87s
..xfs = 16s
..fat = 19s
..reiser = 12.1s
..Winner = xfs/reiser

Total to run benchmark tests:
..ext2 = 5m 5.5s
..ext3 = 5m 7s
..jfs = 4m 49.5s
..xfs = 4m 44s
..fat = 5m 11.5s
..reiser = 4m 55.5s
..Winner = xfs

Notes

The program to run the cpu just made a huge 2D array and copied back and forth. Alone without any disk activity before or during it took almost exactly 1m 4s each run. Also it may seem odd to check the CPU reduction after the copying was complete, but in practice this always seems to be where the most activity occurs(Probably due to buffered IO delaying the actual work). Another weird thing was removing files(Which granted was too small a set), that most had times under a tenth second consistently(And an outlier), except for FAT which always had times over half a second. In conclusion I think I'm going to use xfs, although it's a little worse on CPU than jfs it does seem to noticably copy faster. Also FAT was worse in about every aspect compared to any other system, couple that with external fragmentation and I can't imagine using it for anything but compatibility reasons.

Reiser

ReiserFS deserves it's own section due to it's bizarre nature. All the others were very consistent between runs with usually around a second difference in results, but Reiser was completely random, sometimes a copy would take half a second, other times 30 seconds...I could find no rhyme or reason to why(i.e. not the first time was slow and the rest faster or any pattern). Overall though it was usually slower than most of the others. Especially on removing things it was incredibly slow compared to even FAT. Also the copy time with cpuProg running I put xfs/reiser because reiser was much slower usually but always had a couple ridiculously fast runs(Fractions of a second) that made the average low.