Android 4.3 moet vertraging Nexus 7 bij langdurig gebruik tegengaan

De meest recente update voor Android lost als het goed is een probleem op bij Googles Nexus 7-tablet met betrekking tot het opslaggeheugen. Doordat dit bij de vorige versies niet van tijd tot tijd opgeschoond werd, konden de prestaties van de tablet op termijn teruglopen.

Het probleem was rondom de introductie van de Nexus 7 nog niet bekend, omdat het pas na verloop van tijd optreedt. Als alle sectoren van het nand-geheugen een keer beschreven zijn, dalen de schrijfprestaties, net als bij de ssd's die in moderne notebooks en desktops te vinden zijn. Dit effect wordt verergerd als het geheugen bijna compleet vol zit, waardoor het eerder optreedt bij de 8GB- en 16GB-modellen dan bij de 32GB-variant. De slechtere i/o-prestaties hebben bij de Nexus 7 als gevolg dat de tablet minder vloeiend werkt.

Bij desktops en laptops wordt dit vermeden door een ssd regelmatig te 'trimmen'; het trim-commando verwijdert dan de deels gevulde blokken, waarna het besturingssysteem deze blokken bij schrijfacties zonder vertragingen kan benutten. AnandTech meldt dat de Android 4.3-update voor de Nexus 7 ondersteuning voor fstrim toevoegt, de Linux-binary die het trim-commando uitvoert, en dat dit automatisch uitgevoerd wordt. Dat zou volgens AnandTech bevestigd zijn door een medewerker van Google.

Tot aan Android 4.3 was er geen ondersteuning voor trim. Wel waren er verschillende apps in de Play Store beschikbaar die op gezette tijden het trim-commando uitvoerde, om zo de degradatie tegen te gaan.

Reacties (64)

[_eXistenZ_]

Om dit op te lossen heb je - als je root hebt - het tooltje LagFix nodig.
https://play.google.com/s...=com.grilledmonkey.lagfix

Dit probleem treedt ook op op de Galaxy Nexus en waarschijnlijk nog wel meer toestellen in de Nexus-lijn van Google.

De reden hiervan is dat de kernel die je meegeleverd krijgt bij een Nexus-device niet af en toe het TRIM-commando uitvoert op je geheugen, waardoor het geheugen naar verloop van tijd zelf niet meer weet welke blocks vrij beschrijfbaar zijn. In dat geval moet er met behulp van de de CPU gezocht worden naar een vrij plekje, waardoor je sloomheid / traagheid / vastlopen ervaart.

Bovengenoemd tooltje voert af en toe wél het TRIM-commando uit, waardoor je device lekker snappy blijft.

Waarom ze in een custom kernel niet deze optie gewoon aanzetten, is mij een raadsel, er was een bugreport van bij Google zelf dat ze het moesten fixen, de fix zit nu dus blijkbaar in 4.3.

Meer info op http://forum.xda-developers.com/showthread.php?t=1971852.

/edit

Bugreport gevonden: https://code.google.com/p/android/issues/detail?id=39271

[Reactie gewijzigd door _eXistenZ_ op 24 juli 2024 10:08]

[Verwijderd]

Het is natuurlijk niet wenselijk om in een tijd dat je nu geen harddisk defragmentatie issues meer hebt door de komst van flash opslag dat je dan op android apparaten een tooltje nodig hebt om je flash geheugen te trimmen.

[Fly-guy]

Vanaf 4.3 heb je dus geen tool meer nodig, dan zit het al in android ingebakken. Heb je geen 4.3, dan kun je het op bovenstaande manier doen.

[Verwijderd]

En waarom treed dit probleem enkel en alleen op bij de Nexus 7 en niet bij alle Android toestellen?

[Rednas_N]

Toevallig heeft mijn Galaxy Nexus een vergelijkend probleem. Bij nader onderzoek hadden meerdere mensen hier last van, de bron met de oorzaak ben ik helaas even kwijt. Ik kan me wel vaag herinneren dat de oorzaak vergelijkbaar was met deze. Na de een reset draaide die wel weer als een zonnetje maar een paar maanden later weer zo traag als het maar kan.

Update:
Hier heb ik de bron gevonden: http://forum.xda-developers.com/showthread.php?t=1971852. Je kan dan een programma 'LagFix' gebruiken om de traagheid te verwijderen, dit werkte zo te zien ook voor de Nexus 7.

[Reactie gewijzigd door Rednas_N op 24 juli 2024 10:08]

[Martinspire]

Dat programma is echter niet met elk toestel compatible. Hier een Galaxy Tab 2 10.1 waar hij niet op te installeren is (iig niet via de store) en die na een half jaar gebruik erg traag is geworden. Bij tijd en wijlen zelfs onwerkbaar.

Maar goed, die moet dan ook nog Android 4.2.2 krijgen voordat 4.3 in de pijplijn zit

[tasqa1004]

Zoals eerder gezegd is het een probleem met het eMMC geheugen. De degradatie is op vrijwel elk apparaat na lang intensief gebruik merkbaar. Dit is al enige tijd bekend. Om de problemen te verlichten zijn er diversen tools geschreven voor verschillende apparaten om hetzelfde kunstje als nu (waarschijnlijk) is opgenomen in 4.3 uit te voeren. Ik quote even uit het artikel:

"I’m told that TRIM support has been part of the eMMC standard since around version 4.2, it was just a matter of enabling it in software. The result is that the new Nexus 7 shouldn’t have these aging affects at all. Better yet, fstrim support has also been added to the old Nexus 7 with as of the Android 4.3 update, so if you’ve got a Nexus 7 that feels slow, I/O performance should get better after fstrim runs in the background. I'm checking on whether the other Nexus devices have also had TRIM support added. I would consider the slow storage aging problem fixed as of now, and Google took the eMMC and storage I/O performance issues with the previous Nexus 7 to heart for this version."

[bogy]

Hopelijk ook voor de fonepad van Asus.
Die krijgt namelijk ook nog updates.
Overlaatst was hij trouwens nogal traag aan het worden en de update die ze toen hebben uitgebracht heeft voor mij veel voldoening gebracht want ik stond bijna op het punt m'n phabje eens volledig terug te zetten naar fabrieksinstellingen.

4.3 zou echt de Max zijn op m'n Intel toestel.

[Verwijderd]

Goeie vraag. Zou ik ook wel antwoord op willen.

Edit: Had iets gelezen over eMMC's in telefoons en dergelijke dat die niet getrimmt hoeven worden en SSD's wel? Zoiets. Kan zijn dat de Nexus 7 een SSD bevat. En het trimm commando niet was toegevoegd toen ze de kernel gecompileerd hadden.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:08]

[Delgul]

Ik heb een Galaxy Nexus telefoon en die heeft er 100% zeker ook last van. Het enige wat helpt is af en toe een factory reset. De fora staan er vol mee...

[Framoes]

Vanwege het vermoedelijk relatief goedkope flash-geheugen in de tablet. Dat krijg sneller last van kuren bij 'vervuiling'.

[blorf]

Een bestandssysteem dat daar last van heeft slaat in 2013 totaal nergens op. Windows 98 had dat ook omdat ie overdreven van alles ging lopen indexeren. Nu is het juist het tegenovergestelde: als de schijf vol is komen we erachter dat er niet genoeg is geindexeerd wat op het laatste moment nog geregeld moet worden en resources kost op het verkeerde moment.
Konden ze niet gewoon ext3 oid forken? Het moet allemaal weer zo nodig opnieuw uitgevonden worden.

[Umbrah]

De nexus 4 gebruikt Ext4 bij mijn weten, dit gaat niet over het filesystem, maar meer over een algemene flash geheugen eigenschap. Ntfs, zfs en zelfs gpfs zullen hier last van hebben, vandaar dus ook trim.

[blorf]

Volgens mij heeft flash-geheugen als eigenschap dat je volledig en gelijkmatig addresseerbaar is en dat bij schrijven het er niet toe doet wat er waarmee overschreven wordt, een 1 of een 0. Een andere toestand zoals een "nog niet goed voorbereide cel" of iets dergelijks bestaat niet, het is nul of een.
Als je een stuk flash-geheugen volschrijft met random-getallen en je gooit daar een leeg filesystem overheen zonder enige vorm van formatteren lijkt het me logisch dat ie precies net zo snel is als wanneer hij vol staat met alleen nullen of enen. De kans op corruptie is misschien alleen iets groter omdat bij een klein index-gerelateerd foutje het softwarematig recoveren nogal moeilijk gemaakt wordt met al die rommel die tussen de gebruikte stukken staat.

Als je het mij vraagt kan het niet anders dan dat deze problemen aan de software-implementatie van het bestandssysteem liggen, wat ik dus een beetje uit de tijd vond.

[Reactie gewijzigd door blorf op 24 juli 2024 10:08]

[Verwijderd]

Lees er dit eens op na: http://www.zdnet.be/hardw...rkt-een-solidstatedrive-/ Het is niet al te technisch, maar legt gemakkelijk uit hoe een SSD werkt, en vooral, wat het probleem is met het adresseren.

In een notedop, door zinnen te citeren:
SSD's kunnen alleen volledige blokken wissen en geen pages of cellen apart. Dit betekent dat als er ook maar één bit gewijzigd moet worden aan een bepaald blok, dat blok eerst volledig ingelezen moet worden in de cache... Dit is uiteraard veel trager dan een simpele leesactie... Onder andere hiervoor wordt het algoritme in de controller ontworpen om wijzigingsacties weg te schrijven in ‘verse’ blokken in plaats van gebruikte blokken...Dit alles betekent dat de schrijfsnelheid van een SSD serieus daalt naarmate er meer naartoe geschreven wordt. Hoe meer vrije blokken, hoe meer keuze de controller heeft in de verdeling van de schrijfacties....Een besturingssysteem zal schijfbewegingen uitsparen door bij het wissen van grote bestanden niet werkelijk alle sectoren te wissen, maar alleen begin- en eindsectoren van de bestanden. Een SSD is niet op de hoogte van deze acties, en dit betekent dat bepaalde blokken voor een SSD als ‘in gebruik’ staan, terwijl het OS ze eigenlijk niet meer kan gebruiken....Via een bepaald commando kan een besturingssysteem doorgeven aan de SSD om alle onnodige blokken ook echt te wissen (eventueel op een stil moment van de dag), zodat het aantal gebruikte blokken laag blijft en de SSD niet te snel aan snelheid inboet.

Het ligt dus met andere woorden wel degelijk aan de inherente werking van een SSD. Maar dit gezegd zijnde, mocht het TRIM commando wel wat vroeger in android geïmplementeerd worden.

[Marc Rademaker]

Heeft niet bijzonder veel met het OS te maken volgens mij. Zoals iemand al opmerkte, het gaat om lege cellen, die langzaam beschreven kunnen worden. Dat komt dus omdat er geen trim-commando is / was. Daardoor moeten cellen die volgens het bestandssysteem leeg zijn, eerst ook daadwerkelijk leeggemaakt worden, alvorens ze weer gevuld kunnen worden.

Hoe ssd's bijvoorbeeld tegenwoordig werken, is door cellen die gevuld zijn, maar volgens het OS dus leeg zijn, alvast leeg te maken, zodat ze snel weer gevuld kunnen worden in plaats van dat er eerst een erase-commando naar toe moet, voordat het schrijfcommando uitgevoerd kan worden.

Zelf heb ik er nog niet bar veel last van met mijn Nexus 7, misschien heeft dit te maken met het feit dat ik een 32GB-versie heb. Het geheugen is echter al wel een keer volledig vol geweest, maar dat wil niet zeggen dat alle cellen volgeschreven zijn geweest. Anyhow, 4.3 moet maar snel OTA komen, anders moet ik alsnog dat ding gaan rooten.

[Fly-guy]

Je hoeft niet te rooten om de stock image 4.3 op je nexus te zetten... Slechts de bootloader "unlocken" en de factory 4.3 image flashen is genoeg. In een paar minuten gedaan.

[Verwijderd]

bedoel je dat de ssd kan bepalen welke blokken leeg zijn? dat zou ik vrij spectaculair vinden. ik denk eerder dat het FS dit bepaalt en doorgeeft aan de ssd.

[SuperDre]

Elk bestandsysteem heeft zo zijn voor en nadelen.. Ook bij moderne OSsen vraag ik me soms af waar die mee bezig is, waarom bv indexen? voor die paar keer dat ik iets moet zoeken, dan wacht ik wel paar seconden langer..

[Verwijderd]

ik wacht al tijden op een fs voor linux dat snapshots kan maken.

[Roconda]

LVM kan dit al jaren.
Btrfs en ZFS kunnen dit ook, deze filesystems zijn alleen nog wel in developmentfase dus niet aan te raden voor productie.

[iChaos]

Goede zaak. Gebruikers die reeds hun Nexus 7 geroot hadden konden dit al op zeer eenvoudige wijze doen met o.a. LagFix, maar ofwel weten velen daar niet van af, of hebben ze geen rooted tablet. Fijne update, die 4.3. Geen revolutionare zaken aan de oppervlakte, maar onder de motorkap wel een boel aangename features

[SuperDre]

tja, leuke en fijne update misschien, maar genoeg devices die deze update niet meer krijgen, ondanks dat ze deze makkelijk zouden kunnen draaien.. En dat is meteen 1 van de grootste nadelen van android, de afhankelijkheid van de fabrikant van het device..

[Shadowron]

Dit is onzin. Het zit hem namelijk in de Tegra 3 SOC.
Er zijn diverse mensen (ik ook) geweest met een HTC One X die dit probleem ook hadden. Ook een tablet van Asus met een Tegra 3 SOC heeft hier last van (weet niet zo welk model). Zodra de opslag vol begint te raken gaan de I/O prestaties gigantisch hard achteruit.

Zou je hier meer over willen weten, verwijs ik je naar een thread op XDA. Hier staat precies wat er mis gaat.

Wel fijn dat er nu een native oplossing is i.p.v. een 3rd party zoals LagFix.

[Reactie gewijzigd door Shadowron op 24 juli 2024 10:08]

[redecal]

ik heb 3 Tegra 3 apparaten, Nexus 7, HTC OneX+ en Asus Transformer Infinity

alle 3 ge-root en regelmatig lagfix draaien, daarnaast fsync disabled en dan zijn ze op zich lekker snel. de Transformer Infinity heeft daarnaast ook nog het probleem dat er traag nand geheugen is gebruikt waardoor je beter Data2SD kan gebruiken met een snelle (Class 10) SD-Card.

dat zijn van die dingen waardoor ik mensen gelijk moet geven als ze apple kopen: ik bedoel, ik vind het leuk om met die apparaten te klooien, te rooten en te flashen, maar er zijn zoveel gebruikers die dit niet kunnen doen omdat ze het simpelweg niet snappen.

als je dan bv een Asus Transformer gekocht hebt (nieuw 700 euro) en dat ding is dan zo tergend traag dat er bijna niet mee te werken is (stock Jelly Bean was echt verschikkelijk, duurde soms meer dan 10sec voordat het toetsenbord oppopte bij de browser) dan baal je best wel.

Ik heb na aanschaf van de Asus mijn iPad 2 aan mn vriendin gegeven, maar die was af en toe echt verbaasd dat mijn tablet zo traag was als ze hem in haar handen had.

Begrijp me niet verkeerd, ik ben echt Android fan, maar een hoop apparaten zijn gewoon met teveel issues en/of slechte componenten uitgebracht, helaas...

[blouweKip]

Niet meer bij die fabrikant kopen dus, ik houd het gewoon bij nexus apparaten tegenwoordig (overigens ben ik afkomstig van een ipad 1 die na korte tijd geen ondersteuning van apple meer kreeg...en nee: rooten en updaten kan daar niet)

[MegaTronics]

Klopt, die werkt perfect voor pre 4.3. Toen mijn Nexus 7 bijna vol stond heb ik er gebruik van gemaakt. Ondertussen is die weer voor de helft leeg, dus nu geen probleem meer (mede doordat er nu ook al 4.3 op staat).

[Reactie gewijzigd door MegaTronics op 24 juli 2024 10:08]

[Pinin]

Op mijn tf101 heb ik ook lagfix en dat bevalt idd goed. Ik doe het 2x per week, dmv een shedule.
Maar hoe vaak moet je het doen?

[cyberstalker]

Dat hangt van meerdere factoren af. Ten eerste hoeveel je schrijft naar de schijf en ten tweede hoe vol de schijf is.

Bij een schijf die slechts 10% gevuld is zal het waarschijnlijk lang duren voordat alle blokken gebruikt zijn en zal het dus niet zo geregeld nodig zijn. Is je schijf 90% gevuld dan zullen de paar lege blokken snel gebruikt worden waarna het traag wordt.

Dat gezegd hebbende, twee keer per week lijkt me ruim afdoende.

[twooggy]

Dit speelt natuurlijk niet alleen bij de Nexus 7, ik merk op mijn Galaxy S i9000 met JB 4.2.2, dat als mijn interne opslag bijna vol is, er ook niet meer mee te werken valt. Laatst eens grote schoonmaak gehouden en hij doet het nu weer vlot (genoeg). Ik ben wel benieuwd of dit ook weer op mijn (oude) beestje gaat werken.

[Reactie gewijzigd door twooggy op 24 juli 2024 10:08]

[watercoolertje]

Dat heeft er alleen niks mee te maken...

Dit gaat om LEGE ruimte die niet snel is, niet om VOLLE ruimte

[Master_duck]

Heb Gisteren de 4.3 update binnen gekregen en geinstallerd op mijn Nexus 7.
De bestuuring en laden van app's voelt veel better aan. ik heb alleen geen test of vergelijking gedaan. maar de ervaring zijn voorlopig goed.

[Verwijderd]

Ik heb hem verkocht en hij was supersnel voor de 10 maanden dat ik hem had. Als hij wat trager wordt, dan zou je gewoon een factory reset moeten uitvoeren.

-1? laat me niet lachen!

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:08]

[iChaos]

Werkt waarschijnlijk niet. Ik heb geen idee hoe de stock recovery het aanpakt, maar een custom recovery doet de factory reset door gewoon de desbetreffende mappen te verwijderen (omdat de map van 'externe opslag' niet gewist mag worden). In dat geval komt er dus geen format aan te pas, en zal het ook niet tot verbetering leiden. Indien de partitie wel gewiped wordt vraag ik me af of een format ook gelijk hetzelfde effect oplevert als een trim.

[RedShift]

Dat levert inderdaad niets op want er wordt gewoon een nieuw bestandssysteem gemaakt (de inhoudstabel wordt vervangen door een lege), de effectieve data areas worden niet gewist. mkfs heeft zelf geen optie om dit te doen.

[YopY]

Maar als dat zo is wordt de ' gefragmenteerde' data toch gewoon overgeschreven, waardoor het probleem zich niet meer voor doet?

[Tozz]

Je haalt 2 verschillende lagen door elkaar. Het trim commando werkt op block-level niveau, dus direct op de sectoren van de disk.

Een filesysteem is een niveau dat op het block-level niveau rust. Een nieuw filesystem aanmaken is daarom niets anders dan een bestand verwijderen of een bestand kopieren. Welke sectoren daarvoor worden toegewezen weet het filesysteem niet, dat regelt de schijf zelf.

Bij trim worden sectoren gemarkeerd als vrij, waardoor die hergebruikt kunnen worden. Bij een nieuwe format gebeurt dat niet. BEstaande data wordt alleen overschreven (lege inhoudstabel).

[looc]

Het probleem doet zich juist voor als er al data op de sectors staat en deze worden overschreven.

[Luke_msx]

Ik heb hem na twee maanden al weer verkocht omdat het ding zo traag en laggy was, en dat terwijl het geheugen niet eens voor de helft gevuld was... Het is voor Google zeker te hopen dat dit probleem zich bij de nieuwe N7 niet opnieuw voordoet, want er is al imagoschade opgelopen.

[Verwijderd]

Altijd weer lees je over problemen met Android die opgelost worden door een nieuwe release. Maar die problemen werden zowel door de reviewers op tweakers.net als door mijzelf niet ervaren.

Vergelijk ook project butter dat kwam ook totaal onverwacht om vermeende stroperigheid van de interface op te lossen. Zelf, en ook de reviewers van tweakers.net, heb ik dat nooit ervaren in pre-butter versies. Vreemd is dat.

[Verwijderd]

Mss moet je eens vergeleken met een ander OS dan merk je het mss wel.

[Verwijderd]

Ligt er ook aan welke Android toestel je er naast legt.. De N7 voelde wel wat stroperiger aan. Bij het opstarten van apps. Maar eenmaal geladen in het geheugen was er helemaal niks aan de hand.

Daarnaast, leg eens de Nexus 4 naast een iPhone of een WP telefoon. De Nexus 4 is flitsend snel en super soepel. Dus dat is ook zo van... heb je het over Android of over OEM bedrijven die net niet genoeg energie steken in het optimaliseren van hun drivers etc.

Waar doel je op.. je moet specifieker zijn. Wat voor soort model, welke Android versie en welke OS vergelijk je hem mee op welk toestel? Er is een wereld van verschil overal in.

[Deddiekoel]

Ik heb een Nexus 4 en vind hem, in vergelijking met iOS en WP, zeker niet "flitsend snel en super soepel".
Ja, het is de soepelste Android ervaring die ik heb gehad maar iOS en WP zijn naar mijn mening altijd soepeler geweest. Een van de dingen die Google maar niet onder de knie krijgt is (met name webpagina's) soepel te laten scrollen.

[Fly-guy]

Dat komt vooral vanwege verschillende prioriteiten. Als je bij ios je binger op het scherm plaatst. "bevriest" ios alle processen op dat scherm om zo prioriteit te geven aan het scrollen. Laat je het scherm weer los, dan gaat alles weer verder.
Bij android blijft alles gewoon doorwerken, zodat er veel minder capaciteit beschikbaar is voor het scrollen, waardoor dat inherent minder soepel gaat.

[Luke_msx]

Bij android blijft alles gewoon doorwerken, zodat er veel minder capaciteit beschikbaar is voor het scrollen, waardoor dat inherent minder soepel gaat.

Alleen tweakers interesseert een dergelijke technische uitleg. Voor de gebruiker voelt Android (terecht) als stroperig. Een device dat je 80% van de tijd gebruikt om door content heen te scrollen moet dat gewoon soepel kunnen doen, zeker als je ziet wat voor CPU's en GPU's ze anno 2013 in die Android devices stoppen. Het is werkelijk te belachelijk voor woorden dat Google dat ondanks dingen als 'Project Butter' maar niet voor elkaar weet te krijgen. (lees de review van de nieuwe N7 op The Verge eens, het lukt ze dus nog steeds niet...)

Onderliggend issue is dat zaken als 'gebruikerservaring' en 'gebruiksvriendelijkheid' voor Google van secundair belang zijn, zolang die apparaten maar zo goedkoop zijn dat de markt er mee overspoeld kan worden. Google verdient niet aan Android, Android is slechts een middel om toegang te krijgen tot de informatie van zoveel mogelijk mensen.

Helaas heeft dat zijn weerslag op de kwaliteit van het geleverde product.

[Edax]

Vorig jaar september werd er al over slomer wordende N7's geklaagd, het is echt ongelooflijk dat het zolang heeft moeten duren voordat er een fix kwam. Dat Google hier zomaar mee weg komt.

[Verwijderd]

inderdaad. Omar precies die reden heb ik al mijn android devices de deur uitgedaan, te beginnen met de nexus 7 die Na de eerste update megatraag was geworden..