Fedora 20 on the Omnibook 4150B

I successfully upgraded this pre 2000 laptop to Fedora 20. Everything went smooth. You can hardly see a difference.

Still, the laptop is missing a usage because of its slowness. Even watching videos became hardly possible after some acceleration drivers for the old mach64 chipset had been removed from Xorg.

The situation will become worse when the drivers for old graphic chips will be purged completely in Fedora 21. From then on only VESA drivers will be available for showing a desktop.

If someone still wants to run a desktop on such an old machine, the current debian stable release is probably a much better choice.

Fedora 20 with Gnome 3.10 works again on the wetab

After having input problems in Fedora 19 (previous post) which made the Gnome desktop unuseable – I can now happily confirm that the problem is solved in Fedora 20. I can work with Gnome 3.10 as you expect it on the touchscreen.

The system is running quite slow nonetheless. This may be caused partially with the SSD slowing down during write access – but what can you do about that with an SSD without TRIM support?

Ramdisk/USB-Disk Raid-1 on a Raspberry Pi

I’m using tinyrss as an RSS reader software which is running on my raspberry pi. While its performance is acceptable I’m always wanting it to be a little snappier. Judging from watching top output the pi is most of the time busy with the

Made from a shoe box. Contains a pi, two usb disk, powered usb switch and a 1000 MBit/s ethernet switch.

My selfbuilt Pi-server rack. Made from a shoe box. Contains a pi, two usb disk, powered usb switch and a 1000 MBit/s ethernet switch.

mysql process. I already tried every hint in the web to make mysql faster. I switched from InnoDb to MyISAM (that helped) and tuned the buffers.

I suspected one of the reasons for the slowness the small usb disks on which the mysql databases are saved. That disks are not fast and using the slow USB 2.0 interface. So what would be a faster disk which would not be bottlenecked by the usb interface?

As even the PIs card reader is quite slow and even the ethernet adapter is connected internally via USB I can only think of one faster storage space: the RAM. A ramdisk would provide the fastest storage the pi can offer.

Why a Ramdisk/Disk RAID-1

According to this (german) Heise article it is possible to run a fast ssd in conjunction with a slow hdd in a RAID-1. Readings would be provided by the fast disk. The write speed is limited to the speed of the lower disk. This way you can save your money for just one SSD and use a cheap HDD as the backup disk. I already installed such a setup successfully on desktop pc.

My idea was to use a ramdisk as the fast disk and a slow partition on a usb stick as the slow write disk. The advantage of this setup would be that you have the speed of the RAM when reading data but still can be sure that your data is saved to mass storage on the usb partition. You do not have to worry about restarts and crashes, the ramdisk would be filled with the latest data from usb disk at each startup. Pretty nice. So lets try it out.

Building a Ramdisk/Disk RAID-1

As the PI does only have 512 MB of RAM there is not much room for a ramdisk. However, was my tinyrss database is only 70 MB in size and usually not more than 100 MB of RAM are used in the pi – there is some RAM left that can be used for experiments. I decided to spent 250 MB of RAM for the ramdisk.

The first thing you need is a ramdisk. You cannot use tmpfs as it does not provide a block device. Instead of that you have to use the /dev/ram* devices. By default they are only 4 MB in size. This must be changed by kernel boot parameter.

Add this option to the command line in /boot/cmdline.txt

ramdisk_size=256000

After reboot the ramdisks provide 250 MB of space.

Let’s check the speed of the ramdisk:

sudo hdparm -t /dev/ram0
/dev/ram0:
 Timing buffered disk reads: 250 MB in  2.35 seconds = 106.54 MB/sec

Well, a PC can do much more, but compared to the usb disk it is really fast.

sudo hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:  70 MB in  3.03 seconds =  23.12 MB/sec

Moreover in the ramdisk file access should be more or less instant what is even more important.

Now lets create the raid. I used a small partition on an usb stick as sda1.

sudo mdadm --create -n 2 --level=1 /dev/md0   /dev/ram0 --write-mostly /dev/sda1

And now lets check the read speed on the newly created raid:

sudo hdparm -t /dev/md0
/dev/md0:
 Timing buffered disk reads: 202 MB in  3.03 seconds =  66.73 MB/sec

Well, much faster than the usb partition alone!

Running mysql from ramdisk/usb raid-1

Afterwards you have to create file system on the raid device /dev/md0 and mount it. I copied the database files from my usb disk to the raid device and pointed the mysql data directory to there.

After restarting the mysql server I did some benchmarks whether tinyrss runs faster in this setup.

Interesting idea, but not faster

In the end the database running from the raid was a little bit slower than when running from the usb disk. So my experiment was a failure.

The mysql database is clearly CPU and not I/O bound. As the data access via raid requires more CPU power it is obvious that the raid slowed thinks down. The faster access thanks to the ramdisk that not matter.

For this case I gave up the idea of a ramdisk/disk raid-1 because it did not make anything faster. However, there might be other use cases which are not CPU bound. In that case this might be an idea worth to try out.

Having instant access to your data in RAM and having it written onto a harddisk at the same time might be interesting for some people out there.

Wetab with Fedora 19 and Gnome 3.8 – failure

As described in a previous entry I was quite satisfied with Fedora and Gnome 3.6. running on the wetab. The good impression ended after updating to Fedora 19.

It’s a simple and stupid problem. The Gnome 3.8 shell is simply not recognizing touches on the screen as clicks anymore. Tapping on buttons in the top bar does select them somehow, but does not open open them. That way the interface is unusable, especially as the virtual keyboard is affected by the same problem and is not putting out any key input.

Well, I found out that I can open the “activities” when I slide with the finger to top of the activities button. After that some interaction with the UI elements is possible. Even the virtual keyboard works. But this stops as soon as I leave the activities view and try to enter i.e. an address into the address bar of a browser. Again, the virtual keyboard does not recognize any taps what makes the system unusable.

You cannot even log out from Gnome 3 without attaching a mouse to the wetab.

After this failure I switched the Wetab to KDE. It’s not that optimized for touchscreen usage – but at last I can interact with it via the touchscreen. Sadly the auto-rotation of the screen does not work with KDE. But if you login via GDM you can at least rotate the screen in the correct direction before entering KDE.

Fedora 19 on hardware of the last century

Another six month have passed, so my good old laptop from pre-20IMG_220900 got another update.  I updated the already running fedora 18 to fedora 19 by using the fedUp tool.

The update took longer than on more recent systems (of course) but it worked flawlessly.

After that I booted into the LXDE desktop of Fedora 19. Everything worked as before. The machine is still too slow for most uages, even webbrowsing is painful. Work with libreOffice is probably doable.

Still, one big downside of modern linux distributions is that there is no video acceleration for this old graphic chipset anymore. So most videos can not be played. On the positive side, I was surprised to find that suspend to ram and suspend to disk both worked flawlessly on Fedora 19. Good work to remain compatible with APM (pre-ACPI)!

Ubuntu 13.04 and Fedora 18 on the Wetab

You might remember this tablet that came out from Germany in parallel with the iPad. It’s more or less a netbook with a touchscreen but without a keyboard. It hat some drawbacks, the worst in my opinion is the bad screen. You can switch the small SSD in it, but you cannot replace the screen. Bad. The device ended not being used anymore shortly after I bought a used one.

Anyway, I wanted to use the wetab as a (network) tv display wall-mounted in the kitchen. That’s why I started to throw a modern linux distribution on it. I always used the 64-bit images because they are known to run faster on the CPU (at the cost of slightly increased memory usage).

Ubuntu 13.04

In short: Ubuntu was not running on the wetab for me.

Long version: The install image is loading correctly from a usb stick. Everything looks good – unity is not a bad touch experience. The downside comes after you have installed Ubuntu on the wetab. The system does not get to a usable system. The desktop is visible (in a wrong resolution) but there is no reaction to input. Even if you connect a keyboard to the tablet, you cannot do anything. The keyboard is not initialized correctly.

I was not able to find out the source of the problem. Examining log files made clear that the Vesa graphics driver is loaded instead of the intel one. That’s wrong and explains the wrong resolution with which the desktop is started. However it does not explain why the tablet does not react to any input. Why Ubuntu works from usb but not when being installed remains a mystery.

I tested Ubuntu 12.04 too and it had exactly the same problem. So I don’t expect a fix for this any time soon.

Fedora 18

IMG_0441

I gave Fedora 18 a try afterwards. To my surprise it was fully functional out of the box. After installing it boots into a Gnome 3 desktop. I found Gnome 3 less attractive than unity in this touch usecase, but as far as I know Gnome 3 is the only touch friendly desktop in Fedora. I can live with it.

Fedora 18 and Gnome need some more finishing touches than Ubuntu. The default installation is not really lightweight. But you can turn of some programs and services after installation. If you do that, you can bring memory usage in the area around 300 MiB. The remaining RAM should be enough for watching video streams and some surfing.

My browser choice fell on Chrome. While the low memory available on the wetab (1 GiB) suggests using Firefox with its lower memory footprint, Chrome is able to use some acceleration for displaying webpages. As the wetab is not planned to do many things at the same time but is supposed to do one task as fast as possible, the choice was clear for me here. Chrome has a nice touch extension which really makes it fun to use.

The performance of gnome 3 on Fedora 18 on the wetab is acceptable. What impressed me most is that the screen is rotated automatically when you turn the tablet. This works out of the box.

All in all I find the wetab to be really good supported by Fedora 18, what is surprising after the big problems that showed up with Ubuntu.

Build your own 6 watts home server using an raspberry pi

IMG_1513 In the picture besides you see my new home server built around a raspberry pi. The parts in detail:

  • raspberry pi model b Rev.2 inside a transparent casing
  • D-Link DUB-H7 7-Port USB 2.0 Hub (confirmed working with the raspberry pi)
  • 2.5 inch 500 GB usb harddisk from toshiba (an older one I had)
  • Hauppauge Nova-T Stick for DVB-T (confirmed working with the raspberry pi IF you have a powered usb hub!)

The pi is connected to a fritzbox 7270 via ethernet and is running raspian (Debian Wheezy). The CPU is overclocked a little at 800 MHz.

Currently this small computer is running the following services for me:

  • full webserver consisting of nginx, php and mysql (follow standard tutorials for debian)
  • web rss reader using tiny rss 1.7.4
  • streaming tv from the tv stick to all computers in the network using vdr and streamdev-plugin
  • streaming requested music via the upnp protocol having installed minidlna as described here
  • common file storage via ssh/sftp
  • backup space via rsync

Memory usage is around 100 MiB all the time (no graphical is running). TinyRSS could be running a little snappier – I intend to help optimizing it a little. Streaming tv is putting 15% cpu usage on the pi.

The best about it is the low power usage. I measured it and even together with the power supply it never reached 8 watts. I see around 5 watts at idle. It may peak a little higher when there is full cpu and disk load – but that’s rare. So you can think of having it running all day without some bad.

I intend to add another usb disk acting as a backup by mirroring the data on the other disk.

Things to know about power usage

Power supply was the only big question I had when putting together the parts I needed. I wanted to keep costs and power losses low by running not adding more power supplys than absolutely needed.

The raspberry pi can be powered via an usb port. But it needs at least 700 mA what not every port provide. The usb port of the Fritzbox was no option because of that. If you want to connect more power hungry devices (like harddisks or tv sticks) via usb to the raspberry, you really need a powered usb hub because no usb port can power the pi AND that devices together. I wanted to run the pi, two harddisks and a tv stick altogether, so some power was needed.

Instead of buying a power supply for the pi and a powered usb hub (which would make two), I only bought the usb hub. The D-Link hub is specified to deliver 3.5 A, what should be enough. So I simply pluged the pi into the hub and connected the hub with the pi via one of its two usb ports again. This connection circle is working well and every device I plug in the hub can be used by the pi. This trick saved me one power supply and some power being burned.

A hint if you intend to run usb disks with that hub: Have Y-cables available (with two usb plugs). One port of the hub may not be enough to power the disk, but using two of them will suffice.

Update 30.5.2013

In the meantime I added a second USB harddrive to the setup which serves as a backup. Via cronjob the content of the first harddisk is transfered to the backup disk every night by rsync. That works perfectly.

Moreover I have a cronjob making a low level copy of the sd card containing the system image to the hard disk weekly. So I have a full backup of the system in case the sd card is failing.

Two problems I encountered. Mirroring my desktops home directory to the usb drives of the pi via rsync often crashes long before having finished. I do not know the reason but found rsync to be no backup solution for me. Maybe unison will work here.

Apart from that I sometimes find that my tv stream from the pi suddenly aborts and cannot be restored. It took me a while to find out that the problem is actually the fritzbox 7270 running FritzOS 5.50. After restarting it, everything works again. Must be a strange  bug in the fritzbox with data intensive socket connections. So if you are watching tv via your pi and the stream aborts, the problem might actually be your router.