[Desire Android Development] melethron:
Benchmarks

I did some sqlite benchmark to estimate performance of filesystems on /data/data writes. To make a "clean" benchmark i did the following before changing the filesystem:

- Full Wipe (+format the sd partition)

- fresh ROM install (avaritia HD v 0.2 of course)

- No setup of wifi and apn (so that no other writes happen from any sync)

- Wait 1 min after rosie loaded

- run 5 tap benchmarks in a row

The results (not completly finished but rest will come) are contrary to what i found before. The reason i had a smoother feeling on btrfs than on ext4 was that i switched to noop scheduler. The speed increase i noticed was due to the scheduler.

Part1: SCHEDULER

The first Benchmark is on EXT4 only and is only about scheduler. While i talked to people about scheduling there where 2 arguements against noop scheduler:

1. Noop means "NO OPereations" and means the scheduler doesn't do anything at all. No scheduling is BAD and reduces performance.

2. While "No-op" is definitly the best scheduler for sd-cards since there are 2-4 parallel channels which makes scheduling completly useless it is still a matter of the controller used. If the controller of the sd-card is "bad" it can't handle all the unsorted I/O requests.

About the argument 1:

Thís argument is absolutly true on a normal HDD (rotational) because of the seek times of the "actuator arm" to move the "head" and noop fails completly on stress test and is like 25 times slower than cfq. On the other side this argument is absolutly WRONG on any kind of flash based device. There is no actuator arm, no head and also NO seek time. Optimizing for seek time is thus complete nonsense. All scheduling does then is use CPU. (so much for the theory)

About argument 2:

This is a practical issue and can only be tested to see if the controller can handle the I/O. (since we have no information on controllers used in microSD all we can do is testing here.

Here are the Bench results for EXT4 (rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered)

1. Noop:

DB overall: 402,4

Stress overall: 915,4

2. CFQ:

Db overall:	397,4

Stress test:	909,2

These results AREN'T speeking for themselfs and have to be explained. The results are relativly even there doesn't seem to be a "real improvement" from "noop". But there is something this bench doesn't show: The "smoothness":

Ill make an example. You save something with an app (like clicking on superuser accept button) while another app is syncing in background and also writes to the database. The write request are the following:

App1: write to sector 301,302

App2: write to sector 101,102,103,104,105

The timeline of the I/O request in wich these request occur are these and this is also the the way the I/O request are sent to SD with NOOP:

101,102,103,301,104,302,105

The seek time on HDD would then be 103->301 , 301->104,104->302, 302->105

The scheduler will now sort this request most likely to this:

101,102,103,104,105,301,302

So the result in only one seek: 105->301

And this will GREATLY increase the time needed on random I/O request BUT ONLY ON A HDD (Check how much longer the NOOP scheduler needs for random reads/writes: http://www.linux-magazin.de/var/lin...bb4_jpg/18703-1-ger-DE/abb4_jpg_reference.jpg)

But again. I dont have a HDD in my phone but an SSD. What would this sorting mean: The results above mean that (OH WHAT A WONDER - i proved that an sd-card is no harddisk ^^) that there are no seek times. The random read/writes of the stress test have the same results. This means it

DOESNT MATTER IN ANY KIND

IF THE I/O is like this if you only consider the time needed:

101,102,103,104,105,301,302

or like this

101,102,103,301,104,302,105

Both need the same time (and cfq is even slightly slower bcs it needs cpu time to sort the requests). But as i said there is one thing you don't see in the bench values:

As you are the user who just clicked on the "superuser" accept button you need to WAIT for the write of sector 104,105 until the app even starts to write the data. And this results in ....

LAGS.

EDIT: Some might think now that they can interpret the results the other way around. If the user-app is the other app from the example. This would really apply to this example. But simply think of the number of processes that are running. If you doubt this posting test it yourself.

Part 2: with Benchmarks of the filesystems will follow.....

Attachment: "Raw" results from the "TAP benchmark" log.