Druckbare Version
Aber so liesse sich das für mich erklären.
Warum, wieso die Samsung Leute das gemacht haben weiss keiner.
Lahmen MovieNand für die Daten, lahmes RFS als Dateisystem, GPS das spinnt, Farbtemeratur des Displays zu kalt ...
Warum machen die das? Jeder halbwegs gscheite Linuxer (nicht ich), kann das besser, siehe Hardcore, supercurio, ryanza und die anderen.
Samsung ist doch einfach zu faul... Oder sie haben keine fähigen Leute :) Und SC, Ryanza und HC-GABBER-BUMM-TÄTSCH haben schon gute Jobangebote von Samsung erhalten :)
Naja dann sagen wir hier mal, der K10e ist derzeit der stabilste und beste, oder?
Hier die Kernels :
CWM K10e 500hz
http://dl.dropbox.com/u/14774421/Har...-500hz-CWM.zip
CWM K10e 256 hz
http://dl.dropbox.com/u/14774421/Har...-256hz-CWM.zip
die per Odin:
K10e 256hz
http://dl.dropbox.com/u/14774421/Har...k10e-256hz.zip
K10e 500hz
http://dl.dropbox.com/u/14774421/Har...k10e-500hz.zip
Hmm, also ich kann das absolut nicht nachvollziehen. Zumal ein OLED-Display ja auch nicht ganzflächig altert. Jede organische LED altert unterschiedlich schnell.Zitat:
Zitat von spline
Aber wie ich schon schrieb, die Alterung eines AMOLEDs ist weitaus weniger sichtbar/tragisch als man meinen könnte.
Ich glaube nicht, dass das dort irgendjemand so gewollt hat. Ich vermute mal, dass dieses Problem auf eine Schwankung der elektrischen Leitfähigkeit des Bauteils zurückzuführen ist, welches für die Stromversorgung der organischen LEDs zuständig ist.Zitat:
Zitat von spline
Durchaus möglich, dass die ihre Farbkalibrierung auf ein Model abgeglichen haben, dass für die blauen OLEDs mehr Strom brauchte bzw. weniger empfindlich ist. Es muss definitiv irgend ein Bauteil sein, was für die blauen, grünen und/oder roten OLEDs verantwortlich ist.
Das würde wiederum auch die Schwankungen bei der Farbwiedergabe einzelner Geräte erklären. Ich selbst hab diese bisher immer nachweisen können, wenngleich auch nur minimal und immernoch blaustichig.
Nun, Samsung hat's dabei nur gut gemeint. Sie wollten uns ausreichend Platz für Apps spendieren, deswegen haben die die Data-Partition auf die langsamere, aber dafür größere internene Speicherkarte verlegt. Gut, die hätten statt MLC auch SLC für die internen 8/16GB verwenden können, dann wäre es aber ein ganzes Stück teurer geworden, unser SGS.Zitat:
Zitat von spline
Klar, die MovieNand ist eine Sache, aber das Zusammenspiel mit MovieNand und RFS ... naja wir kennen es.
Also zum Blaustich finde ich noch folgendes:
http://www.pocketpc.ch/samsung-galax...tml#post636146
http://translate.google.ch/translate...e&hl=&ie=UTF-8
und noch mehr Test's:
http://www.displaymate.com/Smartphone_ShootOut_1.htm
zur Lebensdauer:
http://de.wikipedia.org/wiki/Organis...iode#Nachteile
Na schau mal einer an... Wikipedia bestätigt mich sogar indirekt. Die blauen OLEDs leuchten nach über 150.000 Std nur noch halb so stark. Angenommen das Display ist jeden Tag insgesamt 2 Std. eingeschaltet, also ~730Std/Jahr. Damit dauert es über 200 Jahre bis man diesen Halbwerts-Punkt erreicht hat. xD
Wo hast Du den die E Version her ?
Die letzte ist die K10H - läuft Super bei mir.
Habe mich mit CWM angefreundet - einfach mal unterwegs flashen :D bei den massen an updates ;)
Wie ich schon schrieb "warum, wieso weiss keiner". Samsung als absoluter Display Spezialist Weltweit, kann doch nicht so einen Bockmist ohne Grund machen?Zitat:
Zitat von Master_Chief_87
@Grillmeister
"e" deshalb, weil sich bei vielen zeigt, dass K10h unter anderem zuviel Akku saugt.
Stimmt, habe um 5 uhr ausgesteckt und habe nur trillian an. Akku ist auf 80%Zitat:
Zitat von spline
Sent from my GT-I9000
Also bei mir hat sich der verbrauch komischerweise fast verdoppelt. Frag mich ob das an dem kernel liegt xD
Selbst mein 3 KG Superakku hat in 14 Stunden mit mässiger Benutzung 22% verloren :-)
Aber solange ich den billigen Superman Akku hab, kann ich nicht behaupten es läge am Kernel.
Es wäre nicht korrekt.
Wo bleibt K10i ?
Ich habe 15% in 4h verloren mit dem K10H (500 Mhz). Davon 3h im idle und 1h MP3 hören und im Markt stöbern (ohne WiFi, ohne GPS)
Ich möchte hier auch mal die Warnung von Hardcore weitergeben:
Achtung!
Wer ein Lagfixschema ext2 oder ext4nj auf /dbdata und /cache nutzt, sollte sehr gut Aufpassen, den Akku nicht zu entfernen während dem Booten und kein Hardreset (Powerbutton gehalten lassen) machen.
Desweiteren nicht per adb.exe das "reboot" commando durchführen!
Sondern immer das Handy normal runterfahren (bis zum letzten Brummeln).
Weiterhin meint er auch, "kein Grund zur Panik", es passiert schon nichts, wenn man ein wenig Aufpasst und die oben genannten Ratschläge beherzigt.
Das ganze nochmal in Org. Ton
Zitat:
Warning: to those using lagfixes on dbdata & cache, there is a risk of data loss if there is a crash. It's easy to cause corruption if u hard-reboot your phone or pull out the battery while the phone is booting.
Also, NEVER use adb reboot command if u r using a lagfix. Shut down the phone using the normal way.
Supercurio has sent me some feedback on his testing, and he is going to use some safer but slower mount options in the voodoo kernel. I will also make changes to ext4 options in the next version.
I think it's better to have lower quadrant scores but a more reliable phone.
EDIT: I'm doing some testing, it seems with K10H if u converted dbdata/cache to ext4 the risk is not very high. No need to panic. But just be more careful about hard-rebooting your phone - try to always use the power button off command.
damit sind die einträge DBDATA_LOOP und CACHE_LOOP gemeint? Da geht ja nur ext2 oder false...
oder meint er DATA_FS und CACHE_FS?
nicht die loop's.
Es reicht auch wirklich, nur den /data auf ext4 nj zu machen.
Die Geschichte mit dem one (stl)- und movieNand (mmc) muss ich ja nicht noch mal wiederholen?
Auch hab ich gelesen, dass Hardcore mit "normal" ext4, mit Metadaten meint.
Das heisst, im Lagfixschema ext4 sollte automatisch Metadaten (writeback) stehen.
Testen kann man das mit adb.exe ... mount | grep ext4, dann sollten die bzw. der Ordner unter data_writeback sein.
Probiert mal nur ext4 nj auf /data (der alte voodoo sozusagen). Ich glaub damit kann man durchaus zufrieden sein.
Also Spline der Frage von Grilli schließe ich mich an wo hast du die E Version her?
http://touristinparadise.blogspot.co...-speedmod.html
Ich sammle alle Kernel :-)
Bin ein Bytemessi :-)
Also, ich habe moment ext4 all mit journal, heißt dass jetzt das ich keine gefahr beim bösen reboot habe oder nicht? Und /data ext4 nj ist auch gefahrlos? Seh den wald vor lauter bäumen nicht mehr.
Sent from my GT-I900
Steht doch ganz klar oben drin wie Spline erklärt hat.
Wer ein Lagfixschema ext2 oder ext4nj auf /dbdata und /cache nutzt, sollte sehr gut Aufpassen, den Akku nicht zu ziehen.
Wenn du nj nicht Eingestellt hast sollte es keine Gefahr geben.
... die Gefahr durch plötzliches ziehen der Batterie besteht schon seit dem allerersten Lagfix von Ryanza (OCLF).
Das Journal rettet auch nicht 100% vor Verlust. Ich hatte vor kurzen einen Crash mit einem XFS Dateisystem, da half auch kein Journaling mehr.
Sagen wir mal so, was passiert Dir, wenn Du den Akku ziehst und evtl. hinterher ein Datenproblem hast?
- Kannst Du das SGS wegwerfen?
- Ist alles auf nimmerwiedersehn weg?
- Verlierst Du alle Kontakte auf immer?
- Ist Dein Titanium- oder Nandroid Backup weg und Du kannst es nicht mehr einspielen nach dem Crash?
Oder heisst es besser:
- Ich weiss ich sollte immer normal Herunterfahren und nicht den Akku im Betrieb einfach ziehen!
- Ich flashe hier Zeugs herum und weiss, ich hab immer ein Backup auf der Kiste!
- Ich habe meine Kontakte bei Google Online, sowie meine Apps im Market, zur Not Arbeite ich noch mit app2brain!
- Ich weiss wie ich ein so gecrashtes Handy innerhalb von 5 min wieder zum Laufen bringe (CWM/Restore)!
Also was ich nun wieder garnicht verstehen kann das einige so hohen Akku Verbrauch mit der K10H haben. Hab die seit gestern Abend auch drauf und keinerlei Probleme weder vom Laufen noch vom Akku her.
@Spline meintest du mich mit Quatsch geschrieben?
Nein, den Post über Dir, aber ich brauchte länger zum Schreiben.
gestern habe ich die k10h mit ext4nj auf /data geflasht.
gestern abend habe ich dann den lagfix auf ext4 auf /data umgestellt, da mir das sicherer erschien.
heute merke ich, dass das handy langsam und ruckelig ist, ursache: android.process.media zieht fast 100% cpu.
das liegt laut google wohl an korrupten media dateien.
eine suche auf der speicherkarte hat dann auch viele 0-byte grosse avi und mp3 dateien gefunden.
ich vermute, da ist mit dem lagfix irgend etwas schief gegangen und das hat mir die dateien zerlegt. ich habe den jetzt erstmal komplett deaktiviert.
zum glück habe ich ein halbwegs aktuelles backup der speicherkarte,,,
Der K10 ist ja noch in der Test Phase hier kann es immer zu Problemen kommen. Damit sollte auch jeder Rechnen der sich darauf einlässt. Was ich mir angewöhnt habe (frag bitte nicht warum) alten Fix Deinstallieren und dann erst den neuen Kernel Flashen. Dann fix einstellen und Tweaks und Fertig und hatt noch keine Progleme auf diese art.
jo, ich rechne auch mit sowas. der post soll nur ne warnung für andere sein...Zitat:
Zitat von Jens0609
Man kann auch mal den ganzen Mediastorage Löschen unter Einstellungen/Anwendungen/alle/Medien...dinges da
Eidt:
upps die Daten Natürlich, und dessen Cache, nicht das app
Also wie gesagt mein Akku-Verbrauch ist imens hoch seit ich K10H geflasht habe. Mal bis heute abend warten, wenn dann noch kein neuer da ist dann flashe ich zurück auf K10E, den hab ich ja noch auf meinem Rechner zuhause :)
Ich hab doch schon 2x die Links zu allen k10e hier im Thread.
Btw. Bin grad am GPS testen hier draußen.
Hab schnelle Fixes und genügend Satelliten, auch da wo vorher nichts ging.
Nur das Gehüpfe bei Stillstand ist wieder oder noch da.
Sending from galaxy s i9000 using Tapatalk and my finger.
Also mein GPS ist mit H klar schlechter geworden. Das war dann auch der Hauptgrund für mich wieder zurück zur E zu gehen. GPS läuft wieder gut... zumindest für SGS-Verhältnisse xD
Es gibt eine Weiterentwicklung beim Benchmark Tool
Zitat:
Changelog 0.7:
- Comparison bar chart added
- More detailed overall Score
- renamed it for broader future audience
- new icon set
- Minimum iterations is now 4
- the best and worst iteration are not taken for calculations - prevent statistical outliners
- Logfile lies now under TAPBenchmark
- Last benchmark numbers can be copied for fast pasting into this forum (Longpress)
Changelog 0.6:
- Additional Stresstest (Parallel read/write)
- Overall Benchmark Score introduced (has to be refined in future)
- Time for a Single Test can be changed to increase accuracy (maybe)
- Free space can be checked to ensure there is enough (no check before start yet)
- Write and Read test refined (data is now written/read to/from different files)
- Rewritten to be Android style (back-button working now as it should for example ...)
Meins mit ext4 nj auf /data K10H Kernel 500Hz
20101130T190623
Benchmark on /data (4 iterations)
DB writes: 30(1) Writes/s
DB reads: 303(32) Reads/s
DB deletes: 307(6) Deletes/s
File writes 10k: 4955(124) kB/s
File writes 1M: 10398(159) kB/s
File reads 10k: 5772(229) kB/s
File reads 1M: 10928(291) kB/s
File write overhead: 1.056(0.053) ms
File read overhead: 0.817(0.073) ms
Selber Kernel selbe Einstellung wie Spline
Warum hab ich teilweise so merkwürdige zahlen xDZitat:
Details of Performance on /data
Iterations: 6 - Single Test Duration: 1000
Timestamp: 20101206T201102 - 873
Overall Performance: 2999(327)
Database Performance: 428(8)
FileRead/Write Performance: 1902(30)
StressTest Performance: 669(326)
DB writes: 28(2) Writes/s
DB reads: 291(12) Reads/s
DB deletes: 321(3) Deletes/s
File writes 10k: 5239(165) kB/s
File writes 1M: 2825(473) kB/s
File reads 10k: 5930(100) kB/s
File reads 1M: 12889(47) kB/s
File write Overhead: -1.631(0.596) ms
File read overhead: 0.91(0.029) ms
StressWrite: 2385(1527) kB/s
StressRead: 11004(6359) kB/s
Hab auch dieselben einstellungen.
Was ist Merkwürdig und was hast Du für eine Konfi.?
Hab eh grad gesehen das jens auch so minuszahlen hatte. DocRom V8 JPA, ext4nj und HC Kernel K10H 500Hz
Sehr merkwürdig eure Minuszahlen. Habe gerade ein eigenes Thema dafür aufgemacht, wäre sehr interessiert den Grund dafür zu finden. Würde daher vorschlagen dass wir hier weiterdiskutieren:
http://www.pocketpc.ch/samsung-galax...-feedback.html
update von hardcore, wirklich sicher ist wohl nur kein lagfix oder ext4 data:
http://forum.xda-developers.com/show...postcount=4732
ich bin erstmal zurück auf den 9a kernel mit ext4 data lagfix und bisher läuft wieder alles problemlos.
Hab ich auch grad gelesen.
Gut, den Akku im Betrieb ziehen kommt nicht gut, das wissen wir. Neu ist mir allerdings, das der Hardreset also den Powerbutton lange drücken bis es neu Starten auch schaden kann.
Komisch, das hab ich schon sooft gemacht. Bzw. macht beim Hamster Rom das Modifizierte Powerbuttonmenü das gleiche und es ist noch nei was passiert.
Sicher, dass es bei der rom auch so ist?
Glaube nur, dass die shutdown sequenz nicht geladen wird.
Weil das handy kurz vorm aus gehen vibriert und es so lange zum runterfahren brauch.
Lg
Sent from my GT-I9000
So, hab mich mal geopfert zum grossen SPLINETEST "ext4 non Journal vs. Sicherheit". :-)
Test 1:
K10e Kernel mit ext4 nonjournal auf /data/dbdata/cache (also ext4 at all).
Ich mache Asphalt 5 rein, damit auch grade was läuft.
Drück den Powerknopf lange zum forcierten Reboot.
Nach dem Reboot ... das Handy läuft
Spiele Asphalt 5 und zieh mitten im Geschehen den Akku.
Nach Reboot ... Handy läuft
Nun will ich es wissen.
Mache Quandrant an und zieh genau in dem Augenblick den Akku wo er die erste von 4 Datenbanktests macht.
Zack, Licht aus.
Nach Reboot ... kein Reboot, nur noch brumm brumm, nichts geht mehr.
Insofern stimmt es was Hardcore sagt und wir alle ahnen konnten.
So grad wieder frisch, nun folgt der Hardrock Test mit nur RFS.
Stay Tuned
Test 2:
Alles ist auf RFS, ich mache wieder den Quandranten klar und schmeiss den Akku im db writeprozess raus.
Nach dem Reboot, ... alles da alles wunderbar.
Teste nun only Data is ext4 nj.
Test 3:
ext4 ohne journal nur auf /data (vormals voodoo). Wieder im Quadrant im DB write den Akku gezogen.
Handy startet tadellos alles funktioniert.
Test 4:
sollte eigentlich ext normal auf alles sein, aber nach den ersten Versuchen von vorhin machts mir nun Probleme.
Umwandeln zu ext4 ging noch und nach dem Booten kommt kaum noch etwas. Nach langer Zeit kommt dann mal ein Batteriesymbol und die Uhr, aber sonst nix. Da ist nun was durch das umstellen von RFS auf ext4 arg im Eimer.
Versuch ich nun mal ext2 ...
Test 5:
hab nun alles auf ext2, gleicher Test, im Quadrant während des Datenbankenschreibzugriffs Akku ziehen.
Nach dem Reboot alles startet wieder normal.
Fazit:
Der Powerknopf ist wohl kein Grund für Datenverlust. Da muss man schon ordentlich den Stecker ziehen und möglichst auch wenn grad das System bestäftigt ist. Im System und nicht in einem Spielchen das sich mit /data begnügt.
Am Sichersten hat sich also im Sebtest herausgestellt:
ext4 nj auf data ist soweit o.k.
auch o.k. ist RFS wie gehabt und scheinbar auch noch ext2
Was nicht o.k. ist, ist ext4 nj. auf alles.
Empfehlung daher, und fast gleich wie mit Hardcore.
Mit Augenzudrücken macht ext4 nj. auf /data, besser aber langsamer und Stromfressender ext4 Normal auf Data (also mit Journal)
ext2 geht nach meinem Test auch und das sogar auf alles (komisch aber wahr)
RFS geht sowieso, aber des wollen wir ja zumindest im MovieNand beim /data nicht mehr sehen.
Ich werde also ext4 nj. auf data nehmen und den Rest auf RFS.