Category Archives: Uncategorized

Web Performance 3 – Common patterns that will slow down your scripts

Post series for my current employer DemoUp concerning web performance. This part explains why some commonly used patterns for script loading should be avoided.

Quelle: Web Performance 3 – Common patterns that will slow down your scripts

Advertisements

Running Kodak Scanmate i940 with Linux

I just want to share some insights about using the Scanmate i940 scanner using a linux distribution.  Kodak is claiming Linux support for that scanner and is providing a driver here.On its website Kodak states that specifically Ubuntu 12.04 LTS is supported. But this is only partially true. Here is what I found out about this driver:

  • The drivers is x86 32-bit only! This is a major drawback. You can run the scanner with a 64-bit system, but you have to install sane and all applications which are supposed to access the scanner in 32-bit. There is not much hope of being able to run the scanner using an ARM based Raspberry Pi too.
  • The driver actually contains a setup script, which supports far more than just Ubuntu. Judging from the code It is able to handle Debian, Ubuntu, Fedora (and RedHat-Clones) and OpenSuse out of the box
  • BUT it requires the existence of a libudev.so.0 and aborts when it cannot be installed. This causes the setup script to break on ALL RECENT linux distributions. The livudev.so.0 has been phased out for libudev.so.1 from Ubuntu 13.04 and Fedora 18 upwards

So far, so bad. The linux driver is outdated. At last judging from the look of the windows installer, this is true for the windows driver too (still, that one works).

I managed to get the scanner running with Fedora 20 64-bit. This are the steps which resulted in success.

  • Install a libudev.so.0 in the system. I forced in a package from a previous Fedora version. A similar step should work on other operating systems too.
  • Modify the setup script in a way that it does not break because of a missing libudev.so.0 and does not try to install it. Make sure it runs through.
  • Make sure the sane binaries and all applications which should be able to see the scanner are installed in 32-bit and have dependencies fullfilled

After that the scanner worked for me. I tested it under Windows too and the image quality looks like the same. So at least no drawback here. But I see another bigger bug with the linux driver: full duplex scanning does not work. The scanner is able to scan both sides of a page – but that does not work with linux driver. Duplex scanning works only in xsane, but not in more user-friendly apps like simple-scan.

I contacted the Kodak support about the problems of their linux driver. On the positive side they were quick to respond and supportive. A updated linux driver for Ubuntu 14.04 is in the works but there is not date when it can be expected.

As long as there is no updated driver available (I update this article as soon as I get it), I cannot recommend buying this scanner if you want to run it with linux. Not as long as you are not comfortable with the steps outlined above to make it work.

 

Update 25.1.2015:

I just found the updated driver 3.1 for the kodak i940 on the kodak webpage. It says it supports Ubuntu 14.04 and there is a 64-bit driver. So this driver finally comes out of the stoneage.

I was able to run the setup script on Fedora 21 flawlessly. The scanner now finally is able to scan several pages in one run. Unfortunatly the full-duplex scanning is still only working in xsane where you can choose the (driver specific) mode for that.

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 things down. The faster access thanks to the ramdisk does 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 cases 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.