Dlaczego mój smartfon zamula się po pewnym czasie?
134
Ach to uczucie, gdy z pudełka wyjmuje się nowy gadżet. Pierwsza konfiguracja, ochy, achy, i wszystko śmiga jak należy. A po kilku tygodniach... czar świeżości pryska. Niegdyś wymarzony i sprawnie działający sprzęt zaczyna działać coraz bardziej ociężale. Brzmi znajomo? Przez coś takiego przechodzi większość użytkowników. Niektórzy zrzucają to na „mułowatość” nielubianego przez siebie systemu, inni doradzają aby nie instalować miliona niepotrzebnych aplikacji, a jeszcze inni stwierdzają, że im wszystko działa i narzekająca osoba musi mieć jakieś zwidy. No więc gdzie tak naprawdę leży problem?
Jest on bardzo złożony i może zależeć od wielu czynników, ale bardzo często winowajcą jest główny nośnik danych urządzenia. Jest to element naszych kieszonkowych komputerów, który otrzymuje znacznie mniej uwagi, niż powinien. Zresztą to nic dziwnego, bo choć piksele, megaherce i rdzenie łatwo „sprzedać” specjalistom od marketingu, to mało kogo interesuje ile wbudowana pamięć flash danego smartfona wyciąga „ajopsów” przy losowym zapisie małych plików. Prawda, że brzmi to abstrakcyjnie?
A skąd przekonanie, że to właśnie o to chodzi?
Z obserwacji i z... logiki. Już od dłuższego czasu w testach tabletów i smartfonów publikowanych na PCLabie pojawiają się wykresy z Androbencha. Domyślam się, że większość z Was je całkowicie ignoruje, bo są one mało interesujące. No i nie czarując zbyt mocno, ja też przez długi czas miałem problem z właściwym zinterpretowaniem tych cyferek, więc w pewnym sensie Was rozumiem ;) Ale warto na nie patrzeć, bo w praktyce są one czasem nawet bardziej istotne, niż wynik Geekbencha, czy GLBenchmarka, bo mają one dużo większy związek z komfortem użytkowania, niż jakieś punkty i „efpeesy”. Po prostu patrząc na wynik testu szybkości zapisu losowego warto pamiętać o pewnej prostej zależności, którą wypatrzyłem w czasie przerzucania kilkudziesięciu smartfonów i tabletów z Androidem – jeśli jakieś urządzenie uzyskuje tam mniej niż 0,3 MB/sek., to znaczy, że na 100% w czasie gdy jest coś pobierane w tle, instalowane, czy po prostu w czasie przełączania się między aplikacjami będzie ono muliło i wydawało się działać dużo wolniej, niż sprzęt uzyskujący ponad 0,5 MB/sek., nawet jeśli ten drugi ma teoretycznie dużo wolniejszy procesor. W tym momencie wystarczy mi kilka minut z jakimś urządzeniem i sprawdzenie jak się ono zachowuje w czasie podpinania różnego rodzaju kont i instalowania aplikacji, aby znać mniej więcej wynik Androbencha, zanim go jeszcze zobaczę. Serio – nawet coś co ma milion rdzeni taktowanych zegarem bilion gigaherców, to nie będzie w pełni płynne, jeśli ma pamięć flash uzyskującą 0,2-0,3 MB/sek w tym benchmarku. Z obserwacji wiem, że wszystko powyżej 0,5 MB/sek. można uznać za w miarę akceptowalne, ale naprawdę fajnie robi się dopiero w najnowszych urządzeniach, osiągających w tym teście ponad 1 MB/sek.
A jest to logiczne, bo pokrywa się chociażby z tym, co zauważają użytkownicy desktopów. Jeśli jesteś jednym ze szczęśliwców posiadających nośnik SSD, to zapewne dobrze pamiętasz ten moment, gdy pierwszy raz uruchomiłeś świeżo zainstalowany na nim system operacyjny i o ile szybciej wszystko zaczęło działać. Tak samo jest tutaj i jakość wbudowanego w smartfon/tablet nośnika danych ma spore przełożenie na komfort użytkowania go. Zresztą, dziwnym zbiegiem okoliczności, 0,2-0,3 MB/sek. losowego zapisu małych plików, to mniej więcej tyle samo, ile uzyskują klasyczne twardziele, co skutecznie działa na wyobraźnię ;) Co prawda praktyczne różnice między najnowszymi SSD-kami są niemal niezauważalne (chyba, że ktoś bardzo chce się pochwalić przed kumplami, że jego „dysk” ma 500 MB/sek. zapisu, a nie „tylko” 400), ale gadżetowe nośniki eMMC mają przed sobą jeszcze daleką drogę, zanim ich wydajność przestanie mieć znaczenie dla użytkownika.
Ale to dopiero połowa historii
Jednak powyższe słowa, choć mówią czemu niektóre urządzenia mulą, choć teoretycznie nie powinny, w żaden sposób nie odpowiadają na pytanie zadane w tytule. Przez długi czas główkowałem nad tym i miałem wrażenie, że brakuje mi jakiegoś elementu w tej układance, aż w końcu został mi on pokazany palcem w jednym z tekstów opublikowanym na Anandtech, który później (często z różnymi przekłamaniami) obiegł internet. To powinno być dla mnie oczywiste (a może po prosto było zbyt oczywiste), ale smartfonowa pamięć eMMC to przecież taki nośnik SSD w mniejszej skali, a więc kontroler i system plików muszą radzić sobie z wyzwaniami typowymi dla SSD-ków, które były rozwiązywane w różny sposób jakieś trzy, czy cztery lata temu. Po prostu myślałem, że od tamtej pory wszyscy się nauczyli jak właściwie opiekować się pamięcią flash, ale... myliłem się. Krótko mówiąc, każdy nośnik oparty na pamięciach flash zwolni po pewnym czasie, jeśli:
- niemal całkowicie zapełnisz go danymi (dobrym zwyczajem jest pozostawianie przynajmniej 20% wolnego miejsca, bo poniżej tej granicy zawsze robi się trochę wolniej)
- komórki pamięci nie są w nim trimowane, co niestety dotyczy większości urządzeń z Androidem
Nad tą pierwszą rzeczą nie będę się zbytnio rozpisywał, ale druga może wymagać dla niektórych z Was wyjaśnienia. W przypadku klasycznych dysków talerzowych, gdy się kasuje jakiś plik, to nie jest on fizycznie wymazywany z nośnika, ale po prostu system zaznacza sobie, że zajmowane przez niego wcześniej miejsce można ponownie wykorzystać i nowe dane są „nadpisywane” na pozostałości starych bez jakiejkolwiek straty wydajności. W nośnikach flash działa to inaczej i zanim jakiś sektor nośnika będzie mógł być ponownie wykorzystany, to najpierw musi zostać wyczyszczony z pozostałości po skasowanych danych. Niestety, domyślnie nie dzieje się to w momencie wciśnięcia guzika Delete na klawiaturze, a tuż przed zapisaniem nowych informacji w ich miejsce. Jak mocno spowalnia to zapis danych? To zależy od konkretnego nośnika i jego kontrolera, ale czasem różnica bywa bardzo duża (niektórzy z Was zapewne pamiętają niesławne JMicrony...).
Rozwiązaniem tego problemu jest TRIM, czyli komenda, która w momencie jej wywołania, nakazuje wyczyścić nośnik z pozostałości po skasowanych plikach, zanim zaistnieje potrzeba zapisania czegoś nowego w ich miejsce, dzięki czemu nośnik może pracować cały czas z pełną szybkością. Sposoby na zaimplementowanie i wywoływanie tego mechanizmu są różne i zależą od systemu operacyjnego, kontrolera i innych czynników, ale można je wrzucić do dwóch głównych worków: trimowanie całego napędu co jakiś czas, gdy urządzenie akurat nic nie robi, albo trimowanie plików od razu w momencie wciśnięcia guzika Delete.
Smartfonowo-tabletowa praktyka...
... jest taka, że w większości urządzeń nie korzysta z TRIM, choć jego obsługa jest w Androidzie od dawna. Ale jak to? To nie została ona wprowadzona dopiero w Androidzie 4.3? Nie. Najprostszym sposobem na wywołanie TRIM w Androidzie, jest skorzystanie z systemu plików ext4 i flagi discard. Jeśli producent sprzętu ustawi flagę discard, to TRIM jest uruchamiany od razu w momencie kasowania pliku, więc dane są usuwane nie tylko „z widoku” użytkownika, ale też fizycznie. Właściwie jedynym warunkiem, aby to zadziałało, jest posiadanie sprzętu z niezamierzchłą wersją Androida, który ma pamięć eMMC w wersji 4.4, lub nowszej. Z tym pierwszym warunkiem nie powinno być problemu, a z tym drugim... bywa różnie. Teoretycznie są one produkowane już od kilku lat i powinny występować we wszystkich nowych smartfonach i tabletach, ale niektóre nowości nadal mają swoje systemy zainstalowane na magazynowych leżakach, które nie dość, że w standardzie są dramatycznie wolne, to nie da się ich „ztrimować” w żaden sposób.
W jaki sposób sprawdzić, czy Twoje urządzenie „discarduje” dane i dzięki temu jest w 100% odporne na spowalnianie nośnika danych z biegiem czasu? Trzeba je podłączyć do komputera w trybie debugowania USB i skorzystać z dwóch komend adb: najpierw wpisać adb shell, a potem mount. To drugie polecenie wyświetla wszystkie systemy plików i ich parametry. Jeśli wśród podanych informacji znajduje się coś takiego:
to jest dobrze. Do tej pory odnalazłem to w Samsungu Galaxy S4 (Android 4.3) i... Kiano Elegance 8 3G (Android 4.2). Także wiele ROM-ów z XDA ma domyślnie włączony discard dla partycji systemowej i z danymi, co przyczynia się do tego, że wielu użytkowników zauważa po ich zainstalowaniu sporą poprawę w szybkości działania systemu.
W nowych Nexusach z Androidem 4.3 i 4.4 skorzystano z innego rozwiązania. Gdy sprzęt jest przez jakiś czas nieużywany, to działające w tle procesy uruchamiają „odśmiecarkę” trimującą odpowiednie sektory nośnika danych. Najpewniejszym sposobem na wymuszenie „sprzątania” na Nexusie 7 jest zostawienie go podłączonego do ładowarki na noc, bo wywołanie funkcji fstrim jest obwarowane kilkoma wymaganiami dotyczącymi chociażby poziomu naładowania akumulatora, czasu nieaktywności itp. Krótko mówiąc, sposób ten działa, ale nie przepadam za implementacją tego typu. Bo co jeśli ktoś ładuje tablet gdy jest on wyłączony? Albo tylko doładowuje go w ciągu dnia od czasu do czasu? Albo ładuje w czasie grania, oglądania czegoś, albo surfowania po Internecie? Jeśli masz takie zwyczaje, to może się okazać, że nośnik Twojego Nexusa nie będzie trimowany nawet przez kilka tygodni. Zresztą okazało się, że mój nie był i z biegiem czasu zaczął wyraźnie zwalniać. Wystarczyło go tylko podłączyć na noc do ładowarki, sprawdzić logi systemowe:
... i wydajność wróciła do normy.
Jeśli nie masz Nexusa, ani twórca Twojego sprzętu nie pobłogosławił go discardem, to jest jeszcze jeden sposób na TRIM – manualny. Na Google Play Store znajduje się program LagFix, który ręcznie wysyła komendę TRIM do nośnika danych. W wersji płatnej można nawet ustawić, aby proces ten był uruchamiany codziennie, albo raz w tygodniu. Jest tylko jeden problem – wymaga on zrootowanego systemu. Jeśli nie wiesz co to znaczy, to niestety w tym wpisie tego nie będę tłumaczył.
Różnice, różnice
W ramach testów pomęczyłem trochę dwa urządzenia: LG G2, który domyślnie nie ma zaimplementowanego żadnego mechanizmu wywołującego TRIM i Nexusa 7, w którym łatwo „ominąć” sprzątanie nośnika danych. G2 używałem regularnie przez kilka miesięcy i zauważyłem, że ostatnio zaczyna się robić ślamazarny. W końcu go zrootowałem, przeczyściłem mu pamięć i poniżej można zobaczyć efekt.
Pamięć eMMC Nexusa lepiej znosi upływ czasu bez trimowania, ale i tak po przeczyszczeniu jej wszystko zaczęło działać po prostu szybciej. Natomiast LG G2... no właśnie. W przypadku niektórych urządzeń różnica bywa bardzo duża. A teraz wyobraźcie sobie, że czysta pamięć jakiegoś sprzętu „wyciąga” początkowo nie prawie 1 MB/sek (tak jak G2), ale około 0,5 MB/sek. i spowalnia o tyle samo procent, co w smartfonie LG. Właśnie coś takiego działo się na przykład ze starym Nexusem 7 i niektórzy użytkownicy przed aktualizacją do Androida 4.3 (szczególnie ci, którzy zainwestowali w wersję 8 GB) po pewnym czasie narzekali na to, że ich tablet staje się niemiłosiernie powolny, choć początkowo wszystko działało jak trzeba. I nic dziwnego, bo z tego co widziałem w sieci, niektóre Nexusy 7 2012 osiągały w Androbenchu w teście zapisu losowego wyniki na poziomie pojedynczych (czyli mniej niż 10!) operacji na sekundę.
Powyższy slajd Samsunga pochodzi z listopada 2011 roku, czyli problem i jego świadomość nie jest nowa, ale nadal mało kto korzysta z TRIM-u w smartfonach i tabletach. Warto też zauważyć, że wynik średniej szybkości zapisu danych nie opowiada całej historii.
A jak to jest z innymi systemami?
Powyższe akapity skupiają się na Androidze, ale jak wspomniałem na początku, nie jest to kwestia „mułowatości” jednego systemu, a ograniczeń pamięci flash montowanej w naszych gadżetach i tego, jak z nimi radzą sobie programiści. Czy problem ten dotyczy też Windows Phone i iOS? W pewnym stopniu tak, choć nie ma tego jak za bardzo sprawdzić. Pierwsze iPhony raczej na pewno nie były trimowane, ale nie mam pojęcia jak to jest z ich najnowszymi wydaniami, bo znalezienie bardziej szczegółowych informacji na temat systemu plików iOS i tego jakie funkcje w nim zaimplementowano jest bardzo trudne. Tak samo jest z Windows Phone. Podejrzewam, że Windows Phone 7, oparty jeszcze na starszym jądrze systemowym, również nie wiedział co to TRIM, bo powstawał w czasach, gdy jeszcze mało kto był świadomy tego problemu. A czy w Windows Phone 8 działa to jak powinno? Zapewne tak, bo jest oparty na kernelu Windows NT, więc byłbym bardzo zdziwiony, gdyby w tym systemie nie zaimplementowano „śmieciarki”, skoro w biurkowym Windowsie wywodzącym się z tego samego kernela jest ona aktywna od czasów Windowsa 7.
tl;dr
Na koniec skrót dla osób, którym nie chciało się przekopywać przez powyższą ścianę tekstu. Jeśli twój smartfon/tablet po pewnym czasie zaczyna wyraźnie zwalniać, to istnieje duże prawdopodobieństwo tego, że ma on kiepską pamięć flash, która nie jest regularnie „sprzątana” przez system. Jak temu zapobiec i jak to rozwiązać?
- Najlepiej zapobiegać. Urządzenia z małą ilością wbudowanej pamięci i bez slotu na kartę pamięci są dużo bardziej podatne na wspomniane tu spowalnianie, więc w pewnym stopniu można się ubezpieczyć na przyszłość już w czasie zakupów.
- Po zakupie gadżetu, należy nie instalować na nim wszystkiego co się da, utrzymywać jak największą ilość wolnego miejsca (dobrze jest, gdy jest go przynajmniej 20%), a dane trzymać na karcie SD.
- Jeśli masz jakiegoś Nexusa z Androidem 4.3, lub 4.4, to należy pamiętać o tym, że czasem trzeba go zostawić włączonego na noc z podpiętą ładowarką, bo dopiero wtedy jego pamięć zostanie „posprzątana” i jej szybkość wróci do normy.
- Jeśli wiesz jak zrootować swój sprzęt, to zrób to i skorzystać z programu LagFix.
- No i zawsze można się modlić o to, żeby dane urządzenia otrzymało aktualizację oprogramowania dodającą jakąkolwiek implementację TRIM (i wcale nie musi to być Android 4.3).
Jak duże ma znaczenie np. prędkość pamięci w ładowaniu się galerii obrazków. Tak prosta funkcja jak że trudno o lepszy przykład, gdzie ta pamięć ma znaczenie.
Jak słusznie zauważyłeś np. podczas ściągania czegoś w tle telefony ze słabą pamięcią sobie nie radzą. Po prostu muli... Przykład problemu, który o ile w PC praktycznie nie istnieje to w telefonach istanieje jak najbardziej.
W świecie gdy mamy tak duży wybór telefonów praktycznie nie ma wyboru....
Nie możesz sobie kupić high-endowego telefonu 4 calowego praktycznie tu tylko jest iOS...
Niestety inni producenci oszczędzają na pamięci, ekranie, czy baterii i aparacie.
Niestety, ale o ile low-end penetruje do High-Endu. Mamy totalny szrot w wielkości 4,3<, to w drugą stronę trendu nie ma. Szrot imituje high-end i wszyscy są zadowoleni...
Ja wgrałem na S1 CM-a i zapomniałem o samsungu. Tu po prostu wszystko działa, a nawet to co nie powinno (np. Radio FM oficjalnie Andek nie wspiera)...
To porażające jak tak kluczowy parametr producenci sami mogą zepsuć. Swoją drogą nigdy nie odczułem, by aplikacja FB coś takiego robiła, ale też zawsze wywalam bloatware
Ja na Andku nigdy nie odczuwałem mulenia, ale cóż taka dziwota moich telefonów
Ja też mam telefon z tym systemem i chociaż mulenie nie jest jakieś olbrzymie, to jednak występuje. Kupiłem go niecały rok temu, już dwa razy musiałem go do fabrycznych przywracać, bo spowolnienia zaczynały być (zwłaszcza, że to dość niski model, nie najszybszy sam z siebie) cokolwiek irytujące.
Aczkolwiek i tak działał dużo szybciej, niż tak samo zawalone appsami androidy po podobnym czasie
przed uzyciem apki:
zapis losowy: 0,38MB/s (99 IOPS)
zapis ciągły: 5,76MB/s
po użyciu apki:
zapis losowy: 0,59MB/s (152 IOPS)
zapis ciągły: 5,73MB/s
Dzięki za dobre ogarniecie tematu i namiary na aplikację
Ja też mam telefon z tym systemem i chociaż mulenie nie jest jakieś olbrzymie, to jednak występuje. Kupiłem go niecały rok temu, już dwa razy musiałem go do fabrycznych przywracać, bo spowolnienia zaczynały być (zwłaszcza, że to dość niski model, nie najszybszy sam z siebie) cokolwiek irytujące.
Aczkolwiek i tak działał dużo szybciej, niż tak samo zawalone appsami androidy po podobnym czasie
Ja nie musiałem nic na szczęście formatować. Ale mam szybki telefon Lumia 800. Czyli z wyższej serii z procesorem 1.5Ghz oraz 512MB pamięci. Telefon od dwóch lat działa idealnie płynnie. Jedyna aplikacja która potrafi zirytować to Filmweb ponieważ coś odczytuje ze zdalnego serwera który jest wolny. Ale to wina aplikacji a nie telefonu. Bo ta aplikacja od początku tak źle działa. Jestem z tego telefonu bardzo zadowolony i na dzień dzisiejszy nie widzę powodu by zmieniać go na nowszy
XperiaS = 0,23MB/s
L5 II = 0,55MB/s - jak na swoje bebechy, działa bardzo fajnie
To tylko fizycznie kasuje rzeczy, które już wcześniej usunąłeś.
Edit: Udało się wrzucić apkę na kartę i działa, ale nie wiem tylko jeszcze co zaznaczyć spośród /system, /data i /cache. wszystko? Tak żeby mi nic nie wyczyściło
PS. Partycja /data, jak sie przelacze na SDCard to mi wywala przy testach...
Xperia S - oficjalny, najnowszy rom 4.1.2
Zapis losowy: 0,26 MB/s
Zapis ciągły: 6,14 MB/s
I teraz wiem dlaczego te wszystkie oficjalne romy soniacza taką małą responsywność mają.
Galaxy Gio - CM 7.2(android 2.3.7)
Zapis losowy: 0,41 MB/s
Zapis ciągły: 2,34 MB/s
Działa ciągle tak samo - nawet po wyciągnieciu z szuflady po długim czasie. Wiadomo demon szybkośc to to nie jest
Testów Xperii S zrootwanej nie wrzucę, bo jest dużo zabawy na tym najnowszym romie z tego co czytałem(nie działa stary, sprawdzony sposób- trzeba podmieniać kernel)
Chyba nie. Mi też padła pamięć wewnętrzna. Co do szybkości to CM+S1>>stock Samsung S3 4.1<x
PS. Partycja /data, jak sie przelacze na SDCard to mi wywala przy testach...
Musisz przejść do settings i zmienić File Size na coś większego. W przypadku tego testu ustawiłem obie wartości na 100 MB. Jak się ustawi za mało, to wszystko leci z bufora i daje to 'ciut' zawyżone wyniki
Najważniejsze z tego wszystkiego jest data, ale można zaznaczyć wszystko
Ten benchmark daje rozne wyniki, wiec nie wiem czy jest miarodajny.
Ten benchmark daje rozne wyniki, wiec nie wiem czy jest miarodajny.
Daje powtarzalne wyniki, jeśli zmienisz File Size na coś (dużo) większego, niż standard.
Najważniejsze z tego wszystkiego jest data, ale można zaznaczyć wszystko
Aplikacja sie uruchomiła, ale po kliknięciu Run wyskoczył jakiś komunikat o winie kernela lub czegoś innego i niestety nie poleciało, chyba jednak w moim przypadku nie zadziała.
Musisz przejść do settings i zmienić File Size na coś większego. W przypadku tego testu ustawiłem obie wartości na 100 MB. Jak się ustawi za mało, to wszystko leci z bufora i daje to 'ciut' zawyżone wyniki
Dzięki
Przy 200 MB RW=60,36...
Coś tu chyba dalej nie gra.
Ciągły odczyt: 30.93 MB/s
Ciągły zapis: 6.02 MB/s
Losowy odczyt: 9.04 MB/s
I najważniejsze, losowy zapis: 0.65 MB/s
ROM oczywiście z XDA, aktualizację robiłem jakieś 3 tygodnie temu. Chyba trim działa bo wyniki całkiem całkiem
No raczej tak, bo z tego co sprawdzałem to na Nexusie 5 powinno wyjść coś około 0,67 MB, a nie 67 MB, więc nie wiem o co chodzi Oo
Odczyt: 37,6MB/s
Zapis: 65,36MB/s
Losowy odczyt: 6.83MB/s
Losowy Zapis: 74,7 MB/s ???
Na starszym o 2 tygodnie romie miui miałem odczyt w okolicach 60MBs, zapis 6MBs, losowy odczyt ok 10MBs i losowy zapis 0.43MBs.
Mi2s 32GB.
###
Przy próbce 1GB losowy odczyt i zapis wynosi -2MB (minus)
zapis sekwencyjny: 8,51 MB/s
zapis losowy: 0,8 MB/s
Aplikacja LagFix nic nie zmieniła. Tak dla informacji podaję.
Artykuł bardzo dobry, dużo ludziom uświadamia. Powinien na głównej stronie Onetu wisieć przez tydzień.
Na tym tablecie wolałbym jednak nie wygrywać roota bo pozniej mogę nie wygrać pełnej wersji systemu i stracę gwarancję.
Na ZTE grand x in tez jest lipa z tym zapisem bo tylko 0.2mb dobrze że android jest czysty to da się jakoś z tego telefonu korzystać ale i tak nie ma żadnych romów na ten telefon, jest tylko jeden ale mało znaczący praktycznie nie robi to różnicy.
Ha, i w sumie wiadomo, czemu to tak muli. Dziwne, bo na 2.3.6 aceII działał znośnie.
@up
To prawda, użerałem się z GXI jakieś 4 miesiące i telefon zawsze działał bardzo sprawnie. Niestety ten zabugowany soft...
http://www.anandtech.com/show/7235/moto-x-review/9
Szkoda, że mój iPhone 5 chodzi ciągle tak samo. :/
Ale i tak zostane 'zjechany' że przepłaciłem itp
Zapis Losowy 1.12 MB/s wyszło
W ACE 2 są fatalne pamięci. Tłumaczę to pacanom z android.com.pl, a oni dalej uważają, że za zamulanie w tym modelu odpowiada soft.
W ACE 2 są fatalne pamięci. Tłumaczę to pacanom z android.com.pl, a oni dalej uważają, że za zamulanie w tym modelu odpowiada soft.
[img]http://pclab.pl/zdjecia/artykuly/miekrzy/q...ndrorw.png[/img
[img]http://pclab.pl/zdjecia/artykuly/miekrzy/q...ndrosw.png[/img
Im niestety wiele rzeczy trzeba tłumaczyć, często brak odpowiedzi a jak są to przeważnie od chamskich moderatorów którzy tylko potrafią przysłowiowo opie^$%$% za to że ktoś napisał nie w tym dziale ale podbił temat w którym nie było odpowiedzi od kilku dni, dokładnie mam namyśli dział samsunga bo na dziale Sony jest bardzo przyjemnie
Xperia S - oficjalny, najnowszy rom 4.1.2
Zapis losowy: 0,26 MB/s
Zapis ciągły: 6,14 MB/s
I teraz wiem dlaczego te wszystkie oficjalne romy soniacza taką małą responsywność mają.
Galaxy Gio - CM 7.2(android 2.3.7)
Zapis losowy: 0,41 MB/s
Zapis ciągły: 2,34 MB/s
Działa ciągle tak samo - nawet po wyciągnieciu z szuflady po długim czasie. Wiadomo demon szybkośc to to nie jest
Testów Xperii S zrootwanej nie wrzucę, bo jest dużo zabawy na tym najnowszym romie z tego co czytałem(nie działa stary, sprawdzony sposób- trzeba podmieniać kernel)
Ja ma SXS zrootowane i w tym przypadku Lagfix nie dał nic - i przed i po zapis losowy 0,22MB/s. ten typ tak ma (znaczy słabą pamięć).
http://www.anandtech.com/show/7235/moto-x-review/9
SR - 74,27 MB/s
SW - 22,22 MB/s
RR - 13,64 MB/s (3493 IOPS)
RW - 2,09 MB/s (536 IOPS)
Jakiejś rewelacji nie ma, ale może fakt, że zostało mi jedynie 3 GB z 30 ma na to swój wpływ. Ciekawi mnie czy te wyniki podane wyżej rzędu 0,2 -0,3 MB/s to w miarę rzeczywiste są? Bo wydaje się to być okropnie mało, nie spodziewałbym się wyników jak w klasycznych SSD rzędu kilkudziesięciu MB/s, ale takie ułamki?
SR - 41,17 MB/s
SW - 92,44 MB/s
RR - 6,95 MB/s 1779,98 IOPS (4K)
RW - 87,1 MB/s 22298,92 IOPS (4K)
Jednak chińszczyzna jest czasami lepsza od szajsunga :-/
'W przypadku klasycznych dysków talerzowych, gdy się kasuje jakiś plik, to nie jest on fizycznie wymazywany z nośnika, ale po prostu system zaznacza sobie, że zajmowane przez niego wcześniej miejsce można ponownie wykorzystać i nowe dane są „nadpisywane” na pozostałości starych bez jakiejkolwiek straty wydajności.'
Chyba każdy zauważył jak świeżo zainstalowany Windows,czy to 7 czy xp uruchamia się błyskawicznie,a po pewnym czasie ten czas się drastycznie wydłuża. Nie wspominając także o działaniu także samego systemu już po załadowaniu. Przecież chyba nie każdy Mac miał zawsze dysk ssd? Wydaje mi się że to nadpisywanie danych na zwykłym talerzowym dysku jest sporo wolniejsze niż 'pisanie' na czysto,i podobnie jak w ssd powinno dać się coś z tym zrobić,fizycznie wymazać. Proszę o jakieś wyjaśnienie
po drugie nie toleruja małych plików co dodatkowo wydłuza czas dostepu
no i sam czas dostępu który jest bardzo długi w przypadku hdd
kasowac danych na bierzaco nie trzeba - naprawdę to kompletnie nic nie zmienia w przypadku hdd
xperia u - zapchana (50mb wolnego) na oficjalnym 2.3.7 i muł jak cholera
na ustawieniach def:
SR - 26,38 MB/s / 27.21 MB/s / 26.3 MB/s
SW - 2.66 MB/s / 5.7 MB/s / 8.45 MB/s
RR - 8.26 MB/s; 2114 IOPS / 9.0 MB/s; 2305 IOPS / 9.24 MB/s; 2365 IOPS
RW - 0.21 MB/s; 54 IOPS / 0.22 MB/s; 58 IOPS / 0.23 MB/s; 60 IOPS
tak to wyglada po 3 testach w odstępie 5 minut miedzy testami
dla próbki 100MB (zapis i odczyt)
SR - 26.04 MB/s
SW - 3.27 MB/s
RR - 8.7 MB/s; 2227 IOPS
RW - 0.26 MB/s; 67 IOPS
wyglada na to ze puszczę jeszcze z 5 razy i żaden trim mi potrzebny nie będzie !
(chociaz tej padlinie i tak nic nie pomoże - muli jak mulił i mulic będzie i własnie tu jest olbrzymia wina androida który ma zwyczajnie źle ponadawane priorytety)
SR - 41,17 MB/s
SW - 92,44 MB/s
RR - 6,95 MB/s 1779,98 IOPS (4K)
RW - 87,1 MB/s 22298,92 IOPS (4K)
Jednak chińszczyzna jest czasami lepsza od szajsunga :-/
Dynamiczny FSync z micore pokazuje bzdury, to nie są prawdziwe wyniki. Jeśli komuś zapis losowy wychodzi w takich liczbach to właśne przez fsync i test w ramie.
'W przypadku klasycznych dysków talerzowych, gdy się kasuje jakiś plik, to nie jest on fizycznie wymazywany z nośnika, ale po prostu system zaznacza sobie, że zajmowane przez niego wcześniej miejsce można ponownie wykorzystać i nowe dane są „nadpisywane” na pozostałości starych bez jakiejkolwiek straty wydajności.'
Chyba każdy zauważył jak świeżo zainstalowany Windows,czy to 7 czy xp uruchamia się błyskawicznie,a po pewnym czasie ten czas się drastycznie wydłuża. Nie wspominając także o działaniu także samego systemu już po załadowaniu. Przecież chyba nie każdy Mac miał zawsze dysk ssd? Wydaje mi się że to nadpisywanie danych na zwykłym talerzowym dysku jest sporo wolniejsze niż 'pisanie' na czysto,i podobnie jak w ssd powinno dać się coś z tym zrobić,fizycznie wymazać. Proszę o jakieś wyjaśnienie
Nie występuje w windows-ach, bo tam TRIM jest od dawna...
Występuje w Mac-ach, czy iOS-ach, zwłaszcza iOS7, który muli..., OSX to system bardzo, bardzo zardzewiały, ratują go sterowniki pod 'ten' konkretny sprzęt, które są dopracowane vs energooszczędność.
HDD tego problemu nie ma. Nadpisywanie danych jest równie szybkie co pisanie na czysto.
Windows dłużej się wczytuje, zwalnia responsywność systemu bo...
W przypadku HDD masz inną prędkość odczytu na zew/wewnątznej częsci talerza, wraz z z zapełnianiem dysku transfery będą maleć.
W przypadku SSD i HDD dłużej, bo system się z czasem uszkadza i działają mechanizmy naprawy/sprawdzania, bądź gorzej gdy nie działają i są błędy.
W przypadku SSD/HDD dłużej, bo użytkownicy wgrywają masę syfu, który zostawia nawet po odinstalowaniu syf...
Aktualizacje, które czasem psują stabilność i szybkość działania.
akurat tam gdzie i transfer i czas dostępu jest najszybszy
Ja mam trochę paranoiczne podejście i 100% stabilności ma być- komp ma działać miesiącami 100% stabilnie... jak system działa to go nie ruszam, nie pozwalam go ruszać aktualizacjom. Wgrywam pakiety SP w ostateczności, bo po prostu wolę wgrać na nowo system niż mieć bluscreen-a, który być nie powinin.
MS jest firmą, której nie ufam. Ileż to razy wyszła łatka, łatki, która naprawiała to co poprzednia łatka zrobiła.
Xperia S - oficjalny, najnowszy rom 4.1.2
Zapis losowy: 0,26 MB/s
Zapis ciągły: 6,14 MB/s
I teraz wiem dlaczego te wszystkie oficjalne romy soniacza taką małą responsywność mają.
Galaxy Gio - CM 7.2(android 2.3.7)
Zapis losowy: 0,41 MB/s
Zapis ciągły: 2,34 MB/s
Działa ciągle tak samo - nawet po wyciągnieciu z szuflady po długim czasie. Wiadomo demon szybkośc to to nie jest
Testów Xperii S zrootwanej nie wrzucę, bo jest dużo zabawy na tym najnowszym romie z tego co czytałem(nie działa stary, sprawdzony sposób- trzeba podmieniać kernel)
Ja ma SXS zrootowane i w tym przypadku Lagfix nie dał nic - i przed i po zapis losowy 0,22MB/s. ten typ tak ma (znaczy słabą pamięć).
Teraz to panie mówisz, jak ja go pół nocy rootowałem
Ja mam trochę paranoiczne podejście i 100% stabilności ma być- komp ma działać miesiącami 100% stabilnie... jak system działa to go nie ruszam, nie pozwalam go ruszać aktualizacjom. Wgrywam pakiety SP w ostateczności, bo po prostu wolę wgrać na nowo system niż mieć bluscreen-a, który być nie powinin.
MS jest firmą, której nie ufam. Ileż to razy wyszła łatka, łatki, która naprawiała to co poprzednia łatka zrobiła.
Biorąc pod uwagę, że spora część aktualizacji to łatanie różnych dziur bezpieczeństwa to nie wiem czy to najmądrzejsze rozwiązanie.
Ja mam trochę paranoiczne podejście i 100% stabilności ma być- komp ma działać miesiącami 100% stabilnie... jak system działa to go nie ruszam, nie pozwalam go ruszać aktualizacjom. Wgrywam pakiety SP w ostateczności, bo po prostu wolę wgrać na nowo system niż mieć bluscreen-a, który być nie powinin.
MS jest firmą, której nie ufam. Ileż to razy wyszła łatka, łatki, która naprawiała to co poprzednia łatka zrobiła.
Popieram. Ja wgrywam tylko service packi ale na 'czysto'. Integruje SP+najważniejsze aktualizacje z obrazem instalacyjnym i robię nową instalację, po czym od razu wyłączam wszelkie automatyczne aktualizacje. Robię tak zawsze przed Świętami Bożego Narodzenia. Efekt to zero śmieci i żwawy system.
Ja mam włączone automatyczne aktualizacje. Efekt ten sam.
W ACE 2 są fatalne pamięci. Tłumaczę to pacanom z android.com.pl, a oni dalej uważają, że za zamulanie w tym modelu odpowiada soft.
Kolego co to za wyniki? Mam SGS2, właśnie zrobiłem testy i otrzymałem 2x lepsze wyniki:
Sequential Read: 45,4 MB/s
Sequential Write: 14,5 MB/s
Random Read: 11,4 MB/s
Random Write: 0,6 MB/s
Dodam, że program LagFix na moim telefonie nie działa.
@up
Różne ROM'y, różne ustawienia programu testującego itd.
Różne ROM'y, różne ustawienia programu testującego itd.
A oprócz tego różne serie popularnych smartfonów korzystały z różnych pamięci flash i czasem się dostawało niezłą, a czasem trupa.
akurat tam gdzie i transfer i czas dostępu jest najszybszy
Bez przesady. Ukryta partycja zajmuje kilkanaście GB. Przy dyskach wielkości minimum 500GB to nie tak dużo znowu. Ale ja i tak usuwam tę partycję i instaluję czystego windowsa bez tych różnych śmieci dołączonych przez producenta.
Bez przesady. Ukryta partycja zajmuje kilkanaście GB. Przy dyskach wielkości minimum 500GB to nie tak dużo znowu. Ale ja i tak usuwam tę partycję i instaluję czystego windowsa bez tych różnych śmieci dołączonych przez producenta.
Wiesz różne dziwne rzeczy widziałem - szczególnie na sprzęcie z win8 - tam już niezła sieczka na dysku
generalnie tez wolę sam ogarnąć ale nie zawsze jest taka mozliwość
zawsze mozna zweryfikowac wplyw takich podziałów choćby za pomoca hd tune
SR - 41,17 MB/s
SW - 92,44 MB/s
RR - 6,95 MB/s 1779,98 IOPS (4K)
RW - 87,1 MB/s 22298,92 IOPS (4K)
Jednak chińszczyzna jest czasami lepsza od szajsunga :-/
Dynamiczny FSync z micore pokazuje bzdury, to nie są prawdziwe wyniki. Jeśli komuś zapis losowy wychodzi w takich liczbach to właśne przez fsync i test w ramie.
Testowałem kilkukrotnie i to jest jeden z mniejszych wyników. Najczęściej i najwięcej zmienia się wartość RW. Ale to prawda micore jest zmienny i w fazie testów. Podobno płynniejszy
SR: 44.3 MB/s
SW: 7,1 MB/s
RR: 12,4 MB/s
RW: 0,71 MB/s
Uruchomienie programu LagFix nie poprawilo wynikow, wiec pewnie discardowanie dziala w porzadku.
próbka 100MB
SR: 77.1 MB/s
SW: 13.42 MB/s
RR: 13,8 MB/s
RW: 1,15 MB/s
Wolne 3,5gb z 9,27
RW 1.47MB/s
Chciałbym przypomnieć posiadaczom smartfonów z Androidem 4.4 oraz 4.4.2 (cyanogenmod 11), że mają możliwość zmienienia środowiska otwierania aplikacji. Jak na razie nie jest to jeszcze wspierane oficjalnie przez Androida, lecz z tego co mi wiadomo powinno się to stać za niedługo. A więc. O co chodzi. Aby uruchomić aplikacje na androidzie musiał on ją uruchomić w witrualnej maszynie 'Dalvik', lecz po zmienieniu jednej prostej rzeczy nasze aplikacje są uruchamiane 'na bieżąco' (jak w iOs'ie). Drastycznie zwiększa to prędkość całego telefonu, ale coś za coś, jeszcze nie wszystkie aplikacje wspierają to środowisko pracy (nazywa sie ono 'ART"
Jak uruchomić?
Robicie na własną odpowiedzialność(lecz nie znam osoby której by coś nie działało). Pierwsze uruchomienie może troszkę potrwać ale efekt jest świetny!
Wchodzimy w ustawienia-> Opcje Programistyczne( jeżeli nie mamy takiej ikonki lub jet niedostępna to wchodzimy w informacje o telefonie i klikamy parenaście razy 'numer kompilacji' ) ->Wybierz czas wykonania -> Użyj ART
Pozdrawiam! I życzę wesołego Nowego Roku
W ACE 2 są fatalne pamięci. Tłumaczę to pacanom z android.com.pl, a oni dalej uważają, że za zamulanie w tym modelu odpowiada soft.
Kolego co to za wyniki? Mam SGS2, właśnie zrobiłem testy i otrzymałem 2x lepsze wyniki:
Sequential Read: 45,4 MB/s
Sequential Write: 14,5 MB/s
Random Read: 11,4 MB/s
Random Write: 0,6 MB/s
Dodam, że program LagFix na moim telefonie nie działa.
Kolego, wszystko zależy od egzemplarza, mimo że ten sam model. Mam w domu dwie sztuki ACE 2. Pierwszy z kwietnia, drugi z grudnia tego roku. W przypadku pierwszego, losowy zapis na poziomie 0,15, a drugiego 0,40. Przypuszczam, że w późniejszym czasie zaczęli montować lepsze pamięci, bo zwyczajnie skończyły im się leżaki magazynowe.
Między innymi dlatego, jednym ''zamula'' 4.1.2, a drugim chodzi w miarę płynnie na tym telefonie.
Różne ROM'y, różne ustawienia programu testującego itd.
A oprócz tego różne serie popularnych smartfonów korzystały z różnych pamięci flash i czasem się dostawało niezłą, a czasem trupa.
Dokładnie.
Dynamiczny FSync z micore pokazuje bzdury, to nie są prawdziwe wyniki. Jeśli komuś zapis losowy wychodzi w takich liczbach to właśne przez fsync i test w ramie.
Testowałem kilkukrotnie i to jest jeden z mniejszych wyników. Najczęściej i najwięcej zmienia się wartość RW. Ale to prawda micore jest zmienny i w fazie testów. Podobno płynniejszy
Z micore robi się z tego test RAMu.
I tobie też... nie miałe mczasu w google a tu porada sama przyszła.
Htc One, zapiernicza wszystko jak złe.
Spełnieeeeeeeeeeeeeeeeeeeeeeeeeeenia wszystkich noworocznych marzeń !!!!!!!!!!!!!!!
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Pamięci z 'Samsung eMMC secure erase bug' również są wrażliwe na TRIM.
http://forum.xda-developers.com/showthread.php?t=1644364
SEQ RD 29.42MB/s
SEQ Wrt 5.94MB/s
RD RD 7.99 MB/s 2046IOPS
RD WRT 0.27MB/s 77IOPS
No cóz.... =D
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Pamięci z 'Samsung eMMC secure erase bug' również są wrażliwe na TRIM.
http://forum.xda-developers.com/showthread.php?t=1644364
a po użyciu - 1 - test - 0,76MB/s , 2 - test - 0,36MB/s. Więc coś jest nie tak.
Bzdura, kasując aplikację z Android-a kasujesz też wszelkie dane aplikacji. Dokładnie tak samo działa iOS. Nawet obie platformy używają tej samej metody kompresji aplikacji jeśli dobrze pamiętam.
Oczywiście iOS też mulił gdy masz zajętą całą pamięć i setki apek...
Rozwiązanie Apple ma natomiast sporo wad. iOS7 muli, pobiera sporo energii stresie. Jest mniej płynny aplikacje działają z prędkością 30FPSów (domyślny limit Apple), gdy Android ma 60.
Pamięć w tym telefonie to padaka z natury widocznie
Jest o tyle lepiej w porównaniu z innymi, że wyniki są powtarzalne. 5 testów prawie pod rząd dało różnice rzędu 0.02 MB/s.
Nie wiem jak jest, ale telefon od pół roku nie zwolnił a wyżej wrzuciłem ss z benchmarku.
LG Swift L3 II Dual, E435 (Android 4.1.2, jądro 3.4.0, wersja opr. E43510a-EUR-XX):
SR: 36.31 MB/s
SW: 14.98 MB/s
RR: 8.86 MB/s, 2270 IOPS(4K)
RW: 0.7 MB/s, 181.16 IOPS(4K)
bo po prostu dobrze w nim działa podsystem Flash!
Wybierz taki, który ma najlepsze wsparcie CM-a. Samsungi nie mają blokady bootloader-a, LG chyba też.
HTC Desire 300 (Android 4.1.2, HTC Sense 5.0, HTC SDK 5.26, wersja opr. 1.10.401.4):
SR 29.4 MB/s
SW: 5.5 MB/s
RR: 7.32 MB/s, 1875.5 IOPS(4K)
RW: 0.22 MB/s, 58.1 IOPS(4K)
ale mimo to nie muli... jeszcze.
SR - 74,27 MB/s
SW - 22,22 MB/s
RR - 13,64 MB/s (3493 IOPS)
RW - 2,09 MB/s (536 IOPS)
Jakiejś rewelacji nie ma, ale może fakt, że zostało mi jedynie 3 GB z 30 ma na to swój wpływ. Ciekawi mnie czy te wyniki podane wyżej rzędu 0,2 -0,3 MB/s to w miarę rzeczywiste są? Bo wydaje się to być okropnie mało, nie spodziewałbym się wyników jak w klasycznych SSD rzędu kilkudziesięciu MB/s, ale takie ułamki?
Jednakze ja nim nie trzymam filmow ani zdjec , jak i nie mam tony apek .
Czyli u większości użytkowników i nie sądzę aby telefon od każdego operatora dostał ostatnią aktualizację z tym związaną. Powinieneś ostrzegać przed takimi konsekwencjami stosowania Twoich rad bo koszty wymian telefonów użytkowników jakie poniesie PCLab mogą być spore.
Po drugie, ta apka już od dłuższego czasu ma wbudowaną listę kompatybilności i nie da się jej pobrać z PS na „psujących” się urządzeniach.
Z resztą poszedłem do pubu. Zresztą poszedłem po rozum do głowy...
Nadużywasz tego pierwszego 'z resztą' w złym kontekście.
PS
Dzięki za ciekawy tekst.
Jeszcze pozostało rozwiązać zagadkę strasznie wysokich wyników w zapisie losowym w niektórych przypadkach.
Pozdro
LG F5 Androif 4.1.3
Zapis losowy przed 0,48MB po LagFix-ie 1,18MB
Po drugie, ta apka już od dłuższego czasu ma wbudowaną listę kompatybilności i nie da się jej pobrać z PS na „psujących” się urządzeniach.
Dobrze byłoby zdefiniować pojęcie: 'Zwykły' użytkownik.
Bo np. ja mam roota, czasem grzebię w systemie, jednak mam najświeższą wersję oryginalnego romu, czyli 2.3.6 w moim Galaxy S Plus. A wersja ta ma, delikatnie rzecz ujmując, więcej niż rok.
Kolego slawex1983
Proszę nauczyć się czytać ze zrozumieniem. Na wykresach chodzi o Samsung Galaxy Ace 2 a nie o SGS2
ps. oczywiście skorzystałem z komendy mount
Po drugie, ta apka już od dłuższego czasu ma wbudowaną listę kompatybilności i nie da się jej pobrać z PS na „psujących” się urządzeniach.
Dobrze byłoby zdefiniować pojęcie: 'Zwykły' użytkownik.
Bo np. ja mam roota, czasem grzebię w systemie, jednak mam najświeższą wersję oryginalnego romu, czyli 2.3.6 w moim Galaxy S Plus. A wersja ta ma, delikatnie rzecz ujmując, więcej niż rok.
Kolego slawex1983
Proszę nauczyć się czytać ze zrozumieniem. Na wykresach chodzi o Samsung Galaxy Ace 2 a nie o SGS2
Na czwartej pozycji od góry jak byk stoi SGS2. Pytałem skąd tak duża rozbieżność wyników i otrzymałem sensowną odpowiedź. Pozdrawiam
Nie widzę ciągu logicznego.
Mnie po wpisaniu: adb shell wyskakuje: 'device not found'
Wpisuje: adb shell mount to wyskakują informacje jak wykorzystać komendę adb.
Chyba robię coś nie tak. Debugowanie włączone oczywiście. Trzeba mieć roota do tego ?
Edit: Doczytałem że jak nie jest widoczna ta aplikacja w sklepie google to Trim w nic nie da.
Mam zaktualizowany do 4.3 czyli najnowszego ale ostatnio mocno zwolnił mi telefon (tzn czasami jakby przycina). Szukałem informacji, trafiłem tutaj i wydaje mi się, że problemem jest to co opisałeś w artykule. Szkoda, że nie mogę zrobić roota i użyć tego programu
Czy znasz jakieś inne bezpieczne metody?
SEQ Read: ~148MB/s
SEQ Write: ~38MB/s
RDM Read: 12.88MB/s
RDM Write: 3.72MB/s
Wersja telefonu 32GB, zajęte 6.5GB, stock. Soft przywracany do ustawień fabrycznych 2 miesiące temu. Zmiana z 64MB na 100MB nie przyniosła zbyt dużej rozbieżności wyników, raptem kilka MB w tył w SEQ Read i Write.