Druckbare Version
Die Entwicklung ist derzeit aufgrund fehlender Zeit gestoppt, wer will kann sich den Sourcecode herunterladen und weitermachen ... :-)
Da ich mitbekommen habe, dass einige hier im Forum am Testen meines Benchmark-Apps sind, würde ich gerne euer Feedback in diesem Thema bündeln. Genauere Infos und den aktuellen Download findet ihr hier:
http://forum.xda-developers.com/showthread.php?t=850454
Vielen Dank fürs Testen und für das Feedback!
aha, Du bist das ;-)
Was heisst Minuszahlen?
Also die Minuszahlen errechnen sich dadurch, dass die Schreibgeschwindigkeit für 1M große Files kleiner ist als für 10k Files. Das komische ist, dass normalerweise 1M Files, umgerechnet auf die Größe, deutlich schneller geschrieben werden sollten als 10k Files.
Irgendwas passt da beim Schreiben der 1M Files nicht, die restlichen Geschwindigkeiten passen soweit alle. Leider kann ich das momentan bei mir nicht nachstellen. Ich hatte aber heute den Effekt, dass die Benchmarkwerte im Keller waren, Schuld war aber ein Hintergrundprozess, der das ganze Ding lahmgelegt hatte. Nach Neustart waren die Werte wieder normal.
Das hab ich auch, 3x durchlaufen lassen, 3 verschieden Ergebnisse.
denk ich mir auch, so wie bei den meisten benchmarks weichen hier die ergebnisse ab
Dass die Ergebnisse schwanken liegt quasi in der Natur der Sache - Multitasking hat nicht nur Vorteile :-)
Aber zumindest bei mir liegen die "guten" Ergebnisse relativ nahe beieinander und sollten einen guten Eindruck des "möglichen" Speeds geben. Ist das bei euch ähnlich?
Aber was ich sehr verdächtig finde ist die langsame Schreibgeschwindigkeit bei 1M Files. Ist diese reproduzierbar immer bei so niedrigen Werten? Werde probieren etwas mehr Details in das Logfile zu schreiben und eine Debug-Version rausbringen sobald ich dazu komme.
Auf xda hat gerade einer geschrieben, dass ein homescreen widget für die langsame Schreibgeschwindigkeit verantwortlich war. Könnte das sein?
Kommt doch auch drauf an, welches Dateisystem man nutzt?!
ext4 liesst schneller, ext2 schreibt schneller (und JFS).
Verlässliche Daten bekommt man nie, solange jeder eine andere Konfiguration hat.
Allein wenn ein einzelnes Widget es schon so beeinflussen kann.
Edit:
in Systempanel, wenn man sich die Systemprozesse auch Anzeigen lässt, sehe ich bei mir z.B. oft den Media Prozess am Rödeln und der genehmigt sich allerhand an Ressourcen.
Hab aber leider keine Ahnung, warum er das nur ab und an mal macht.
Klar - die Werte sollten vom Dateisystem abhängen. Aber wenn 2 das gleiche fs haben sollten sie auch ca. Die selben werte erreichen. Aber falls einer von euch die gleiche Beobachtung macht, dass ein laufendes widget den test negativ beeinflusst, bitte posten. Dann kann ich das in kommende faqs aufnehmen.Zitat:
Zitat von spline
Wobei was ich bis jetzt gesehen habe liegen ext2 und ext4oj ungefähr gleichauf. Hat einer von euch ext2 mit journal oder jfs? Wenn ja wäre cool wenn ihr eure detailwerte hier posten könntet dann kann ich sie zum vergleich ins programm aufnehmen. Auch wenn einer noch stock rfs hat wäre ich dankbar. Oder überhaupt werte von anderen handys :-)
ext2 mit Journal? gibts das?
Hier mal meine Werte mit dem speedmod K10i Kernel ohne Lagfix (alles RFS)
20101207T091335
Stresstest on /data (6 iterations)
StressWrite: 2275(1319) kB/s
StressRead: 10025(5941) kB/s
20101207T091335
Benchmark on /data (6 iterations)
DB writes: 11(1) Writes/s
DB reads: 107(13) Reads/s
DB deletes: 150(2) Deletes/s
File writes 10k: 199(20) kB/s
File writes 1M: 2745(662) kB/s
File reads 10k: 1558(600) kB/s
File reads 1M: 10526(646) kB/s
File write overhead: 46.441(5.054) ms
File read overhead: 5.467(2.471) ms
______________________________________________________
Im Vergleich dazu K10h Kernel mit ext4 ohne Journal auf /data
20101206T183750
Stresstest on /data (6 iterations)
StressWrite: 1178(918 ) kB/s
StressRead: 10214(5899) kB/s
20101206T183750
Benchmark on /data (6 iterations)
DB writes: 30(1) Writes/s
DB reads: 282(35) Reads/s
DB deletes: 316(7) Deletes/s
File writes 10k: 279(89) kB/s
File writes 1M: 830(94) kB/s
File reads 10k: 5532(224) kB/s
File reads 1M: 10649(756) kB/s
File write overhead: 23.691(11.456) ms
File read overhead: 0.869(0.099) ms
_______________________________________________
Edit:
in einigen Punkten wie z.B. bei den 1M Files scheint RFS besser zu sein. Oder liegts am Benchmark?
LOL ich glaub das war ein freud'scher :-) EXT4 mit Journal war natürlich gemeint!Zitat:
Zitat von spline
übrigens komm ich RFS grad mal auf 1733 Punkte
Hmm, sind die Benchmarkdaten bei ext4 reproduzierbar d.h. bei mehrmaliger Wiederholung ungefähr gleich?Zitat:
Zitat von spline
Der Benchmark an sich ist relativ simpel: Er notiert sich die aktuelle Zeit, schreibt Daten und rechnet sich dann aus der Differenzzeit und der Anzahl der geschriebenen Files die Geschwindigkeit aus. EXT4 sollte aber auf jeden Fall schneller sein.
Meine ergebnisse mim k10h kernel, 3x ext4nj und ext2 loops alle tweaks außer cifs support:
Details of Performance on /data
Iterations: 4 - Single Test Duration: 1000
Timestamp: 20101207T104317 - 530
Overall Performance: 3474(809)
Database Performance: 546(8)
FileRead/Write Performance: 2149(210)
StressTest Performance: 779(781)
DB writes: 233(9) Writes/s
DB reads: 280(5) Reads/s
DB deletes: 307(8) Deletes/s
File writes 10k: 3436(716) kB/s
File writes 1M: 10159(3952) kB/s
File reads 10k: 5843(25) kB/s
File reads 1M: 14271(29) kB/s
File write Overhead: 1.925(0.717) ms
File read overhead: 1.01(0.007) ms
StressWrite: 7322(10358) kB/s
StressRead: 8274(11702) kB/s
Sent from my GT-I9000 using Tapatalk
Schau Dir mal das an:
Test mit Speedmod K10 Kernel und /data ist auf ext2 (ohne loop)
Ich finde, je kleiner die DB writes sind, je höher ist hinterher die File read und writes
Test1:
20101207T134703
Stresstest on /data (6 iterations)
StressWrite: 7936(4808) kB/s
StressRead: 10443(6116) kB/s
20101207T134703
Benchmark on /data (6 iterations)
DB writes: 2(4) Writes/s
DB reads: 156(83) Reads/s
DB deletes: 125(14) Deletes/s
File writes 10k: 2533(527) kB/s
File writes 1M: 9661(1315) kB/s
File reads 10k: 5460(872) kB/s
File reads 1M: 11976(185) kB/s
File write overhead: 2.913(0.834) ms
File read overhead: 0.996(0.293) ms
Test2:
20101207T134743
Stresstest on /data (6 iterations)
StressWrite: 3205(2842) kB/s
StressRead: 11042(6376) kB/s
20101207T134743
Benchmark on /data (6 iterations)
DB writes: 23(7) Writes/s
DB reads: 298(11) Reads/s
DB deletes: 311(4) Deletes/s
File writes 10k: 1818(840) kB/s
File writes 1M: 3043(943) kB/s
File reads 10k: 542(22) kB/s
File reads 1M: 9764(3478) kB/s
File write overhead: 2.215(2.739) ms
File read overhead: 17.402(0.839) ms
Anbei hab ich Dir mal das Logfile mit ext2, ext4 und rfs Test
(habs grafisch ein wenig hervorgehoben)
@spline: sicher, dass keine backgroundprozesse stören oder apps oder widgets? EXT2 sollte deutlich bessere Werte liefern?
So, hab mal wieder zu RFS gewechselt und 2x eine dreiertestreihe mit verschiedenen schedulern (über OCLF eingestellt) gemacht:
RFS deadline scheduler:
DB writes: 15(0) 15(1) 15(1)
DB reads: 150(13) 150(9) 127(13)
DB deletes: 160(1) 157(5) 157(5)
File writes 10k: 285(17) 300(10) 285(23)
File writes 1M: 2308(138 ) 1864(141) 1986(298 )
File reads 10k: 3259(1572) 2751(1755) 3265(1290)
File reads 1M: 10505(85) 10938(179) 10958(171)
StressWrite: 1899(1118 ) 1826(1080) 1915(1137)
StressRead: 8776(5070) 8948(5167) 9577(5545)
StressWrite 10k: 95(19) 80(20) 94(18 )
StressRead 10k: 411(189) 538(328 ) 480(220)
Database overall: 218(8 ) 215(6) 200(9)
File overall: 995(157) 945(175) 1002(130)
Stress overall: 394(177) 424(214) 431(196)
Overall: 1607 1584 1633
RFS CFQ scheduler:
DB writes: 12(1) 13(0) 13(1)
DB reads: 148(13) 138(11) 124(29)
DB deletes: 156(6) 157(3) 154(15)
File writes 10k: 187(40) 298(10) 285(2)
File writes 1M: 2382(105) 1929(150) 1810(129)
File reads 10k: 2522(1077) 1818(1505) 2417(1675)
File reads 1M: 11251(41) 10596(84) 11034(278 )
StressWrite: 1922(1119) 2004(1172) 2398(1438 )
StressRead: 9563(5542) 8938(5203) 9060(5241)
StressWrite 10k: 94(17) 83(28 ) 89(15)
StressRead 10k: 539(263) 392(194) 1039(558 )
Database overall: 211(9) 206(7) 194(21)
File overall: 952(107) 837(150) 912(168 )
Stress overall: 446(207) 389(245) 569(275)
Overall: 1609 1432 1675
Die Werte fluktuieren nicht so stark würde ich sagen.
Ich hab ständig irgendwelche Background Prozesse :-(
Also die Prozesse die er mir anzeigt sind:Zitat:
Zitat von spline
mClock (von meiner Uhr)
Device Management
DRM-geschützter Content-Speicher
Google-Services-Framework
SNS
Smart Keyboard Pro (meine Tastatur)
Das wars, Google sync is aus, email sync wart ich bis er vorbei is (mit k9).
ach da hab ich einiges mehr.
Ich weiss nicht, ob die Dinger, die sich einen Platz als Service genehmigen auch Speicher fressen oder nur den Anspruch darauf erheben?!
z.B. Mortplayer
Speicher fressen ist glaube ich egal, sollte ja genug da sein :-) Aber falls die im Hintergrund was machen wie z.B Statistiken anlegen oder syncen oder so, das wäre nicht gut. Wenn was als Service rennt, ist es ja auch darauf ausgelegt. Ich würde einfach probieren alle services die nicht android-eigen sind mal zu stoppen und dann zu schauen ob sich an den benchmarkwerten was ändert.Zitat:
Zitat von spline
Neue Version online:
Changelog 0.8:
- Refined Stress test and details
- FAQ added
- Logfile can now be copied (Longpress)
- Logfile structure changed for better overview
Stresstest ist jetzt aussagekräftiger ...
Zum Vergleich mal meine werte mit rfs+ loopback ext2:
Details of Performance on /data
Iterations: 6 - Single Test Duration: 500
Timestamp: 20101208T094922
Overall Performance: 3828(125)
Database Performance: 559(30)
FileRead/Write Performance: 2243(44)
StressTest Performance: 1026(113)
DB writes: 228(21) Writes/s
DB reads: 293(32) Reads/s
DB deletes: 316(25) Deletes/s
File writes 10k: 5282(288) kB/s
File writes 1M: 10666(370) kB/s
File reads 10k: 5841(68) kB/s
File reads 1M: 11952(560) kB/s
File write Overhead: 0.956(0.108) ms
File read overhead: 0.875(0.044) ms
StressWrite 1M: 10600(407) kB/s
StressRead 1M: 11588(419) kB/s
StressWrite 10k: 831(225) kB/s
StressRead 10k: 1054(324) kB/s
Ich kann den 0.8 garnicht erst Starten. nur Vibrieren dann kommt Benchmark wurde unerwartet angehalten.
Schon vorher ne ältere version installiert gehabt? Dann am besten entweder anwendungsdaten löschen oder de- und neuinstallieren.Zitat:
Zitat von Jens0609
Du bist ja Genial Anwendungsdaten haben gereicht das war die Lösung vielen dank.Zitat:
Zitat von Peaceman
So dann auch hier mal meine Daten mit ext4 auf Data ohne Journal mit der 0.8 Version
:-) naja genial wärs wenns nicht passieren würde. Ich weiß zwar wo das Problem ist, aber ich hab noch nicht rausgefunden wie ichs lösen kann. Sollte aber für alle zukünftigen Updates kein problem mehr sein :-)Zitat:
Zitat von Jens0609
Ja gut ich sehe das jetzt nicht zwingend als Problem wenn man weiß wie man den Fehler behebt ist doch alles gut. Find es aber gut das du dir die Arbeit gemacht hast.
Wäre es möglich, den Benchmark z.B. 3x zu wiederholen und mir das LogFile zu schicken? Danke im voraus!Zitat:
Zitat von Jens0609
So das Log File nach 3 mal den Test durchlaufen lassen. Hoffe ist das was du wolltest.Zitat:
Zitat von Peaceman
Danke :-) man kann aber auch das ganze logfile per copypaste (lang klicken) kopieren ;-)
Das sagst mir jetzt.:DZitat:
Zitat von Peaceman
Für alle die Interesse haben, ich habe den Sourcecode des Benchmark im XDA-Forum gepostet, da ich derzeit nicht dazukomme das App weiterzuentwickeln. Knackpunkt ist, dass das Lesen/Schreiben von Android gut gepuffert wird und daher viel schneller erscheint, da müsste man eine NDK Routine verwenden um das abzustellen.