Related
So everyone (including me) has noticed that the transformer slows down when doing i/o. I originally thought this was a hardware issue (slow memory? slow bus?) but from various threads it sounds like third party os fix the issue. So I have two questions:
Can someone explain what the asus kernel does wrong (or how third party kernels) fix the issue ?
Why asus cannot copy the fixes from third party kernels into their kernel (I presume this is a kernel issue and not support software around the kernel but maybe that presumption is incorrect; maybe it is a driver issue or maybe there really is a hardware issue?)
jake21 said:
So everyone (including me) has noticed that the transformer slows down when doing i/o. I originally thought this was a hardware issue (slow memory? slow bus?)
Click to expand...
Click to collapse
Random write of small blocks to the internal eMMC is slow. Flash memory has huge erase blocks (typically a couple of megabytes) and large write blocks. Writing 4KB is a relatively slow process.
jake21 said:
but from various threads it sounds like third party os fix the issue.
Click to expand...
Click to collapse
They can't fix it, they can only work around the issue by tweaking the kernel's caching parameters. Or, in the extreme case, disabling the fsync system call. Usually, an application calls fsync to ensure data has been written to the disk, so that even in case of a following crash or unexpected power loss the data on the medium is consistent. And normally fsync waits until the write command has completed. If you disable fsync, the app no longer has to wait, therefore no more lag. The data still resides in the RAM and is eventually written to the card by the background cache flush thread.
Downside of disabling fsync: If the tablet crashes in the wrong moment, you may in the worst case lose all your data, run into a bootloop, etc.
If this is true, how come with original release ICS 4.0.3 everything runs smooth and fast. I installed latest Jelly Bean 4.1 and slow real bad, i downgraded back to ICS 4.03 and it is fast again. Is it a driver issue. It can't be hardware.
Thanks
_that said:
Random write of small blocks to the internal eMMC is slow. Flash memory has huge erase blocks (typically a couple of megabytes) and large write blocks. Writing 4KB is a relatively slow process.
They can't fix it, they can only work around the issue by tweaking the kernel's caching parameters. Or, in the extreme case, disabling the fsync system call. Usually, an application calls fsync to ensure data has been written to the disk, so that even in case of a following crash or unexpected power loss the data on the medium is consistent. And normally fsync waits until the write command has completed. If you disable fsync, the app no longer has to wait, therefore no more lag. The data still resides in the RAM and is eventually written to the card by the background cache flush thread.
Downside of disabling fsync: If the tablet crashes in the wrong moment, you may in the worst case lose all your data, run into a bootloop, etc.
Click to expand...
Click to collapse
Ok I can understand the issue with fsync and small writes but then all tablets would have this issue (unless the infinity used particularly poor chioce of hardware). Also does this indicate if writes were disabled in (for example) browsers then they would be silky smooth ?
-
It would be nice if the tablet could mark certain directories as critical and flush those faster than other directories (perhaps abusing the meaning of the sticky bit on the directory). Certain non critical data can avoid having immediate flush (though if andriod apps are calling fsync explicitly there might be some stickyness in changing the behavior of the api). Anyways is my understanding correct that you are indicating that Asus used a particularly poor choice of eMMC or tweaked the kernel to flush more frequently ?
_that said:
Random write of small blocks to the internal eMMC is slow. Flash memory has huge erase blocks (typically a couple of megabytes) and large write blocks. Writing 4KB is a relatively slow process.
They can't fix it, they can only work around the issue by tweaking the kernel's caching parameters. Or, in the extreme case, disabling the fsync system call. Usually, an application calls fsync to ensure data has been written to the disk, so that even in case of a following crash or unexpected power loss the data on the medium is consistent. And normally fsync waits until the write command has completed. If you disable fsync, the app no longer has to wait, therefore no more lag. The data still resides in the RAM and is eventually written to the card by the background cache flush thread.
Downside of disabling fsync: If the tablet crashes in the wrong moment, you may in the worst case lose all your data, run into a bootloop, etc.
Click to expand...
Click to collapse
gordo2000 said:
If this is true, how come with original release ICS 4.0.3 everything runs smooth and fast. I installed latest Jelly Bean 4.1 and slow real bad, i downgraded back to ICS 4.03 and it is fast again. Is it a driver issue. It can't be hardware.
Click to expand...
Click to collapse
I didn't see a big performance difference between ICS and JB, even though JB should be even faster after all the "Project Butter" work. What is slow for you on JB?
---------- Post added at 07:35 PM ---------- Previous post was at 07:30 PM ----------
jake21 said:
Ok I can understand the issue with fsync and small writes but then all tablets would have this issue (unless the infinity used particularly poor chioce of hardware). Also does this indicate if writes were disabled in (for example) browsers then they would be silky smooth ?
Click to expand...
Click to collapse
Many people said the TF700's eMMC is slower than good microSD cards, and that can be reproduced with benchmarks.
To check how the browser performs if it doesn't have to write to the eMMC, install Browser2RAM, which moves the browser cache to a ramdisk. In my experience, there is still lag on some pages - so not all slowdowns seem to be I/O-related. It would be interesting to find out the real cause of this.
There may be another I/O situation except random writes: large writes which block small reads from another process. HPI should help here, but I think the 3.1 kernel doesn't support it yet.
_that said:
I didn't see a big performance difference between ICS and JB, even though JB should be even faster after all the "Project Butter" work. What is slow for you on JB?
---------- Post added at 07:35 PM ---------- Previous post was at 07:30 PM ----------
Many people said the TF700's eMMC is slower than good microSD cards, and that can be reproduced with benchmarks.
To check how the browser performs if it doesn't have to write to the eMMC, install Browser2RAM, which moves the browser cache to a ramdisk. In my experience, there is still lag on some pages - so not all slowdowns seem to be I/O-related. It would be interesting to find out the real cause of this.
There may be another I/O situation except random writes: large writes which block small reads from another process. HPI should help here, but I think the 3.1 kernel doesn't support it yet.
Click to expand...
Click to collapse
Agreed. However, even with Browser2Ram, I'm betting that there is still some i/o with the emmc that cannot be hijacked by broser2ram, and therein lies the problem. If nothing else, using RAM like that may force the tablet (b/c of screwy coding) to start paging data to...yup, you guessed it, emmc ... a lot sooner than it actually needs to.
Has anyone tried B2R along with dev settings to kill apps ASAP that are not in use? Perhaps this could lengthen the time before paging starts to occur?
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
Overall, everything runs smooth on ICS 4.0.3. Browser, opening app, games, there is no hick ups when watching movies, that happen alot on JB 4.1.1. The whole OS is smoth redrawing. On JB, there is always a wait few seconds to open application folders or closing it. I did reformat to default but no help.
_that said:
I didn't see a big performance difference between ICS and JB, even though JB should be even faster after all the "Project Butter" work. What is slow for you on JB?
---------- Post added at 07:35 PM ---------- Previous post was at 07:30 PM ----------
Many people said the TF700's eMMC is slower than good microSD cards, and that can be reproduced with benchmarks.
To check how the browser performs if it doesn't have to write to the eMMC, install Browser2RAM, which moves the browser cache to a ramdisk. In my experience, there is still lag on some pages - so not all slowdowns seem to be I/O-related. It would be interesting to find out the real cause of this.
There may be another I/O situation except random writes: large writes which block small reads from another process. HPI should help here, but I think the 3.1 kernel doesn't support it yet.
Click to expand...
Click to collapse
johnlgalt said:
Agreed. However, even with Browser2Ram, I'm betting that there is still some i/o with the emmc that cannot be hijacked by broser2ram, and therein lies the problem.
Click to expand...
Click to collapse
Not all I/O automatically leads to problems. The latest version of Browser2RAM only redirects the browser cache, it does not affect browser settings, bookmarks, etc. - which is usually a good thing.
johnlgalt said:
If nothing else, using RAM like that may force the tablet (b/c of screwy coding) to start paging data to...yup, you guessed it, emmc ... a lot sooner than it actually needs to.
Click to expand...
Click to collapse
No. Paging does not occur *to* the eMMC (no swap space is configured on the TF700), but only *from* the eMMC, to fetch pages of executable files. While it is true that the ramdisk for the cache uses some memory, it would only make a difference if you have lots of background apps competing for RAM.
A first step to see how much I/O happens is to watch the output of "iostat".
Thanks for the heads up. So, why does it still cause pauses and the like then?
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
johnlgalt said:
So, why does it still cause pauses and the like then?
Click to expand...
Click to collapse
Good question. It's time to find out.
Arm yourself with multiple adb shells and watch the output of iostat, top, free, or whatever else you can think of that displays interesting metrics. Then do something that causes lag and see if you notice a specific pattern.
(I am currently away from my main PC, and the SSD in my laptop decided yesterday it no longer wants to read ntkrnlpa.exe - so no adb for me right now)
I'll need a bit more specifics - I know adb well enough and can shell, but these other ... executables you're mentioning are new to me.
I'm on vacation in Hawaii, and have a Windows 7 based laptop that I can use, so I can do this no problem - but not today. About to go see some sights before going on a Lava Boat tour at 4 PM local, which means I'll be bushed when I get back - plus I'm fighting a nasty ear infection that aches something awful.
AFAIK, though, I have no real plans for tomorrow or Friday, so I can take some time and investigate.
Also, FWIW: I'm rooted but have not (yet) unlocked my bootloader - mainly b/c I purchased the 64 GB version of the tablet and it is a C50, so I'm hoping something 'breaks' enough for me to get a replacement (c70? C90 even? )- and hoping even more that it is running something under ICS .30 so I can nvflash a backup and not have to worry about goofing things up when I *do* unlock the bootloader.
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
iostat and top are standard unix utilities. They would only be useful if run on the phone so I must presume andriod has versions. A bit of 'googling' and htere appears to be a developer's kit that includes stuff like iostat. If hte switches are the norm then something like "iostat -x 2" will produce nice output of performance of each 'disk'. top is a tool that shows cpu usage.
-
I've not done any developing for andriod (maybe I should bite hte bullet?) so have never tried to use adb or similar but i've done a bit of system development on linux (though I very rarely muck with the kernel; i prefer to work one layer above the kernel).
johnlgalt said:
I'll need a bit more specifics - I know adb well enough and can shell, but these other ... executables you're mentioning are new to me.
Click to expand...
Click to collapse
If you haven't done it yet, install BusyBox on your TF700. Then just open one or more command windows on your PC, run adb shell in each, and run "iostat 1" in one window, "top" in another, and maybe also adb logcat in yet another window.
That gives you up-to-date statistics about I/O and processes which currently use CPU time. Then try to use your tablet normally, and when it lags, watch the output on your PC if you see a big number of writes or a process eating CPU.
But don't forget to enjoy your vacation.
_that said:
If you haven't done it yet, install BusyBox on your TF700. Then just open one or more command windows on your PC, run adb shell in each, and run "iostat 1" in one window, "top" in another, and maybe also adb logcat in yet another window.
That gives you up-to-date statistics about I/O and processes which currently use CPU time. Then try to use your tablet normally, and when it lags, watch the output on your PC if you see a big number of writes or a process eating CPU.
But don't forget to enjoy your vacation.
Click to expand...
Click to collapse
Awesome. Busybox already installed here, so this should be easy enough.
And I never forget to enjoy ... anything. lol
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk
_that said:
Good question. It's time to find out.
Arm yourself with multiple adb shells and watch the output of iostat, top, free, or whatever else you can think of that displays interesting metrics. Then do something that causes lag and see if you notice a specific pattern.
(I am currently away from my main PC, and the SSD in my laptop decided yesterday it no longer wants to read ntkrnlpa.exe - so no adb for me right now)
Click to expand...
Click to collapse
hey fellas, have you seen chainfire's app : PerfMon
http://www.xda-developers.com/android/perfmon-floats-your-devices-performance-on-screen/
real time stats including io reads/writes to both mmcblk0/mmcblk1... :good:
ps: i have always loved "android status" aswell ... oldy but a goody
https://play.google.com/store/apps/details?id=com.AndroidStatus&hl=en
I have several Android tablets running the Rockchip 3066 processor.
I have tried all of the torrent clients available on Google Play, and find that while downloading files it really bogs down the whole tablet's resources. So much so, that you pretty much can't do anything else.
Very little is written about this problem, but I'm curious if there are any ROM tweaks available to eliminate this performance hit caused from running a torrent client. If so, I want to adjust the ROM'S I'm cooking for the Yuandao tablets.
All of my devices are very speedy....except when downloading torrents.
Randy
If it's only while downloading, then it could be a bandwidth issue. You could run Android's built-in firewall to limit the connection speed.
If it's the apps suck all the processing power available, then yeah, you'd probably have to adjust some code in your ROM... which I can't help you with.
It is the latter, because it doesn't really matter what the download speed is...it just sucks all the CPU power.
As soon as the download is done, everything speeds back up.
It all made sense until...
rrileypm said:
As soon as the download is done, everything speeds back up.
Click to expand...
Click to collapse
I still think it is twodayportedapp fault. With uTorrent, my device is totally bogged even when it is downloading slower than 1kb/s
I would like to find an android friendly torrent client, since remote just doesn`t cut it for me. Heck, I would make my tablet the only device running 24/7 at home (the refrigerator is not running round clock, you know )
Every torrent application will lag your phone/table it you're downloading to your primary SD Card. This is becase Androids needs to preallocate the full size of the downloaded files. So when Android zero filles 2Gb of files, then the read/write speed for other applications on the internal storage will drop, thus you'll get a lot of lag. Once the preallocation is over the phone comes back to live again (that is if you're not downloading with +10Mb/s speed of more).
Only way to avoid the lag is to have an external SD Card and download to it. BTW you can try my new torrent application TDM. Maybe it'll suit your needs better? (it has no problems with downloading to extarnal cards and it has a file manager to allowes you to manage the file on multiple cards with ease).
I am using -t torrent - in my gt-s5570i phone that have 800 mh CPU speed and it s working great on it try it
Sent from my EBM8000ND using xda app-developers app
After I do a fresh install of cromi on my tablet, it's just excellent, fluid and smooth. After a while, the performance seems to detoriate. It has done so for about every version I tried and the same goes for my phone (An i9300 running slimkat). So my question is this: What makes an android device inherently slower? Is there a way to see what apps may slow down the performance?
vonVaffel said:
After I do a fresh install of cromi on my tablet, it's just excellent, fluid and smooth. After a while, the performance seems to detoriate. It has done so for about every version I tried and the same goes for my phone (An i9300 running slimkat). So my question is this: What makes an android device inherently slower? Is there a way to see what apps may slow down the performance?
Click to expand...
Click to collapse
That is a very good question...:good: I have the same question but I can not find a solid answer for it. I hope that some developers or experts can give us a good definition of it...
This is what I know but I may be totally off and wrong, haha..
When you first install the new ROM, all your partitions are new and clean. When you write something to your data partition, it is most of the case, it just writes data to a clean blocks without erasing the blocks. After a while, most of your blocks are dirty even though they are unused or available for writing. This is the part that users see the degradation. When a new data is writing to the available and dirty blocks, first the kernel has to erase the block before writing to it. The erase process takes a lot longer than the write process according to my research...:crying: On our tf700, writing to the internal sd or mmc is very slow already. On top of that, the erasing process has to be done before writing the new data to your internal sd. If you do the math, the performance of the writing will degrade more than twice comparing the new installation..:crying: I believe that google noticed this issue so they implemented the fsTRIM on the newer kernel source to tackle this problem..:good:
However, when you are using the fsTRIM, you have to sacrifice some slightly performance loss and you don't notice performance degradation over time.. During the normal usage, I can not tell the differences if the fsTRIM is on or off but I did see the small performance loss with a bench test.. In short, I know both _that and hund's kernel support the fsTRIM but it is disable as a default. You can try to enable it to see if it is solving your degraded problem....Good luck...:fingers-crossed:
Another method is to use the lagfix manually once a week or more frequently...
Usually I reboot to recovery, wipe cache (don't need to do dalvik), reboot back to ROM and everything is quick again.
I don't know why this works though.
sbdags said:
Usually I reboot to recovery, wipe cache (don't need to do dalvik), reboot back to ROM and everything is quick again.
I don't know why this works though.
Click to expand...
Click to collapse
Thanks sbdags for the information...
LetMeKnow said:
This is what I know but I may be totally off and wrong, haha..
Click to expand...
Click to collapse
Mostly correct.
LetMeKnow said:
When a new data is writing to the available and dirty blocks, first the kernel has to erase the block before writing to it.
Click to expand...
Click to collapse
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
LetMeKnow said:
Another method is to use the lagfix manually once a week or more frequently...
Click to expand...
Click to collapse
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.
_that said:
Mostly correct.
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.
Click to expand...
Click to collapse
Thanks _that for sharing the information and time...:good:
I take the mostly correct and hate the least incorrect....:crying: Every time I talk to you. It seems like there is a language barrier. Oh yeah, it is called an Android language, hehe... I will loose a few days researching and trying to understand what you are saying...:silly: However, I feel like that I understand android a bit more in the end and thanks for that....
Now it is time for me to bang my head on the keyboard for the next few days...:crying:
Thanks for the insightful information guys, you are frickin awesome! . I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?
vonVaffel said:
Thanks for the insightful information guys, you are frickin awesome! . I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?
Click to expand...
Click to collapse
I personally like the "discard" mounting option on Cromi x.. It is just my personal preference...:laugh: I don't recall that the lagfix was a problem for me but I heard some issued stories about it but could not remember now, sorry...
vonVaffel said:
Thanks for the insightful information guys, you are frickin awesome! . I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?
Click to expand...
Click to collapse
CROMI is based off ASUS' stock firmware, hence it is still Android 4.2.1 (and will likely stay that way forever since ASUS does not update the tf700 anymore). As TRIM is only available in Android 4.3 onward, Lagfix is still a relevant. As far as I know, some people reported data corruption from using Lagfix, but I personally haven't had any issue. Your mileage may vary though.
As for performance degradation, I am also quite interested in knowing why. One of the key strength of Linux over Windows is that Linux does not have this performance degradation over time and most Linux users will happily attest to this statement. Apparently, Google has somehow removed that strength when they made Android. Many people who choose iOS over Android will also cite this performance degradation as a factor since iOS does not suffer from this problem as well, if at all. At this point, I am just going to blame Dalvik VM for all this inefficiency. If you look at Windows Phone 8 (made by the same company that brought you Windows) and iOS, both run native machine code instead of a virtual machine and they don't have any drop in performance over time. Practically, a HTC HD7 with WP7 can still compete with current Android handsets in terms of UI smoothness and exhibit no stuttering nonewhatsoever, except when you started using intensive apps, but that is definitely a hardware limitation.
huy_lonewolf said:
As TRIM is only available in Android 4.3 onward, Lagfix is still a relevant.
Click to expand...
Click to collapse
"Trim" is a kernel feature and is activated by using the ext4 mount option "discard", which has been in the kernel since 2010.
Expanding a bit on the issue at hand, I'm curious about two types of apps:
First one is twilight. It's much like the f.lux or redshift program for PCs making the screen red at nighttime, so that falling asleep is supposedly easier. Now I enjoy using this on any type of screen I'm in front of after dark, but the downside to this is that it makes both my tablet and phone really laggy. My phone (i9300) isn't as affected by the performance as the tf700 is, but I wonder why this sort of app slows the device down?
Second app is SwiftKey. I love this keyboard app for its functionality and its predictions. However not being a native English speaker, I also write a lot of Norwegian so I have two word lists installed. My issue is that the keyboard seems slow and sluggish in its response, and sometimes it takes forever to actually write something down. Is this related to using two dictionares instead of one? I really love this app and would like to keep on using it, as no other keyboard seems as good to me.
vonVaffel said:
Expanding a bit on the issue at hand, I'm curious about two types of apps:
First one is twilight. It's much like the f.lux or redshift program for PCs making the screen red at nighttime, so that falling asleep is supposedly easier. Now I enjoy using this on any type of screen I'm in front of after dark, but the downside to this is that it makes both my tablet and phone really laggy. My phone (i9300) isn't as affected by the performance as the tf700 is, but I wonder why this sort of app slows the device down?
Second app is SwiftKey. I love this keyboard app for its functionality and its predictions. However not being a native English speaker, I also write a lot of Norwegian so I have two word lists installed. My issue is that the keyboard seems slow and sluggish in its response, and sometimes it takes forever to actually write something down. Is this related to using two dictionares instead of one? I really love this app and would like to keep on using it, as no other keyboard seems as good to me.
Click to expand...
Click to collapse
I also use f.lux on all our laptops. Never heard of twillight. I highly recommend and have used Lux Dash (location based sunset setting etc) for what seems like forever on Kindle Fire, Note, Note 2 and TF700 and it can even dim down to pretty much all black if you want it to. I never experienced any slow-down because of it on the Infinity.
Just last week I read about two apps that slow down the posters Infinity and one of them was Swiftkey and there was no mention of your dual language setting and I suspect it's not a dual language issue. I've used Danish & English (and briefly Spanish for Duolingo app so 3 at the same time) and also noticed it being very unresponsive, but haven't noticed any diffence with 1, 2, or 3 languages. Now it solely resides on my Note 2. Should be easy to test though, just by disabling one language and see if it makes a difference.
I can't remember what the other app was though. It was some post or article about lowering RAM usage by, among other things, using Titanium to change certain downloadable system apps (Gmail, Dropbox etc) into user apps and then using Greenify. Hopefully Greenify will work on this new Cromi-KK ROM I just installed, but that's on tomorrow's To Do List. Note: Greenify can only do system apps (paid version) with Xposed installer and Xposed doesn't work with KitKat.
Hope that was somewhat useful and not a complete waste of your time :silly:
Not sure if I need to create a new thread, or post here, but I'm at a loss. I feel like I've wasted a ton of money on this thing. I bought the TF700 over the Galaxy 10.1 thinking it had better specs and was going to be a great product from ASUS. First problem I had was "phantom touches" and had to send it in for repair. Now it's utterly useless. It SUPER slow, so slow that I'd rather throw it in the trash than deal with it. I've tried Clean Master, but it never seemed to help performance. I installed CROMBI-kk and it's still has poor performance. I've set the wallpaper to black (none), removed all widgets, and installed maybe 2 apps so far. I also tried LagFix but it says it doesn't have permission to modify the directories (or something like that). I've ensured that Root is enabled under Developer Options.
My old Incredible (v1) runs better than this. I really don't know what to do. It's very frustrating. I even wasted the money on the keyboard attachment but in combination with the lag, I can't even bear to use it. I downloaded 2048 and swipes are slow, and once the tiles move, sometimes it takes a couple of seconds for the numbers to merge.
Is there ANYTHING I can do? I've looked through the suggestions. Am I missing something? Does EVERYONE have this problem with their TF700? I wrote ASUS about it and basically said "since you unlocked the device, we would have to replace the mainboard for $300 (parts + labor) in order to undergo any out-of-warranty diagnostics." The only reason I unlocked it was because I've heard that the performance problems were due to the ASUS software, so I thought installing a custom ROM would be the answer to my problem.
Any idea if this is a hardware issue, or something that can be fixed in the software?
briandichiara said:
Not sure if I need to create a new thread, or post here, but I'm at a loss. I feel like I've wasted a ton of money on this thing. I bought the TF700 over the Galaxy 10.1 thinking it had better specs and was going to be a great product from ASUS. First problem I had was "phantom touches" and had to send it in for repair. Now it's utterly useless. It SUPER slow, so slow that I'd rather throw it in the trash than deal with it. I've tried Clean Master, but it never seemed to help performance. I installed CROMBI-kk and it's still has poor performance. I've set the wallpaper to black (none), removed all widgets, and installed maybe 2 apps so far. I also tried LagFix but it says it doesn't have permission to modify the directories (or something like that). I've ensured that Root is enabled under Developer Options.
My old Incredible (v1) runs better than this. I really don't know what to do. It's very frustrating. I even wasted the money on the keyboard attachment but in combination with the lag, I can't even bear to use it. I downloaded 2048 and swipes are slow, and once the tiles move, sometimes it takes a couple of seconds for the numbers to merge.
Is there ANYTHING I can do? I've looked through the suggestions. Am I missing something? Does EVERYONE have this problem with their TF700? I wrote ASUS about it and basically said "since you unlocked the device, we would have to replace the mainboard for $300 (parts + labor) in order to undergo any out-of-warranty diagnostics." The only reason I unlocked it was because I've heard that the performance problems were due to the ASUS software, so I thought installing a custom ROM would be the answer to my problem.
Any idea if this is a hardware issue, or something that can be fixed in the software?
Click to expand...
Click to collapse
Something is not right mate.
Confirm what boot loader you are on please, which recovery and how you updated the ROM then we can get you setup so experience your tab like never before
sbdags said:
Something is not right mate.
Confirm what boot loader you are on please, which recovery and how you updated the ROM then we can get you setup so experience your tab like never before
Click to expand...
Click to collapse
I followed the instructions in the thread, using twrp-2.6.3-that3_Signed.zip and cm-11.0-20140322-CROMBikk4.4.2-tf700t_Signed.zip. I had already unlocked it a while back with the intention of installing a ROM but never did until yesterday, But I had TWRP 2.3.3.3 installed.
I booted up the tablet, plugged it into the computer, copied over TWRP 2.6.3 (zip) and CROMBI-kk (zip) onto internal storage. Powered down and powered back in into RCK (recovery). First thing I did was an advanced wipe, wiping everything except for the SD card and internal storage. Then installed TWRP from the zip on the storage. Rebooted Recovery. Did the same advanced wipe (x2), then installed the CROMBI zip from within recovery, pretty much leaving all the defaults for the install except for I chose Google Experience Launcher (not sure why, never tried it I guess). That's pretty much it. It installed fine, didn't seem to have any errors or anything odd. Booted up fine, went through the setup process on first boot. Setup 1 Google Account, and installed a few apps (mainly just Chrome and 2048). Other apps installed by ROM were: AdAway, Google+ (for auto-backup), Maps, Hangouts, and I installed SwiftKey. Most everything else seems to be stock.
As far as bootloader, not really sure. When I do the volume-down+power boot, I see Key driver not found.. Android cardhu-user bootloader (1.00 e) released by "US_epad-10.6.1.14.8-20130514" A03. I can get into Terminal Command from TWRP so if I need to run any commands to find out any information, let me know.
Thanks for your response and willingness to help!
briandichiara said:
I followed the instructions in the thread, using twrp-2.6.3-that3_Signed.zip and cm-11.0-20140322-CROMBikk4.4.2-tf700t_Signed.zip. I had already unlocked it a while back with the intention of installing a ROM but never did until yesterday, But I had TWRP 2.3.3.3 installed.
I booted up the tablet, plugged it into the computer, copied over TWRP 2.6.3 (zip) and CROMBI-kk (zip) onto internal storage. Powered down and powered back in into RCK (recovery). First thing I did was an advanced wipe, wiping everything except for the SD card and internal storage. Then installed TWRP from the zip on the storage. Rebooted Recovery. Did the same advanced wipe (x2), then installed the CROMBI zip from within recovery, pretty much leaving all the defaults for the install except for I chose Google Experience Launcher (not sure why, never tried it I guess). That's pretty much it. It installed fine, didn't seem to have any errors or anything odd. Booted up fine, went through the setup process on first boot. Setup 1 Google Account, and installed a few apps (mainly just Chrome and 2048). Other apps installed by ROM were: AdAway, Google+ (for auto-backup), Maps, Hangouts, and I installed SwiftKey. Most everything else seems to be stock.
As far as bootloader, not really sure. When I do the volume-down+power boot, I see Key driver not found.. Android cardhu-user bootloader (1.00 e) released by "US_epad-10.6.1.14.8-20130514" A03. I can get into Terminal Command from TWRP so if I need to run any commands to find out any information, let me know.
Thanks for your response and willingness to help!
Click to expand...
Click to collapse
OK I don't quite understand your advanced wipe decisions. Also what is 2048?
You need to make sure you are at least wiping /data. It may be worth loading CROMBi-kk to microsd and doing a full format on internal which will do data and the whole internal sd - it'll take about 90 mins+ so nmake sure you have enough juice.
The will eliminate any remnants and left overs.
Your bootloader *should* be fine although it is slightly old as the latest one is 10.6.1.14.10 but I don't think that causes any issues. Also make sure you choose _that's kernel in the installer and it doesn't hurt to disable journaling, disable fsync and enable the 2 GPU options.
Finally after it boots go to settings, about tablet and click the build number 7 times to enable developer settings. Then go into developer settings, enable power menu, root and set your 3 animation settings to 0.5x or zero. Last but not least change the runtime from dalvik to art and then let it reboot.
Let it settle. How does it feel now?
sbdags said:
OK I don't quite understand your advanced wipe decisions. Also what is 2048?
Click to expand...
Click to collapse
In the past, I've read to do multiple wipes, but the items I'm wiping should be all except the SD_CARD and Internal Storage. 2048 is a little number game: http://gabrielecirulli.github.io/2048/ (https://play.google.com/store/apps/details?id=com.digiplex.game)
sbdags said:
You need to make sure you are at least wiping /data. It may be worth loading CROMBi-kk to microsd and doing a full format on internal which will do data and the whole internal sd - it'll take about 90 mins+ so nmake sure you have enough juice.
Click to expand...
Click to collapse
When I get some free time, I'll come back and give this a shot. Thanks for all your help.
sbdags said:
Your bootloader *should* be fine although it is slightly old as the latest one is 10.6.1.14.10 but I don't think that causes any issues. Also make sure you choose _that's kernel in the installer and it doesn't hurt to disable journaling, disable fsync and enable the 2 GPU options.
Click to expand...
Click to collapse
I'll make a note of this as well when I go back through this. I'm not sure where I had the choice of kernel in the installer, but I'll make sure I choose _that's. I don't know what those other options are, but again, will keep an eye out for them.
sbdags said:
Finally after it boots go to settings, about tablet and click the build number 7 times to enable developer settings. Then go into developer settings, enable power menu, root and set your 3 animation settings to 0.5x or zero. Last but not least change the runtime from dalvik to art and then let it reboot.
Click to expand...
Click to collapse
Thank you for all this information. When I get some time, I'll give these steps a shot and hopefully be much happier with my tablet. Thanks again!
Guys I have problem with Android smartphones. I am not the youngest anymore and remember the first PCs and first smartphones with 32x less memory then an average handheld device has today. I played with them all and know what they could do. The thing that still continues to surprise me till today on Android is WHY the heck can't an app stay in memory without being quit on the first occasion?? I really think that Android will never be usable for any serious work if things keep closing or reloading just after a few switches between apps!
Some examples: why can't I switch between Chrome browser and Onenote to type something without having that webpage be reloaded again using more data and sucking more battery power? I learned not to risk writing any bigger post into some forum lately because if I would have to switch to another tab to check some info or switch to another app the in progress text would most likely be lost because webpage would reload! Why is it so risky to switch out of some game to write a message or check calendar because it is very likely to be killed and my progress lost? The phones I used recently (Xiaomi Mi2s, Xperia Z3 compact, Xperia Z5 compact) have frikin 2GB of memory, so I wonder if nowadays apps are so much more memory demanding then before that this is simply still not sufficient. I just checked settings and some apps I just tested use few tens of MB, so it is still comparable to the times of Windows 98 or Windows mobile IMHO.
My first smartphone was windows mobile Samsung Omnia II with just around 90MB of usable memory and let me tell you that this problem was not happening on it! I could have several tabs with webpages (even non mobile versions) open and could safely switch on the camera, take pictures, write an sms and go back without having to worry that anything will be closed or reloaded! Why can't I open a camera app on Android and take a photo without having the previously open app be closed?
I can even compare today's android phones to one of my oldest pcs back in year 2000 or so. Imagine that it had just 64MB of RAM. I could have open many webpages in Internet Explorer (yeah it was far the best at that time , a few editors for web and text editing and I could even play some game and alt+tab back and forth without any problem! That was Windows 98 guys. Of course you will tell me that today's web pages for example are much bigger then in 2000. OK but what about mobile versions huh? I don't think they are that big so a phone with 2GB of RAM would choke.
I always thought that apps are supposed to be paused/frozen when I switch out of them but left in memory. Unfortunately it seems apps are being killed surprisingly often even when settings / memory shows hundreds of RAM free. The thing that is even more weird to me is that apps I had open just a few seconds ago are being closed upon switching to some other one and back, but the ones which I had active hours ago often stay in memory! That does not make much sense. Why doesn't android kill the longest not active apps first instead? OK, so do I have to buy OnePlus 3 or Meizu Pro 6 with 6GB of RAM to be able to keep simple 3 apps open without worrying that they will reload when switching out of them? As I showed this does not happen on much older devices with similar specs, so is this some fundamental flaw/feature of Android architecture or am I missing some simple explanation?
If you have experience with Windows Phones or iOS regarding this please share and compare.
So it seems everybody agrees
But I would really like to know some of your experience with other phones from the fruit company for example...
java
---------- Post added at 07:20 PM ---------- Previous post was at 07:11 PM ----------
> Why doesn't android kill the longest not active apps first instead?
There is some heuristic going on that calculate the oom priority and modifies /proc/PID/oom_adj so. For example (foreground) services have lower oom_adj (less likely to be killed by oom-killer). Actually I ended up adding code to my app that overrides /proc/PID/oom_adj to a really low number to keep it running (but that requires root - I also dont understand why *the user* does not have a chance to say "hey android keep running this app in the background!")
> Unfortunately it seems apps are being killed surprisingly often even when settings / memory shows hundreds of RAM free
Yeah that "low memory value" (ie when to kick off the oom-killer) is also set somewhere in /proc (?) It's 200MB on my phone with 2 gigs ram IIRC. To test what's getting killed (and whenl, etc.) this app is superb: https://play.google.com/store/apps/details?id=com.tspoon.androidtoolbelt
it's all even more annoying because starting even basic apps (like dialer or contacts etc. etc.) takes even seconds(!) if they are not in memory already (on any phone!) ... oh, well, java
Thanks for a reply! Have anybody tried MIUI? There is an option to lock an application and supposedly prevent it from being killed when multitasking. Just swipe up in tasks view and it marks it with a lock. I have just read this article and it seems manufacturers set these LMK values. I have a feeling they are really high for Sony phones. Maybe if I root mine I would be able to change those. Unfortunately it seems without root I cannot even view these values. They show as 0 in /sys/module/lowmemorykiller/parameters/ and cannot be opened. I can't open those oom files either.
yeah, defo need root for this
Oh and it gets worse. Because of this behaviour many apps use a nasty trick of setting up an alarm (usually with wake lock) triggered every second to make sure they are running (if a process is not running and there is an alarm for that process set up, the process is started).
So what happens is that the OOM/low-memory killer kills the app it is started by android framework the next second ... and it might get killed by oom-kiler again ...
It's interesting to run "apktool d foobar.apk" and grep the smali for "AlarmManager.set" on apps that want to run in the background ...
CleanMaster app is good and it saved me from exhausted internal capacity issues many times (on Z3Compact) and it also shows apps which frequently restart. Is that because of what you just wrote? I remember it was Pinterest a lot for example.
and it also shows apps which frequently restart. Is that because of what you just wrote? I remember it was Pinterest a lot for example.
Click to expand...
Click to collapse
sounds like it could be the case but you it's hard to tell for sure - you would have to have a look at logcat at least
I have logcat. What would you search for there?
Android phones and tablets would have surely gained your attention at one point or another, whether you are a tech-savvy person or not. Owning one makes you feel connected and in-the-loop. But are you really taking care of your Android device? While most of us focus on keeping its physical appearance from harm’s way, a majority ignore the fact that their device’s performance might be slowing down. And a slow Android device takes all the fun away.
Here is a list of some simple steps you can perform to make your Android device perform faster:
1. Perform an inventory of your apps
If you are not using all of your apps in the phone or the tablet, it might be a good decision to delete them permanently. An unused app is synonymous to carrying dead weight. It is commonly known that a full memory can affect the speed of all devices – Android or not. Hence, if you disable or delete apps that aren’t being used, you’ll free up a lot of space in your device and your device will end up performing faster.
2. Clean up your files
Android devices make the moment of clicking photographs and shooting videos very enjoyable. And it intensifies when the device is one that boasts of high-quality resolution. But as soon as these photographs and videos start piling up in your device’s memory, the performance gets hindered. Instead of getting yourself into this mess, decide once and for all which ones you’d like to keep in your device and which ones you can dispense off. Those that you can manage without having in your phone memory can be either deleted or moved to some sort of cloud storage (Google Drive, Dropbox, etc.). And since these cloud storage platforms can be integrated into your Android device, you don’t have to worry much.
3. Refrain from using live wallpapers
Live wallpapers sure are trendy and increase your cool quotient. But there is nothing much they can offer in terms of use. If you experience a downfall in the speed of your device, you can do away with the live wallpapers. Change the live wallpaper and move to a stagnant wallpaper, and see the difference in the speed of your device.
4. Use widgets only when required
Widgets are useful applications as they make the use of your device much easier. But despite the convenience they provide, they drag the speed of your device down. If you are experiencing a loss in the speed of your Android device, you can think of doing away with some widgets, at least the ones that you use rarely.
5. Check for updates
If there is a software update available, you can see it in your device’s notifications. If not, you can perform a check for them in the settings of your Android device. System updates don’t really help your device go back to its original speed, as much as they improve the overall functionalities and provide enhanced security to your device.
If you miss your Android of old days and wish for your device to be as fast as when you had bought it, perform some of these steps and see the difference. Although remember that you don’t need to do all of these steps, a mere 2-3 will be enough to bring about an improvement in the speed. After all, what doesn’t kill you makes you stronger.
Endive said:
make your phone faster by asking it to do less
Click to expand...
Click to collapse
Hope this is the right place to be asking this question, (also, first post, Hi and all that) but supposing you've done all of the things you've mentioned above, and you still have woefully poor performance from an android device? In fact, what if you have done a factory reset and it still runs agonisingly slowly?
Specific issue: An Archos (yes, I know, not brilliant) cobalt 7 tablet. It was never *fast*, but it did at least respond fairly quickly. After using it for a few years it got noticeably slower and slower; it now takes several minutes to boot, and just asking it to swipe to a different screen and start a basic app takes more minutes. Removed all the apps, deleted everything from the internal memory, barely any improvement. Factory reset.. no improvement. Put a couple of apps back on it afterwards and it has now all-but stopped.
I'm not after doing anything clever with it, just want to get it back to factory performance. I had a quick search of the forum in general, but haven't found anything that seems to fit. (other than doing a factory reset...)