Related
I have noticed that my HTC Touch HD consistently shows heights incorrectly - about 50m too high where I live. After some research I have identified that the NMEA message GGA contains 0 in field 11 (Geoid separation) which should contain the difference between the ellipsoid height and mean sea level height. In my Mio A701 this field contains 50.5, which explains the 50m error on the HTC.
Despite searching this forum I have been unable to find any reports of this problem. Has anyone else experienced it?
What gps chipset does the HTC Touch HD use? My copy of Sirftech does not work on it, so perhaps it is not the Sirf ?
Is there any way to correct this error?
Thanks for any information
Edit
The problem has been solved thanks to the GpsModDriver which performs this correction (amongst other things), and which can be found at http://forum.xda-developers.com/showthread.php?t=571266.
rpettipher said:
What gps chipset does the HTC Touch HD use? My copy of Sirftech does not work on it, so perhaps it is not the Sirf ?
Is there any way to correct this error?
Click to expand...
Click to collapse
It uses the Qualcomm GPSone receiver, this isn't a discrete component as a SiRF chip would be, but is integrated into the 7201A chipset
Sounds like you need to try to flash a few different radios.
GPS height error
Thanks for the information about the chipset.
Because of that I found a small program (MyGPS) which is largely based on an MS SDK demonstration, and that gives the correct height !!
As I understand it, please correct me if I am wrong, that program uses the MS SDK primitives to get information from the GPS without going through the NMEA messages (?). If it can get the correct answer then the GPS must be working, but the NMEA messages, and the programs using them (ozi explorer, visualgps ...) are wrong.
It would be very helpful if someone could confirm that they do see non-zero values in field 11 of the GGA NMEA message (between the two Ms) on an HTC Touch HD.
(One easy way to see the messages is to use the log feature of visualgps).
Thanks for your help
Actually, I noticed it, and I programmed a soft-coded separation correction into the program GPSVP: http://code.google.com/p/gpsvp/
Not many chipsets have the separation. To date, I had none in my hands, other than when using a 'real' garmin connected via a cable to my PC.
Additionally, I have encountered no program that does the correction, other than gpsVP, in which I programmed that myself. I shall check that MyGPS, if it is correct, but I am sceptical, I do not believe that MS would strip the info from the chipset, nor do I believe MS has a softcoded correction.
I guess I could write some sort of serial loopback to insert the logic into other programs, but I am far to busy.
EDIT: just so you know: I only programmed this very small part into gpsVP, the rest is done by others.
GPS height error
Thanks for the reply cybermaus, unfortunately I am not sure what you are saying.
What did you notice ? Zero in field 11 of the GGA message?
Are you suggesting that most chipsets put 0 in field 11?
This is certainly not the case with my Mio A701 with the Sirftech chip, which puts 50.5 into that field and gives me accurate altitude values.
It seems (I am still learning) that there are two ways to get the information from the gps, either parsing the NMEA messages or using the MS API.
In my case it seems that the first way fails and the second works.
Which does your program use, and how have you made the correction?
Thanks (in advance) for your patience with these questions.
Well, yes, I am saying that the devices I encountered, all gave 0 in that field, except actual Garmin handhelds connected by serial. Also, I learned from reading in the internet, that many other people noticed the same. But that does not mean there are none. I believe any real Sirf III will do it correct, but I have a Sirf II dongle witch also does it wrong.
It even turns out there are a few devices, that put 0 in that field, but already subtract the correct separation from the geoid height, so you should not correct the value yourself.
The geoid separation is stable, and well known, you can look up the value for every coordinate on the internet. Also it varies only with a few meters per degree in the steepest places. The steepest separation is west of the mountains range of Peru. The biggest separation is a 100 mtr hole in the sea south of India.
What I did was program a hardcoded matrix with 10 degree resolution (to keep it small) with the correct geoid separation value. The program than takes your coordinates, and *interpolates* these in the matrix, to find your separation. I found it will yield the correct value within 1.5 mtrs, which is well within the GPS precision.
Also, if my program finds there is already a separation value in the field, it will *not* apply the correction, because it knows the chipset behaves properly.
If you want more details, browse the source to gpsVP. Unfortunately, you will not be able to use it for other programs if you are not a programmer or do not have access to the source of those other programs.
As I said, if I have some time, I will check out the MS API you mentioned, there is indeed a new API data structure in WM 6.1 and above, I played with it, but I did not check it for this parameter specifically. However, I am skeptical. I find it more likely the programmer from MyGPS did something similar as myself.
As to your Mio A701. Good. I said I did not encounter any other than the dedicated GPS handhelds from Garmin, but that does not mean there are none. To be quite honest, I only held 5 or so non-Garmins, so who knows.
I think the problem is not widely recognized because most people use GPS in 2D, for navigation. This 3D is more for people doing hiking, with programs like gpsVP or Ozi. Pilots and paragliders may have a 3D GPS, but know better than using it for altitude (I am a paraglider myself)
BTW: Ozi also does not correct the value, I checked.
GPS height error
Thanks again for the comprehensive reply.
I am surprised that you say that most GPSs give incorrect altitudes due to the missing geoid separation field, since I have seen a lot of discussion about this problem, mostly several years old, so I assumed that any modern chipset would have it sorted. I am also surprised that no-one with an HTC Touch HD (for instance) has complained about it.
Do you have an HTC Touch HD, and are therefore confirming that this model is faulty? That is - the NMEA message GGA field 9 gives height above ellipsoid and field 11 is 0.
I would still appreciate input from any other HTC Touch HD owner on the values in these fields.
As you say, and as I have seen, ozi explorer does not do a manual correction in the way you do. It does not need to when the NMEA messages are correct since field 9 is specified to contain height above MSL.
It does, however, have an option to subtract the geoid separation field from the value in field 9 to correct for the (other faulty) case where field 9 contains the height above ellipsoid and field 11 gives the geoid separation. If I use this option on the HTC it changes nothing, since field 11 is 0, but on the Mio it then gives me heights 50m too low (as would be expected).
I will now try your program.
Well, this not just my program, I only supplied 1% of the code, it just happens to be this particular part.
Anyway, yes, I do have a Touch HD. And yes, I am talking about the GGA message fields. One with altitude according to WGS84 ellipsoid, and one with the separation of said ellipsoid from the actual geoid according to the '96 model. Probably indeed fields 9 and 11, though I have not looked at the code for a few months, but it sounds about right.
Your MIO has a real Sirf III chipset. I would have expect that to work, because my Garmin also has a Sirf III in it. But as stated, I have a dongle with Sirf II, and that did not have the correction. Neither did the other dongles I have, but granted, they are all a bit aged and budget quality. Maybe my experiences are a non representative sample
But I confirm the Touch HD is faulty, and I suspect other HTC's and many other brands & models with non-dedicated chips. These do not have a real GSM chip, but a generic secondary ARM cpu shared with the GSM radio function and other radio functions like WiFi, UMTS, Bluetooth and probably even FM.
----
The way I understand it, the original GPS specifications did not have the separation specification. In '84, they simply did not realize that a simple mathematical ellipsoid model for earth and earth gravity was so incorrect.
It was only after the launch of the GSM network that they started to realize that there were so many fluctuations in the local gravity of the earth, which causes this effect, that they came up with the new '96 numerical geoid, rather than the mathematical '84 ellipsoid. Or something like that.
Of course, if HTC wanted, they could program the similar correction into the radio chip firmware, it is simple and small code. And it is 14 years after the fact. But I think they simply do not see the need.
----
If you start to use gpsVP, and you go hiking off-road, please note I find it best to use with GARMIN vector maps. I can also downloads Bing and Google raster maps, but those are not good in off-road data, though the satellite view is sometimes nice.
All in all, the program is a bit 'coarse' in its use. If you understand what it does (vector maps and preloaded cache for raster maps), it has value, but you will not be able to impress friends who are used to the smooth Google map application.
GPS height error
Thanks again cybermaus.
I tried the gpsvp program, both in the htc and the Mio. On both machines I got a correct altitude and a value of 51 for the geoid separation field, which compares well with the 50.5 which appears in the GGA messages on the Mio, so it looks as if your calculation works well.
I tried changing the value of the Geoid separation parameter in the setup options, trying auto, always and never, and in all cases got exactly the same results for altitude and geoid separation, so I am a bit puzzled. Does the setup option change anything, or does one have to do something else to activate it?
Well, the setup part of it is not complete yet, I think it is essentially always auto. Need to find the time and motivation to complete the coding. Log a case in the gpsVP website please.
I do not have much to contribute, but yes, living in Switzerland and hiking in the mountains I have also noticed that the altitude was wrong.
I first thought it was the inherent imprecision of the GPS, but then remarked that it was systematically off by several tens of meters.
I was also surprised that nobody complained, now I know that I am not alone.
I wish that programs like Ozi could apply the correction, or at least allow entering a fixed offset.
Thanks to cybermaus for explaining it.
Will give a try at gpspv.
GPS height error
Thanks marder.
Could you try running visualgps with the log activated, then look at the log file for the message $GPGGA? If the 11th field, between the two Ms, is always 0 then it proves the point.
I remain very surprised at the lack of complaints about this, if it is such a common problem.
But why would people complain? Or even notice?
The height error is absolute, but in differential measurements, it still works well. In other words, if you have a height, and you walk up a hill, it will give you a higher height (most of the time, and within margin of error). And most people are not aware of their absolute altitude anyway. Lets face it, if you live in Moscow, and the device tells you you are at 200mtrs, why would you distrust it?
I only noticed because I live at sea-level (Holland). You only noticed because you live in an area with above average separation, and got annoyed with two devices giving you 2 different values. And marder probably scratched his head when encountering these "xxxx above sea" markers which you get when hicking in the mountains. He would not encounter such markers in the city he lives.
Face it, if you had not had you Mio, would you have noticed? Or be able to confirm it?
Of course, once we know, we think it is unacceptable. Thats human nature, myself included.
But there are other people who did see it. Searching for keywords geoid and gps shows this thread, and the program appears also to have a fixed geoid position.
Like I said before, did you try different radios? As this affects the functions of the GPS. I had this problem too but flashing to the latest radio cleared it right up, along with making the gps now lock on with a strong signal within 8 seconds. Going through the complicated route of coding things to fix it is a bit pointless when others have fixed it before you. I'm not saying it will definitely clear it up for you, but taking 20mins to try a few radios is probably worth your time.
Oh and a good way to tell if it's accurate or not, for anyone else wondering, is to check on google earth for the "elevation".
GPS height error
cybermaus, I expect you are right - people do not notice.
I certainly did notice, independently of the Mio, by comparing the heights marked beside the autoroute that I use with those displayed by the HTC.
But you are right in that without the experience of the Mio I might well have assumed that it was due to some inherent inaccuracy in the GPS system and not searched further (and not found the thread at http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=10915 where this is all explained).
stuntdouble, thanks for the input. I assume that flashing new radios is trivial for you, but somewhat more traumatic for people like me, aware that a problem during the process can end with a dead phone. Could you perhaps tell me
1. Does it actually correct the problem i.e. does the NMEA message $GPGGA give a non-zero value in field 11?
2. Do I lose all my programs and data in the process
3. Which of these many radios do you recommend
4. Where do I find it/them
5. Are you sure it will work on my phone (which is apparently of Malaysian origin)?
6. What is the procedure?
Sorry for the interrogation but this is not as easy for me as it is for you.
For information I have:
ROM version 1.18.707.3 (23358) WWE
ROM date 12/10/08
Radio version 1.09.25.14
Protocol version 52.49a.25.26U
rpettipher said:
stuntdouble, thanks for the input. I assume that flashing new radios is trivial for you, but somewhat more traumatic for people like me, aware that a problem during the process can end with a dead phone. Could you perhaps tell me
1. Does it actually correct the problem i.e. does the NMEA message $GPGGA give a non-zero value in field 11?
2. Do I lose all my programs and data in the process
3. Which of these many radios do you recommend
4. Where do I find it/them
5. Are you sure it will work on my phone (which is apparently of Malaysian origin)?
6. What is the procedure?
Sorry for the interrogation but this is not as easy for me as it is for you.
Click to expand...
Click to collapse
1. Yes. All seemingly corrected.
2. No programs are touched as long as it's a successful flash. Radio is separate from the rest of the device's memory. Just backup your device with Sprite Backup or SPB Backup before you try it, in case you do need to do a hard reset. This way you can get your device back to exactly the way it was before.
3. The one in my sig fixed mine. However every device is different so you would need to find the best radio for your own device. I'd start with the latest and work backwards though if I were you.
4. Get them here.
5. If it doesn't work, it doesn't work. You can always re-flash your old radio if you wish. However I suggest you ask in the radio thread before trying, which radio would be best for your operator. There will be plenty of people who will know this and have tried it before you have I'm sure. The radio info is based on your operator and not on country of origin for the phone.
6. Easy procedure is in link above.
I'm not guaranteeing this will fix your problem, but it really is easy to do and well worth attempting as like I said it fixed it easily for me. It also increased battery life dramatically, and the faster gps fix like I mentioned before.
I understand that it may seem difficult on first read. I felt that way too when I first tried it. But it really is very simple and I was wondering what I was scared of after I tried it. Just follow the instructions in that thread carefully and there won't be any problems. If you use windows vista/7 then make sure you run as admin if you are flashing via the pc. Good luck.
Sorry guys.
I have followed most of the radio updates, and never noticed this being fixed. I have to admit, I never checked since I updated to 1.17 radio, so I checked just now, and it still reports 0 meters separation and at 43 meters altitude (at the coastline of Holland...) So for clarity, I logged out the NMEA messages, and all $GPGGA mssages give 43.5,M,0,M for field 9 through 12. On the latest 1.17 radio.
While theoretically possible they fix it in the radio, it still has not been done, not even at 1.17. I guess you either have the luck of living in a region where geoid and ellipsoid are very close to each other, and/or you are not aware of your true absolute altitude.
GPS height error
Thanks guys now I am confused.
I suppose we need to know what "seemingly corrected" means.
Has stuntdouble actually seen the NMEA messages with the correct data?
Rom update
I do not know about taking "20mins to try a few radios" - I have spent several times that amount just reading some of the information relating to flashing!!
But then I am a slow reader.
Following the links I eventually found what is apparently the 1.17 radio rom on a support page of the HTC site.
I am puzzled to see that it is described as for South Africa only, and concerned to see that it says it is only for ROM version less than or equal to 1.14.421.5. when my ROM is 1.18.707.3.
Should I be concerned and should I also be concerned about the caution when starting the program that it will destroy all the information on my phone?
Just being cautious, especially as I do not know what improvements if any I will see.
Well, okay, nothing really about space aliens and robots, but you're here reading, aren't you?
Lots of discussion about pro/con of the EXT4 filesystem, risks to data integrity without journaling (analogous to a transaction log for a database), the disappearance of the reboot option on Bonsai (and maybe other ROMs) because of this, blah blah blah this, blah blah that, and on and on and on.
There is another solution. You can still have the performance of EXT4, without journaling. With much lower risk to your data in case of the battery leaping out of the phone on a whim. And good ol' reboot can make a comeback too!
The nirvana is a linux command called 'sync'. Crusty old unix hacks like me will get a twinkle in their eye at the mention of this command.
sync does somesthing very straightforward and simple: It syncs the filesystems. Put another way, it flushes the in-ram buffers out to "disk", syncronizing the actual state of the filesytem with what is stored -- and stale -- in secondary storage (hard discs on the big boys, NVRAM/SD/whatever on phones).
I've been experimenting with this to see if I can improve data integrity while minimally impacting performance. Here's what I've done:
Using GScript Lite, created a simple Superuser script for rebooting that looks like,
sync
sync
sync
/sbin/reboot #Bonsai ROM
Why 3 syncs? Paranoid. Nothing more.
Optionally create a shortcut on the homescreen to invoke this script to easy one-button reboot. I did this a week ago, have been using this to reboot Bonsai 4.0.0 a gazillion (actually, a bazillion, but I'm rounding) times, and have had absolutely no problems at all. Seems to work.
Created a shell script that launches at boot, as superuser, that runs in an infinite loop waking up every 10 seconds to do a sync. No detectable impact on performance that I can see. This is what I'd expect, as there is never more than 10 seconds of filesystem activity sitting "dirty" in the cache, so the sync doesn't usually have much to do (most of the time, nothing).
What does all this mean? Well, it's sort of a "lazy" journaling, and much more efficient. There's still a higher risk of data corruption under uncontrolled loss of power than with journaling, but in my considered opinion its negligible with the usage model/patterns for this particular situation (a smartphone).
FWIW, before I implemented this method for reboot, I like others got FCs on apps randomly after using the 3-finger reboot, simply running reboot directly from a shell prompt, or back on Bonsai 3, using the power-button menu reboot command. With this sync approach, I have not had a single problem -- and I can reboot the phone again easily!
What this means for you
If you're enough of a hack to understand how to implement this stuff yourself, give it a shot (at your own risk!), and let us know how it works out.
For the rest of you, be patient... I'm putting together a package to make it simple to install all this (initially just for the Bonsai ROM, others to follow, maybe), and should have something to test in a day or two. If you're interested in being a tester, PM me. Looking for 10 people.
I'm interested in this as I have been wondering about no_journaling for some time. I think it would help to prove or disprove the theory that no_journaling is causing data corruption. PM sent.
This is very interesting. I'll be watching this - depending on the results, it may be a good option for future versions of SRF.
I think a mod should move this thread over into the Development forum, please?
This sounds interesting. So will this "lazy" journaling put the same or less wear on the nand chip vs journaling being enabled?
If it has the same or similar wear factor as no journaling, as well as no impact on performance. Then this mod is a no brainer IMO.
Does sync only cause a write operation for data that has changed, or simply rewrite the entire buffer to disk each time? I'm sure you can see where I'm going with this...
Sent from my SPH-D700 using XDA App
It's better than nothing, but it still doesn't address battery pulls or phone freezes. It just provides a more graceful shutdown IF you do a clean shutdown.
dwallersv said:
Using GScript Lite, created a simple Superuser script for rebooting that looks like,
sync
sync
sync
/sbin/reboot #Bonsai ROM
Click to expand...
Click to collapse
I tried this on my phone and so far, so good. I am using ACS Frozen Rom 1.1.0 with Twilight 1.1.0. When I downloaded the GScript lite, there was already a script for reboot, I just edited it to add the sync lines. I assume that the #Bonsai ROM is a comment and not needed, so that was omitted. I have rebooted about 10 times (I know...many, many less than a Gazillion) and have not had any issues.
Thank you!
epic4GEE said:
This sounds interesting. So will this "lazy" journaling put the same or less wear on the nand chip vs journaling being enabled?
If it has the same or similar wear factor as no journaling, as well as no impact on performance. Then this mod is a no brainer IMO.
Click to expand...
Click to collapse
In terms of the precise impact on storage, it is indistinguishable from not doing it at all. All this does if change the timing of the writes -- you control it, rather than waiting for the OS to decide to flush the filesystem buffers.
In the case of a reboot, this makes a ginormous difference, because anything in cache that hasn't been flushed is lost if the system doesn't sync before quitting back into the bootloader.
Sent from my mind using telepathitalk
styles420 said:
Does sync only cause a write operation for data that has changed, or simply rewrite the entire buffer to disk each time? I'm sure you can see where I'm going with this...
Click to expand...
Click to collapse
only dirty blocks.
sync should not cause anything to be written that wouldn't be eventually written anyway, when the kernel decides it is either idle enough to perform the deferred task, or cache "fullness" requires it to make room for newer data by flushing older stuff that hadn't been written yet.
Sent from my mind using telepathitalk
poit said:
It's better than nothing, but it still doesn't address battery pulls or phone freezes. It just provides a more graceful shutdown IF you do a clean shutdown.
Click to expand...
Click to collapse
True on the reboot mod.
On the monitor, though, it can make a big difference in the case of catastrophe. The FS cache is never more than 10 seconds out of sync with the underlying NV secondary storage. Depending on the usage model, this may be enough to reduce risk significantly.
The interval, of course, is configurable. The monitor could sync every second, reducing risk further. Given the speed of the processor in the 4G, and the low overhead hitting sync when there's nothing to flush, the overhead at a one sec interval may be trivial.
I haven't progressed far enough with this nascent idea to have characterized such questions. It's on the work order, though.
Also, my rough experimentation with this is all via shell scripting, which has a lot of unnecessary overhead. Coding this into an Android service, calling the linux sync(2) system call directly will be much more efficient.
Sent from my mind using telepathitalk
hotwired34 said:
I assume that the #Bonsai ROM is a comment and not needed, so that was omitted.
Click to expand...
Click to collapse
Yes, just a comment... across different ROMs I've found that devs mess around with the location, and linking, of the reboot command.
I have rebooted about 10 times (I know...many, many less than a Gazillion) and have not had any issues.
Thank you!
Click to expand...
Click to collapse
let us know when you get to a gazillion... our at least to a bazillion.
Oh, and anything with aliens or robots that comes up as well
Sent from my mind using telepathitalk
I could not help but notice that -- like with many issues
regarding Android -- really comprehensive and concise information
about the 'eMMC brickbug' is nowhere to be found.
After reading a lot of puzzle pieces on the internet I will try
to provide such information.
The 'eMMC brickbug' seems to occur when three conditions
coincide:
(1) The eMMC chip of the device has a bug. The app 'eMMC Brickbug
Check' from Market can check whether your device has a faulty
chip. As this is a hardware fault, nothing can be done to remedy
it; also if your chip passes, there is no way to acquire this
bug. This hardware fault has probably been around for some time.
My device bought last week is clean.
(2) A certain kernel option is set. This is the case in the 4.0.4
stock kernel and subsequently any kernel derived from this one.
As this option was unset before, the above mentioned hardware
fault could go unnoticed for so long.
(3) A certain operation must be performed on the internal memory.
Apparently the only instance in which this operation is used is
wiping the memory with CWM. Stock recovery seems not use this
operation and should therefor be safe.
Now, to brick your phone you must fullfil _all_ three conditions.
If _any one_ of the three conditions is _not_ fullfilled, you are
safe. Especially you have nothing to worry if the app says your
chip is okay.
I hope that this in fact is an accurate description of the
problem as -- like I stated -- comprehensive information is hard
to find. Also I hope this might clarify the situation.
Honestly I'm clueless about sdcard speed.
I used to have 17-22mb write speed which I think is ok.
When I had about 2gb space left it went down to 5-10mb. I removed some files and speed went back to normal for quite long time. Now I have 5gb (32gb version) left and speed is 5-6mb. I'm like WTF!
Speed test is very irradic. It writes 15mb/s for a few seconds and then stops for some seconds and then speeds up. Average then gets really slow.
What tool/apps can I use to see if some process locks up write or what could be wrong?
All ideas appreciated. Can sdcard get fragmented like harddrives?
I'm stock rom 4.2.2 rooted.
Also tried ktoonez kernel but same result for sdcard speed.
Skickat från min Nexus 10 via Tapatalk 2
And the solution was lagfix on Google Play. Well known problem on Nexus 7. Apparently present on Nexus 10 too. Strange noone else seem to have this problem on their Nexus 10.
Skickat från min Nexus 10 via Tapatalk 2
All solid state storage bogs down after a time, it is similar to "fragmentation" on hard drives but in a different fashion. solid state storage is made up of cell's that store an electrical charge. SLC chips are either on or off and store 1 bit per cell. MLC flash chips have 4 levels, which gives the capability of storing 2 bits of information per cell. So double the storage in the same space. The problem is how the MLC memory is handled, you can just write a new value to a cell like you can with SLC type. When the memory cell is empty then yes it can be written to directly, but when it contains data the system must first read the data in a cell and store it in memory, then do an erase cycle on the cell, then write the new data to the cell that is a combination of the old data and new data. A lot more steps on MLC type. As memory cells get full you have to do these extra steps a lot more often because there are no empty cells left. This causes a large slowdown in write speed. What lagfix does is called "TRIM", it sends a command to try and consolidate the data in the cells so that all the half filled cells get brought together to a smaller amount of full cells. Then it uses all the newly empty cells (which are not truly empty yet) and does an erase cycle on all of them to remove the voltage charge. This creates more completely empty cells on the storage which allows for the system to do writes much faster since it doesnt have to do 2 extra steps each time until the cells all get dirty again.
In addition to this problem, many solid state controllers have problems when they get too full, jut as hard drives do when you fill them up completely. The chipset cant handle what it is trying to do with shifting around data very well so this creates a large slowdown as well when the storage is almost full. Not all chipsets have this problem, but most do.
Most chipsets have "garbage collection" routines in the background that when the system is idle for long enough will automatically do this TRIM stuff for you to get speed back up. But if you have no idle time then the system cant do this optimization and you run into more slowdowns.
TRIM isn't specific to MLC flash, actually; SLC has to be erased too. Initially all the bits are 1, and data is written by selectively changing individual bits to 0. Changing them back to 1 can only be done by erasing the whole block.
Technically, TRIM doesn't actually command the flash device to erase anything, it just informs the device that certain parts of its data are no longer needed. Typically the device will respond by erasing blocks in that area, but the specifics can vary from device to device.
Hehe this got really technical (which is interesting) but in the end I'm just happy it worked. Most curious why this isn't fixed either in kernel or rom. Because I honestly thought my internal memory was damaged and thought I needed a replacement. Shouldn't this really bad slowdown occur to everyone after a while?
(really love autocorrection sometime. Sdcard managed to be seward)
Skickat från min Nexus 10 via Tapatalk 2
Yes the slowdown does happen to everyone. Theoretically the problem should clear itself up from garbage collection built into the chipset. This lagfix app is really for those who want it fixed right away and not done over idle time in the background.
I don't think it fixes itself on my Nexus 10. Been slow speed and laggy as hell for days. And it should have been idle a lot during this time.
Skickat från min Nexus 10 via Tapatalk 2
Hi,
I haven't been in here a while. Mostly because I rarely use my 32Gb (2012) N7 anymore; it is simply too painful of an experience. Typically I will pick it up for web browsing, but after the browser or keyboard hangs for tens of seconds for the fifth time in ten minutes, I feel like chucking it against a wall.
Don't tell me I need to free up some space; it has 25 GB of free space in /data
Don't tell me I need f2fs; I'm running CM 12.1 (20151117) / 5.5.1 with /data and /cache formatted as f2fs
Code:
[email protected]:/ $ mount | grep f2
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache f2fs rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,inline_dentry,active_logs=6 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data f2fs rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,inline_dentry,active_logs=6 0 0
I've filled (to within a few 100 MB) the device and deleted all those files; no real improvement.
So anyway - since I haven't been keeping up, I'm wondering if anyone had been able to shine some more light on what seems to be progressive degradation of eMMC write performance with use (independent of choice of OS, kernel, fs types etc). I suppose this is some sort of wear-leveling/write amplification thing but I can't say for sure.
I really liked this tablet for the first 18 months I owned it; I'm not trolling anyone here. Note that I don't believe this is a situation with faulty hardware (it never crashes or spontaneously reboots - eventually it always comes out of it's hangs (but maybe not for 30-40 seconds). My device has just gotten progressively worse with time, to the point of unbearability.
Have there been any new developments or findings in the last several months?
I use Parrot Mod with Stock 5.1.1 on my N7 3G and I have acceptable performance on it. Ok, Chrome is not the fastest but much faster than before applying the Mod.
http://forum.xda-developers.com/showthread.php?t=3300416
bftb0 said:
Hi,
I haven't been in here a while. Mostly because I rarely use my 32Gb (2012) N7 anymore; it is simply too painful of an experience. Typically I will pick it up for web browsing, but after the browser or keyboard hangs for tens of seconds for the fifth time in ten minutes, I feel like chucking it against a wall.
Don't tell me I need to free up some space; it has 25 GB of free space in /data
Don't tell me I need f2fs; I'm running CM 12.1 (20151117) / 5.5.1 with /data and /cache formatted as f2fs
Code:
[email protected]:/ $ mount | grep f2
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache f2fs rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,inline_dentry,active_logs=6 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data f2fs rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,inline_dentry,active_logs=6 0 0
I've filled (to within a few 100 MB) the device and deleted all those files; no real improvement.
So anyway - since I haven't been keeping up, I'm wondering if anyone had been able to shine some more light on what seems to be progressive degradation of eMMC write performance with use (independent of choice of OS, kernel, fs types etc). I suppose this is some sort of wear-leveling/write amplification thing but I can't say for sure.
I really liked this tablet for the first 18 months I owned it; I'm not trolling anyone here. Note that I don't believe this is a situation with faulty hardware (it never crashes or spontaneously reboots - eventually it always comes out of it's hangs (but maybe not for 30-40 seconds). My device has just gotten progressively worse with time, to the point of unbearability.
Have there been any new developments or findings in the last several months?
Click to expand...
Click to collapse
Just install parrotmod and you'll notice the difference
I'm using N7 as a main device with Pure Nexus ROM + parrotmod and installed Facebook, messenger, facebook groups, asphalt 8 and about 60 other apps still works fine without lag!
Thanks for the quick feedback everyone.
I'll read through that entire thread and look at the github too.
Already I see I've got Kingston eMMC (manfid 0x000070) , ugh.
Does Trimmer accomplish the same thing as trim on boot, or is it possible to re-enable trim-on-boot on a Kingston device if not? (I just leave the tablet on, so boot time isn't a huge deal to me.)
PS for anyone interested I stumbled across an older version of JESD84 (.pdf)
Please, don't think too much about chips, trimming, file systems etc. Simply apply the Mod and be happy.
Your N7 then will be faster than before.
mausbock said:
Please, don't think too much about chips, trimming, file systems etc. Simply apply the Mod and be happy.
Your N7 then will be faster than before.
Click to expand...
Click to collapse
Performance optimization is always, always about details. In particular, tuning that benefits one type of workload usually makes another one worse.
If I'm sitting behind a full queue of I/O and the CPU is idling at 8% usage, tweaking the GPU or adding BT functionality isn't going to do me a whit of good.
But I'll give lines 58-74 of 01ParrotMod.sh a roll and see how it goes.
PS for anyone else reading this thread: the Trimmer app doesn't do anything on f2fs. (That app is basically a wrapper around a BusyBox version of fstrim; it dies without doing anything but the app doesn't record that in it's log.)
It's Your life. You can spend Your whole time in analyzing this old tablet and its firmware. You can also try dozens of custom roms or custom kernels, format partitions with f2fs etc. Mostly You will still have a laggy N7.
In past I also tried many things like wiping cache, limiting background processes and other tweaks in developer options.
Parrotgeek did a lot of research and many people like are happy with the result.
By the way, f2fs is auto trimming. There is no need to call fstrim manually or by script.
mausbock said:
It's Your life. You can spend Your whole time in analyzing this old tablet and its firmware.
Click to expand...
Click to collapse
You are probably right I suppose. I guess the downside of buying inexpensive commodity hardware is that it is designed for a 2-3 year life cycle, maybe less.
Makes me wonder how much usable life span I gave up by letting the tablet sit at idle condition instead of turning it off - all those slow but non-zero write cycles inexorably chewing away at MLC/TLC write endurance lifetime, and that in turn causing progressively higher write amplification & lower usability/performance.
I can understand that - compared to other types of appliances / equipment that people buy - that expectations of usable lifetime for computers has always been rather short. Mostly because a replacement would be dramatically better/faster/more capable than the older gear. (In contrast, nobody expects to replace their toaster oven every two years - they won't be getting dramatically better toast every few years)
On the other hand, this is a subtly worse situation: not only are the replacement products better, but the older product is actually getting worse with time. Imagine buying a car model with a top speed of 100 mph; but during each year of ownership it's top speed drops by 20mph. It is impossible to remain satisfied even at a fixed level of performance if that functionality is continuously eroding.
Kind of a new-age planned obsolescence I guess. Just keep buying!
@bftb0 I am still using the N7 as my daily driver. I am running trim every two days (it helps especially when there is a lot of write access on your tablet, e.g. installing new apps, etc.) and I have set the background task limit to 4. With these settings on MM I can live quite well. Even if there are from time to time some lags, but most of the time I do not even notice them ...
AndDiSa said:
@bftb0 I am still using the N7 as my daily driver. I am running trim every two days (it helps especially when there is a lot of write access on your tablet, e.g. installing new apps, etc.) and I have set the background task limit to 4. With these settings on MM I can live quite well. Even if there are from time to time some lags, but most of the time I do not even notice them ...
Click to expand...
Click to collapse
I'm using f2fs for /data and /cache, so explicit "fstrim" is not needed. Which flash memory chip do you have? I think that probably accounts for some of the differences in reports. (The "eMMC" flash memory usage model hides some details of wear leveling and even the basic memory cell type and ECC design within the chip itself - so chips from two vendors can perform similarly at the beginning of their lifespan, but quite differently towards the end as they start to engage in more page replacement activity - the methods they use to implement wear leveling are not mandated to be identical by the eMMC specification)
I have the 32 Gb model with the eMMC flash memory chip apparently mfg'ed by Kingston. (manfid 0x70)
I do have a 16GB version with MAG2GA (Samsung), rev. 0x05 (which should have even the TRIM bug ... 8-0)