yashsingh1/xdaforums huggingface dataset:
[HD2 Android Q&A, Help & Troubleshooting and Genera] xuix:
It not solve my data connexion problem, i have installed the apps, set it to AUTO, reboot, delete the apps, and now everything is same than before i install the apps... nothing better...

using the Mdeejay eVo Sense v. 1.0 Warm|3.29.651.5|[kernel: hastarin R7.1] release with the libhtc_ril_wrapper.zip updated (9/28)
[HD2 Android Q&A, Help & Troubleshooting and Genera] will3k14:
Ill try this on my 1.8 and my evo 1.0.1, will report back
[HD2 Android Q&A, Help & Troubleshooting and Genera] lkrfn5283:
How long were you running michy's r1 kernal before you installed that app? Reason I asked is because installing michy's r1 kernal and rebooting is what solved my data issue.

*minus the winmo rom i have the same exact set up as you
[HD2 Android Q&A, Help & Troubleshooting and Genera] k2trill:
Try this kernel

http://xdaforums.com/showthread.php?t=791584
[HD2 Android Q&A, Help & Troubleshooting and Genera] malzubai:
Solutions?

Any new solutions to this item, I attempted the above fix and didn't quite fix it. I have a good feeling this fix has a lot to do with the rom/radio combination.
[HD2 Android Q&A, Help & Troubleshooting and Genera] lkrfn5283:
I concur. Thats why I was wondering how long had he used that set up before downloading the app. I have almost the same exact set up and my data connectivity has been excellent (this is without downloading that app)
[HD2 Android Q&A, Help & Troubleshooting and Genera] jigners:
I can confirm this has worked for me, after updating my kernel to hastarin 7.1

i started having data disconnections, then this came along:)

thanks for sharing:)
[HD2 Android Q&A, Help & Troubleshooting and Genera] liaquila:
My attempt ...

Until now, any build that uses PPP would not work without at least one flaw in the data connection every half hour or less... Terrible...

I then decided to try a combination of the tips that I've been reading in the forum.

First, I edited the build.prop in system folder and changed the last two lines in the file, the primary and secondary DSN. I used Namebench, a free program to find the indication of which DNSuse for my region (I live in northern Brazil). I run the Namebench on my laptop and copied the two recommended DNS addresses.

Then followed another tip, and using the *#*#4636#*#*, changed the network configuration for GSM auto.

And finally, in the phone settings, I changed from GSM/WCDMA auto to GSM only...

It's five hours straight without any disconnection !!!!!! It is true that the connection is slower because of GSM, but it is steady and reliable!

My next step will be to change this last parameter for WCDMA Only and just see what happens

Sorry about my English, hope you can understand!
[HD2 Android Q&A, Help & Troubleshooting and Genera] will3k14:
Thanks for the help I tried this fixit doenst work. I'll do what you suggest K2trill thanks. btw any fix for the voice rail issue on the evo 1.0.1?
[HD2 Android Q&A, Help & Troubleshooting and Genera] k2trill:
I'd been running it since its release... few days
[HD2 Android Q&A, Help & Troubleshooting and Genera] aussiebum:
+1. Had freq. dropouts when on 2.09 radio, 2.10 caused the entire radio to dropout and 2.11 was fairly stable but still freq. dropout. 2.14 was been the most stable radio for me so far, only 2-3 dropouts max per day.

Of course, the early radio dropouts could've been caused by the older buggy ril wrapper library, so I might revert back just to experiment around a bit more.
[HD2 Android Q&A, Help & Troubleshooting and Genera] tkato:
Using Mdeejay Evo Sense 2.4.2 I Managed to resolve my data drops... at least in the last 24 hours.
[HD2 Android Q&A, Help & Troubleshooting and Genera] k2trill:
I still haven't gotten one freeze on any of the 3 phones I'm testing since I did this. maybe I'm lucky...
[HD2 Android Q&A, Help & Troubleshooting and Genera] liaquila:
Ok. Just to give a feed back...

With GSM only, no drops at all!!!!

When I changed to WCDMA only, overall it's more stable than before, but I had a few drops last night and this mornig...

So, for me, I'm switching back to GSM only. I do prefer a more slower connection but with no drops !!!

I'm using 2.14 radio, with FroyoStoneSense v3.1 (Darkstone) !
[HD2 Android Q&A, Help & Troubleshooting and Genera] pathologo:
Installing & uninstalling "Data On Demand" had no improvement for me.
[HD2 Android Q&A, Help & Troubleshooting and Genera] memin1857:
Data on Demand changes apn settings related to your provider.

I found out about this when I was faking my provider with Market Enabler. It adjusted the apn for the provider I faked. From that I figured that it reconfigures apns. I think thats why your situation changed. Data on demand entered new apn settings which were different than your original settings.
[HD2 Android Q&A, Help & Troubleshooting and Genera] Horsey:
Are you guys receiving any text messages with the data drop? I ask because I don't seem to be getting some text messages sometimes and a phone reboot will work and sometimes airplane mode will work.
[HD2 Android Q&A, Help & Troubleshooting and Genera] veda_sticks:
i remember having this problem with my g1. data connection would just stop working with the up arrow always on. never found a fix, but it was not nearly as frequent as on the hd2.

ive also had problems in thje past with broadband dongles under linux, sometimes bogus dns addresses would be assigned when yoiu connect.

i bet its a similar bug.

has anyone looked at what there dns addresses are when there data connection stops working#?
[HD2 Android Q&A, Help & Troubleshooting and Genera] AliBaba007:
OK I tried this on mdeejay evo sense v1.4 and on the plus side, it seemed to have worked perfectly. On the downside, it stays on a 2G connection permanently and I can't (or don't know how) to change it 3G. Any ideas?
[HD2 Android Q&A, Help & Troubleshooting and Genera] will3k14:
Did you ever get a fix?

Sent from my HD2 using the XDA app
[General Topics] migliorare:
Hi!

I'm sorry, but i don't know where i should write to report a bug found on my Samsung Galaxy S... i mean i don't know if i should write here or in another site... i'm sorry for that, but i hope someone could help me...

My Galaxy (that I love it) i don't know why to some randomly number of my friends doesn't send SMS... i mean... it send... i spend money, but they doesn't receive...

It is not an operator problem, it do the same problem with Tim, Vodafone ecc...

To some mobile phone number they don't arrive... I think was a bug in my firmware 2.1 JM5, but a friend with Galaxy S too but JM3 firmware noted that some number in SMS hasn't the "+" in front the number... if ther is +39 (i'm writing from Italy... and sorry for my english... :o) or if there isn't is the same... SMS arrives, but sometime the number starts with 39 (no "+" ahead)... we try to cancel the phone number, delete the contact and rewrite, but the thing persists... How can i do? I Hope Samsung knows this problem and corrects it in the next Froyo 2.2... but i would write to it... i hope i write enough correct to understand me... :o

Thanks by now for who respond me... ;)

Edit: Ehm... sorry... wrong place... how can i delete this post? (i just rewrote in Questions and FAQ... ) :o
[Galaxy S I9000 Android Development] xan:
There is significant need for detailed information about filesystems here. Info is scattered in many topics.

My goal is to lead all thought concerning filesystem debate to this thread.

Lots of thought is given from the developers to choosing the correct one.

My idea is to start an detailed and technical only discussion about best suitable RFS replacement for SGS.

To start, I recall a blog post from Theodore Ts'o, one [if not main] of ext4 developers, who tested and compared write operations overhead on ext2/3/4 filesystems.

1. Thoughts by Ted - SSD’s, Journaling, and noatime/relatime

As a second reference I post Samsung's moviNAND™ (used in SGS) product info:

2. SAMSUNG Semiconductor - Products - Fusion Memory - MoviNAND

Third one, RFS product info:

3. SAMSUNG Semiconductor - Products - Flash - Flash Software

The first link should be the most interesting one. There are interesting results about overhead caused by journaling and comparisons of data written executing the same operations in these three filesystems.

Second and third ones should justify (or exclude!) the use of 'general purpose' filesystems on SGS.
[Galaxy S I9000 Android Development] RyanZA:
Nice topic! Hopefully we can get some useful information out of this that can relate back to better lagfixes! :D

I'd first like to say: EXT3 doesn't make any sense. It has no advantages other than being a 'middle ground', and a fairly poor one at that. I don't think EXT3 is really relevant here.

So that leaves EXT2, and EXT4. In effect, EXT4 is just EXT2 with added options that are available, so it comes down to 'EXT simple' which is EXT2, and 'EXT features' which is EXT4. The features add to the overhead (how much? we need some way to test it!) and also reduce the speed in the case of journaling. The purpose of journaling is to remove the need for filesystem checks, which is fairly important to a lot of users who don't want their phone to be sitting at a black screen for minutes while booting.

To address the topics though, in regards to the Samsung recommendations - Samsung recommends we use RFS. I would personally discount any recommendations from Samsung at this point as being clueless, so unless other sources back up anything said by Samsung, it should probably be discounted! :)

As far as the Tso blog post, it is in regards to wear and tear on the SSD, and not in regards to speed. EXT4 adds both increased wear (up to 40% in a 'make clean' - how much does it add to normal Android operations, such as writing sqlite databases?) and decreases the speed (certain apps run slower). What the blog post is saying is that nothing bad will come from using EXT4, which is great, and let's us choose - since it doesn't say anything bad will come from using EXT2 either, except for the need for filesystem checks.

As far as fragmentation issues - the underlying MoviNAND is constantly shuffling around data by itself, so fragmentation is a bit of an unknown at this point in all cases.

So I'm gonna conclude (and hopefully someone will prove this wrong and give us more information) -

EXT2 : faster and less wear on the SSD and less overhead on the CPU, but requires disk checking on boot.

EXT4 : slightly slower and slightly more wear and slightly more CPU, but very fast boots.
[Galaxy S I9000 Android Development] ghost77:
I personally don't worry about flash wear , it takes many years for it to run out of write cycles by then you will have switched to new phone two or three times, that is the case for all SSD's during normal use, only exception would be server load but then you will be using premium SLC nand anyways, or intentionally running heavy simulated load 24/7 for the sake of killing nand :p

As for EXT as long as it is not crappy RFS , ext2 or 4 is ideal in my opinion.
[Galaxy S I9000 Android Development] xan:
We should notice two fragmentation levels:

1) File system fragmentation (external and internal),

2) MoviNAND fragmentation, which is present, but nature and level is unknown.

In the context of ext2/3/4 choice I must disagree to some extent.

Nature of first one is well-known, and ext4 has been designed with lowering external file system fragmentation in mind, compared to ext2/3. This makes ext4 more viable option at this point, which should be noted.

There is no info given about MoviNAND layer fragmenation, nor wear-leveling methods. My conclusion (based on study of wear-leveling methods:

Micron TN-29-42: Wear-Leveling Techniques in NAND Flash Devices Introduction

) is that there might be significant amount of underlying layer fragmentation present, caused by file system not being 1:1 with physical media.

We might need to get more detailed information about this. The one and only mention about in-build wear leveling in MoviNAND I personally found is:

This is quite short.

This seems to be the worst case scenario. Could anyone with knowledge explain the nature of 'make clean' operation?

Based on this study, average additional wear caused by amount of data written (only!) is no more than 15%, in the file system level.

We should consider write amplification, which level is unknown. Writing one byte in the file causes whole low-level block to be rewritten. Does this rewrite whole filesystem block? If so, it causes to rewrite all MoviNAND blocks containing data for one filesystem block.

We know that wear comes from write count per block, not write amount.

There are several improvements in ext4 which lower write count compared to ext2/3.

Here's some of them:

Persistent pre-allocation which prevents writing 0s to whole preallocated space,

Multiblock allocator, making allocating multiple blocks a single write operation,

Allocate-on-flush, delaying writes.

This adds up, decreasing number of writes.

//EDIT: Sorry for constantly editing this post, but I want to be as exact and understood I can be.
[Galaxy S I9000 Android Development] Project1.exe:
Shouldn't we not worry about file system defragmentation since it is only a big deal for spinning disk drives for their access times? whereas in SSD/NAND, access time isn't a real concern?
[Galaxy S I9000 Android Development] RyanZA:
You can't just de-couple filesystem fragmentation from the underlying data fragmentation, I think. Or at least, the issue isn't all that cut and dried.

The major fragmentation changes in EXT4 over EXT2 is to ensure that the same file shares contiguous blocks. But, does this mean anything at all on top of MoviNAND?

NAND is random access - so 2 block file which has one block at the start of the disk, and one at the end, should perform identically to a 2 block file with the two blocks next to each other. However, this is where the practical comes in - If the MoviNAND has more than 1 chip with different channels or something, then having the 2 block file have block 1 on chip 1 and block 2 on chip 2 may actually be faster than having both blocks on chip 1.

Basically, fragmentation on the MoviNAND is not necessary the same as fragmentation on spinning media! And the MoviNAND isn't going to listen to where the filesystem tells it to put data, it provides a 'virtual table' that the filesystem sees, but unlike an old spinning disk, the table isn't what's actually going on. :)

So, I'm gonna say that We Know Nothin! :)
[Galaxy S I9000 Android Development] Project1.exe:
^my point, better explained :D
[Galaxy S I9000 Android Development] jbrugger:
I do not have a lot of knowledge of file systems, but as explained here:

maenad.net/geek/di8k-debian/node29.html (i think that counts for ext4 as well)

So when i'm correct, we are safe to use ext2 and loose the overhead, and take the fsck for granted. :)

Is there a raid solution for the external / internal sd cards available? ;)
[Galaxy S I9000 Android Development] hardcore:
Also one point to consider is:

Are both the Internal SD (mmcblk0) and STL partitions MoviNAND? Or...

Is only the STL partitions OneNAND and the Internal SD is a separate device (MoviNAND)? Maybe RFS is necessary for OneNAND but not for MoviNAND?
[Galaxy S I9000 Android Development] xan:
Yes, this is correct. Furthermore I believe that file system fragmentation may lead to increased wear, depending on relation of file system and MoviNAND internal block sizes.

This actually depends on MoviNAND wear leveling algorithm, which is yet to be revealed.

If this means something - we might actually add unneeded write count. If not, using these two file systems should result in the same amount of MoviNAND wear caused by fragmentation. We might be terribly wrong and introduce additional write counts. Why take the risk?

In my opinion its too speculative. If it is true, it might increase linear operation speeds. There is a way to test it: write a large file and monitor MB/s in short time periods. If two or more performance levels are noticeable -> this makes this file to be written simultaneously, and your suspicions may be true. Although fragmenting file system in sake of exploiting this behavior is not a good idea.

What is sure, this puts excessive workload on controller, which should be always avoided.

Of course it isn't. But remember, with every additional write cycle in file system, there comes unknown amount of additional write cycles on MoviNAND. Also, with every single MoviNAND write, there comes full block (128KB? no idea here) read, ecc check, ecc recalc and rewrite. (Unless MoviNAND utilises copy-on-write, which is doubtful since it might increase wear)

What comes to my mind are first SSD's available on the market, some time ago. They were flawed, their random write times were unacceptable. Random write operations might not be that fast on MoviNAND as we might expect.

I think the fragmentation issue should be avoided, because in worst case scenario nor we lose or gain anything having less fragmentation.

This however, is genuine statement :D
[Galaxy S I9000 Android Development] xan:
Is it worth losing all features lowering write count and reducing fragmentation?

It might be better to use ext4 w/o journaling than ext2. This depends if the benefits of ext4 listed in one of my previous posts work without journaling.
[Galaxy S I9000 Android Development] jbrugger:
Isn't that solved by using the oclf over the voodoo fix?
[Galaxy S I9000 Android Development] RyanZA:
I got a bit lost as to what you were saying is impacting on what (<- I lost myself writing that too!)

This could be completely incorrect, since I don't know the low level details of MoviNAND! But, I'm going to try make a diagram so at least we'r all on the same page. :D

EDIT: red is for the 'fake' table, or the table that movinand shows to linux

green is for the 'real' table, or the actual layout of blocks on the physical disk

___1234____ would mean that all blocks are aligned in the proper order and are contiguous.

_2__3__1__4 would mean that the blocks are all over the place, with big gaps in between them, and in the wrong order.

A) File made up of 4 'blocks' sitting on EXT2, with each block labelled 1-4, and blank blocks labelled with an _

__3__2__1__4___

On a spinning disk, this would be horribly fragmented, and the disk would have to seek (spin) 4 times while reading the one file

However, the underlying MoviNAND real storage in terms of 'blocks' could look like this, purely due to chance (Remember, the MoviNAND is doing constant wear leveling - this means that after the device has been in use for awhile, it could be writing your next block anywhere!)

___123___4______

So even though it is very fragmented at a filesystem level, on the real physical media, it's not very fragmented at all!

B) Now we load up the same file onto EXT4. EXT4 thinks that the file is really fragmented (because all it sees is the 'fake' layout, it can't see the real layout!) so it goes ahead and fixes up the file for us! This is how the file looks to EXT4 now:

1234______________

Awesome, it's all nicely laid out! But wait, it had to move the blocks around to do this, so what may have happened to the underlying now?

____1_3__4______2_

It's actually worse than the fragmented EXT2, even though it's gone to all that effort of moving data around! This is also why running a 'defrag' on RFS might not actually help at all. ;)

So basically, the issue isn't simple! I can't guarantee that this happens, since I don't really know how it all works, but I can almost guarantee you that going to any effort to align blocks on the virtual table isn't going to translate directly to the real physical disk!

So I'm going to conclude that EXT4s fragmentation routines are just as likely to hurt performance as they are to help it, with all of the overhead as well. If you do use EXT4, you should probably explicitly TURN OFF the defragmentation. :) Or at least, acknowledge that we don't know.. ;)
[Galaxy S I9000 Android Development] dupel:
Well, I just want to add my 2 cents.

I used both OCLF and voodoo with OC kernel (thus I was experimenting with voltages and very often had to pull out the battery).

Never had data loss on OCLF as it was probabl negated by underliying rfs.

Once had data loss on voodoo, though older version (complete data loss - reboots (check fs I assume) did not help, as didn't just wiping data) and had to completely reflash.

Thus data loss is possible, up to a level where your phone would be almost unsuable (I had a lot of FC's, but could still call, for example). So, not sure if jounraling will actually help in case of data corruption.
[Galaxy S I9000 Android Development] xan:
I believe you are talking about Online Defragmentation, which according to this:

http://kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0

is

Yes, your drawings would be correct, but only when filesystem block size = MoviNAND block size.

Yeh, sorry I'm not good at expressing my thoughts, even worse doing it in English.

What I'm trying to say is:

Given the number of unknown variables, there is a big probability that fragmentation is increasing write count, leading to increased wear.

Also, ext4 features decrease number of writes, decreasing wear.
[Galaxy S I9000 Android Development] RyanZA:
To be honest, I'd attribute data loss to overclocking long before I'd attribute it to an EXT filesystem. ;)

Moving around a lot of data and rebooting can also cause issues, as can numerous other things. From bug reports for OCLF, it basically comes down to the more different fixes and changes that a user tries, the more likely he is to report 'data loss'. All of the novice users I know who are using OCLF have never had any data loss issues (and there are tens of thousands of them at this point), so I'm fairly quick to attribute OCLF data issues to non-OCLF sources at this point, since after investigating it usually turns into 'well just before running oclf, I tried using Kies to flash froyo and it didn't work, and then I tried deleting stuff in root explorer, and then it.. ' :D

I'm not discounting your issues though, but simply going by statistics that more people have had issues with overclocking than with OCLF. :) If anybody has any more info? Although this isn't really the place to post it - rather post it in the OCLF posts (or read through em, most of these issues have come up multiple times now! :) )
[Galaxy S I9000 Android Development] jbrugger:
One fact is however that the rfs filesystem (that should be cooperating correctly with the underlaying system) does a worse job than ext4 or ext2 in the matter of speed.

In other words, the lag-fixes actually DO work.

Isn't it than safe to assume the underlaying system is just a 'normal' system, and stores like any other sd?

In that case the oclf over voodoo should be the best of both worlds.