Re: Missing feature
Good news. I contacted Marc Trevisan and he was willing to update his script to the new dbus methods, even that he doesn't use shr anymore. i'm thankfull for his effort and his newest version is available at [1]. So i think i can try the script again at the weekend. :) Ciao, Rainer [1] http://dev.3v1n0.net/gitweb/shr-notifier.git ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
SAMSUNG - possible project - help needed
Hello list Some of you know me perhaps as leviathan. I'm mailing to this list in behalf of my company to inform you, that we plan to offer a project to Samsung, which would also involve all kind of developers. The idea is to pilot a new Openmoko like platform, based on SAMSUNG-Omnia. The plan is to provide full hardware support by the upstream kernel, and a full SHR-userspace on the shipped phone. The target customers will be business employees, but also private users. So we need a realistic business model and also a realistic design. My company is willed to invest some money into the project. But for successing we will need the cooperation of engineers, who has already worked on OpenMoko and who are familiar with common problems in this area. In order to accomplish this, we would need some informations and your precious knowledge acquired during the Openmoko project What is your suggestion for this feature list? Components proposition would be very nice. You can interprete this propositions as realistic wishlist, I will put into a block diagramm, which will be shown in a presentation around next week. I hope they will buy the idea, and give feedback soon. If everything goes well, selected developers (people I know, they will really do development) will recieve prototypes for starting writing the drivers and modify'n the userspace. Here are the required hardware features: - GPS - GSM, EDGE, GPRS, UMTS, HSDPA - RAM - CPU - SD-card - Touchscreen - Wifi - Bluetooth [* I'm not using it, but its requested ;-)] And the required software features: - Exchange synchronisation * - Outlook synchronisation * - Handy Calendar I know, that you will ask, why they should start developing on another platform while they're already working on BADA and Linux/EFL. The answer is simple: Contacts. And this email is just for preparation for a presentation on a meeting with some important managers, who's names I'm not allowed to tell on a public mailing list. (Privacy) In fact there is not guaranty yet, that they will buy the project. with the best regards David Lanzendöfer (aka. leviathan) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: sd performance tests, bonnie++ with different filesystems.
It's good to see someone doing tests on this, but more info is needed on what fs creation and mount options were applied by default. These can have a major effect on the results. Of particular interest would be whether btrfs used the ssd option by default, and how the compress option would affect the results - does the cpu overhead of compression outweigh the reduction of bus traffic between cpu and glamo? On Thursday 24 June 2010, Gennady Kupava wrote: > Hi, list. > > Unexpectedly, seems it's time for me to repartition my sd card. > > So i decided to find which filesystem is best for current kernels, and > to share my results as this topic should be interesting to everyone who > is using sd card as storage for data. > > The participants - btrfs nilfs2 ext2 ext3 ext4 reiserfs jfs xfs. > > The old well-know test is bonnie++. > > Resulting html table, with 2 runs: > http://www.bsdmn.com/openmoko/fstest/fstestresults.html > > The test script: > http://www.bsdmn.com/openmoko/fstest/fsbench.sh > > Results are really hard to interpret, all filesystems has weak and > strong sides, but i'll try to do some summary now, for whoose who is > interested. > > 1. sequental io, this is quite rare now, so not really matter. > 1.1 sequental output per char > reiser, btrfs is non-usable in this respect. ext3 is close to unusable, > xfs is almost ok. all others same. > 1.2. sequental input per char > all almost the same - latency +-25%, expect btrfs, which is 30% slower > and have extraoridinary latencies. xfs is not good at speed too. > > 2. block io, most important thing. > 2.1 8k blocks write > here is most surprise - ext4 and ext2 are slowest. almost 50% slower > than xfs, jfs. ext3 have outstandingly bad latency. > 2.2 most important thing for fs - block read. > they all the same, except btrfs, which is much slower. > 2.3. rewrite > all almost same, expect btrfs and ext3. > > 3. random seeks. > it's seek+read or write. useful operation. only test where btrfs is > relatively good in performance. > > 4. create/delete tests > 1. Create (random) > great difference here, ext2, ext4, xfs, are bad. ext3, btrfs, reiser > 5-10 times better. > 2. delete (random) > ext2,ext3,ext4,reiser,btrfs are good, jfs and xfs 10 times slower. > > my conclusion here is that good filesystems: > ext2 and ext4 have same performance in this test. > reiserfs is best, despite of name of it's creator. > ext2 is good except file creation and remove. > xfs is good except file creation and remove. > ext3 is good _for_ file creation and remove. > > so, my choise of fs will be: > /boot -> ext2 for compatibility > /, /usr -> xfs, need fast block r/w. > /home -> reiser, need fast file create/remove, and overall balance > /var -> reiser, 'append fs', need good overall balance. > > i wanted to test nilfs2 (and use it for /var), but it didn't pass > testing - out of free space. > > All tests were done on .34, yesterday git (with FIFO LCM patch). Short > tests algorithm: for each fs: create fs on same mmc partition, mount > (with noatime) and run bonnie in mounted directory, then umount. I did > two runs to ensure results are sane. > > plain dd read speed of my sd card is 2.7Mb/s. > > Gennady. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
sd performance tests, bonnie++ with different filesystems.
Hi, list. Unexpectedly, seems it's time for me to repartition my sd card. So i decided to find which filesystem is best for current kernels, and to share my results as this topic should be interesting to everyone who is using sd card as storage for data. The participants - btrfs nilfs2 ext2 ext3 ext4 reiserfs jfs xfs. The old well-know test is bonnie++. Resulting html table, with 2 runs: http://www.bsdmn.com/openmoko/fstest/fstestresults.html The test script: http://www.bsdmn.com/openmoko/fstest/fsbench.sh Results are really hard to interpret, all filesystems has weak and strong sides, but i'll try to do some summary now, for whoose who is interested. 1. sequental io, this is quite rare now, so not really matter. 1.1 sequental output per char reiser, btrfs is non-usable in this respect. ext3 is close to unusable, xfs is almost ok. all others same. 1.2. sequental input per char all almost the same - latency +-25%, expect btrfs, which is 30% slower and have extraoridinary latencies. xfs is not good at speed too. 2. block io, most important thing. 2.1 8k blocks write here is most surprise - ext4 and ext2 are slowest. almost 50% slower than xfs, jfs. ext3 have outstandingly bad latency. 2.2 most important thing for fs - block read. they all the same, except btrfs, which is much slower. 2.3. rewrite all almost same, expect btrfs and ext3. 3. random seeks. it's seek+read or write. useful operation. only test where btrfs is relatively good in performance. 4. create/delete tests 1. Create (random) great difference here, ext2, ext4, xfs, are bad. ext3, btrfs, reiser 5-10 times better. 2. delete (random) ext2,ext3,ext4,reiser,btrfs are good, jfs and xfs 10 times slower. my conclusion here is that good filesystems: ext2 and ext4 have same performance in this test. reiserfs is best, despite of name of it's creator. ext2 is good except file creation and remove. xfs is good except file creation and remove. ext3 is good _for_ file creation and remove. so, my choise of fs will be: /boot -> ext2 for compatibility /, /usr -> xfs, need fast block r/w. /home -> reiser, need fast file create/remove, and overall balance /var -> reiser, 'append fs', need good overall balance. i wanted to test nilfs2 (and use it for /var), but it didn't pass testing - out of free space. All tests were done on .34, yesterday git (with FIFO LCM patch). Short tests algorithm: for each fs: create fs on same mmc partition, mount (with noatime) and run bonnie in mounted directory, then umount. I did two runs to ensure results are sane. plain dd read speed of my sd card is 2.7Mb/s. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
