If you have root you can alter the global settings database (DATA_STALL_ALARM_AGRESSIVE_DELAY_IN_MS, DATA_STALL_ALARM_NON_AGGRESSIVE_DELAY_IN_MS).
On Mon, Dec 17, 2012 at 4:22 AM, Goncalo Oliveira <[email protected]>wrote: > Robert, isn't there any way to override the data stall detector behavior? > or at least change the default value? > > > On 17 December 2012 12:02, Goncalo Oliveira <[email protected]> wrote: > >> Thanks again for the feedback Robert. >> >> I'm sending a heartbeat package but an answer is given. Though, I'm only >> sending the heartbeat every 30 minutes. Well, currently I'm doing less than >> that, but only as a workaround for this problem. For the test in case, I'm >> not even sending data. I'm just connecting and listening. >> More information that might be relevant - I ran the test again, but this >> time I'm not even making a connection. I'm just listening to the >> connectivity changes - I was suspecting someone else was causing this. >> Turns out that the same behavior occurs, so someone else is causing this? >> >> 12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection: >> tearDown=true reason=pdpReset >> 12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection: >> tearing down >> 12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState >> msg.what=EVENT_DISCONNECT RefCount=0 >> 12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio >> is on, call deactivateDataCall >> 12-17 11:50:27.951 374 1486 D RILJ : [1903]> DEACTIVATE_DATA_CALL 1 >> 2 >> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: >> DISCONNECTING for type default, previous state:CONNECTED >> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as >> pdpReset, for type mms,current state IDLE >> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection: >> tearDown=true reason=pdpReset >> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE >> for type mms, previous state:IDLE >> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(mms): >> possible=true isDataAllowed=true apnTypePossible=true >> apnContextisEnabled=false apnContextState()=IDLE >> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string >> for type:mms >> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as >> pdpReset, for type cbs,current state IDLE >> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection: >> tearDown=true reason=pdpReset >> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE >> for type cbs, previous state:IDLE >> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(cbs): >> possible=true isDataAllowed=true apnTypePossible=true >> apnContextisEnabled=false apnContextState()=IDLE >> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string >> for type:cbs >> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll >> 12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={ >> what=270368 when=-1ms arg1=1 } >> 12-17 11:50:28.576 111 209 D RILClient: processUnsolicited(): resp_id >> (11010), len(59) >> 12-17 11:50:28.576 115 194 D RILClient: processUnsolicited(): resp_id >> (11010), len(59) >> 12-17 11:50:28.576 756 784 D RILS : Executing Am broadcast -a >> android.intent.action.PROXIMITY_CP --es cmd on >> 12-17 11:50:30.576 374 496 D RILJ : [1903]< DEACTIVATE_DATA_CALL >> >> Cheers >> >> >> On 14 December 2012 19:58, Robert Greenwalt <[email protected]>wrote: >> >>> oops.. I truncated a sentence.. >>> >>> updateDataStallInfo logs show what's going on when a stall is detected. >>> In your log you can see that 21 packets have been sent since you last >>> received a packet. >>> >>> >>> On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt < >>> [email protected]> wrote: >>> >>>> The data stall detector is watching for outgoing packets with no >>>> corresponding return. If it sees this for X (6 minute default) it tries a >>>> bunch of things and one of those steps is to tear down and rebuild the >>>> connection. That's what you're seeing. I believe UDP packets may get >>>> ignored, thus my tcp/udp question. You can see some log lines in the radio >>>> log like "updateDataStallInfo: OUT send=..." that show what' >>>> >>>> What are you doing in your keepalive pings? Sending a char with no >>>> response, or echoing a response back? That could cause the problem because >>>> there'd be outgoing traffic but no incoming traffic. If there were NO >>>> outgoing the data stall detector shouldn't fire. If you change your >>>> keep-alive to send both ways you should be fine. >>>> >>>> This makes me wonder what your other test device is doing - the one >>>> that doesn't show this problem. Are you using rooted devices? They would >>>> allow you to use tcpdump and look at the network traffic.. >>>> >>>> >>>> >>>> >>>> On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt < >>>> [email protected]> wrote: >>>> >>>>> Interesting. >>>>> >>>>> Maybe it is an android bug! >>>>> >>>>> What kind of traffic are you sending? tcp? udp? >>>>> >>>>> >>>>> On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira <[email protected] >>>>> > wrote: >>>>> >>>>>> Got the radio logs... >>>>>> >>>>>> http://pastebin.com/754wJ2jd >>>>>> >>>>>> This seems to be it >>>>>> GSM : [GsmDCT] onReceive: >>>>>> action=com.android.internal.telephony.gprs-data-stall >>>>>> >>>>>> >>>>>> On 14 December 2012 18:25, Robert Greenwalt <[email protected]>wrote: >>>>>> >>>>>>> 3319 is fine. It's just the tethering code noting an interface is >>>>>>> going away. >>>>>>> >>>>>>> Can you get radio logs? This is the system log - there are several >>>>>>> log buffers. A bugreport (adb bugreport > mybug.txt) would get them >>>>>>> all. >>>>>>> Then you can match the connectivityservice dropout with what happened >>>>>>> in >>>>>>> the radio. >>>>>>> >>>>>>> I don't think you should open a bug: this is not an android issue, >>>>>>> but rather it's a samsung issue. >>>>>>> >>>>>>> I have opened an internal issue to expand CTS to check for this - >>>>>>> any device wanting to claim to be an android device would not be >>>>>>> allowed to >>>>>>> do such a thing in the future. >>>>>>> >>>>>>> >>>>>>> On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Robert, >>>>>>>> >>>>>>>> Thanks again for the feedback. I traced the logs from samsung with >>>>>>>> a simple app to reproduce this behavior. Same thing, 6/7 minutes and it >>>>>>>> drops. >>>>>>>> I posted the logs here: http://pastebin.com/FcPPbq3V >>>>>>>> On line 3323 you can see ConnectivityService disconnecting. What I >>>>>>>> can't understand is what's causing it. Line 3319 is suspicious as I >>>>>>>> don't >>>>>>>> have tethering on, but other than that I can't really determine what >>>>>>>> causes >>>>>>>> this. Should I open a bug for this? >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> On 14 December 2012 16:50, Robert Greenwalt >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> Is it possible something else on the device is occasionally >>>>>>>>> sending data and reseting your window? >>>>>>>>> >>>>>>>>> I would look in the log for the timestamp of the >>>>>>>>> ConnectivityChanged broadcast and then check the radio log and see >>>>>>>>> what's >>>>>>>>> going on. >>>>>>>>> >>>>>>>>> I suspect there is an unsolicited data call list notification >>>>>>>>> coming from the radio showing that the data call has gone away. >>>>>>>>> Perhaps >>>>>>>>> just before that there may be something explaining why. >>>>>>>>> >>>>>>>>> You may have to contact samsung if you're sure that other devices >>>>>>>>> have longer connection times on the same carrier. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Robert, >>>>>>>>>> >>>>>>>>>> Thanks for the reply. If I send a packet every 5/6 minutes the >>>>>>>>>> connectivity is maintained yes. Only if connection is idle for >>>>>>>>>> longer than >>>>>>>>>> that. The weird thing is that it's not an exact timer, even though >>>>>>>>>> the >>>>>>>>>> average is very close. Sometimes it lasts 7 minutes, sometimes 8 or >>>>>>>>>> 9. I >>>>>>>>>> even saw this happening with a 4 minute interval, though very >>>>>>>>>> rarely. On >>>>>>>>>> the other device, I can most of the times maintain higher idle times. >>>>>>>>>> I'll try to look at the logs more carefully to see if there's >>>>>>>>>> something else. Is there anything in particular that I should look >>>>>>>>>> for? >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14 December 2012 16:16, Robert Greenwalt < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Android is not supposed to do this, though there is no guarantee >>>>>>>>>>> of connectivity. It sounds like something samsung is doing, either >>>>>>>>>>> accidentally or on purpose. >>>>>>>>>>> >>>>>>>>>>> If you send a packet every 6 minutes does that keep the device >>>>>>>>>>> from pulsing connectivity? >>>>>>>>>>> >>>>>>>>>>> Can you take a bugreport - the radio log may have some >>>>>>>>>>> indication of why it's happening. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Seems that Android is dropping idle sockets when under a mobile >>>>>>>>>>>> network. Usually, no socket is kept alive for more than 7 minutes >>>>>>>>>>>> of >>>>>>>>>>>> inactivity. I am using a SIM card with a particular APN, that >>>>>>>>>>>> allows idle >>>>>>>>>>>> sockets for at least 30 minutes - this was tested using another >>>>>>>>>>>> kind of >>>>>>>>>>>> device, also communicating with GSM, and there are no drops, so >>>>>>>>>>>> problem >>>>>>>>>>>> isn't the SIM card. >>>>>>>>>>>> >>>>>>>>>>>> After a few searches in the web, I tried a few approaches to >>>>>>>>>>>> work around this, but until now, no success. I tried using a >>>>>>>>>>>> partial wake >>>>>>>>>>>> lock after connecting, releasing only when disconnected - didn't >>>>>>>>>>>> work. Also >>>>>>>>>>>> tried using only a 2G network, as some said that changing from >>>>>>>>>>>> network type >>>>>>>>>>>> could impact on this - same outcome. >>>>>>>>>>>> >>>>>>>>>>>> After digging a bit more and by analyzing logcat, I watched >>>>>>>>>>>> that a CONNECTIVITY_CHANGE is sent after some idle time, >>>>>>>>>>>> disabling the data transfer availability (active network is >>>>>>>>>>>> mobile, no >>>>>>>>>>>> connectivity) and another one is sent enabling it again (active >>>>>>>>>>>> network is >>>>>>>>>>>> mobile, connectivity). This cuts off all live socket connections. >>>>>>>>>>>> >>>>>>>>>>>> Investigating a little bit more, I also observed that this >>>>>>>>>>>> behavior is not consistent through all Android versions, or maybe >>>>>>>>>>>> (even >>>>>>>>>>>> worse) through different hardware. Connectivity break is >>>>>>>>>>>> occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't >>>>>>>>>>>> occurring in >>>>>>>>>>>> an Unitech TB 100 with Android 3.2. >>>>>>>>>>>> >>>>>>>>>>>> Does anyone know where I can get more information and/or I can >>>>>>>>>>>> work around this? I would really like to avoid sending heartbeats >>>>>>>>>>>> every 6/7 >>>>>>>>>>>> minutes. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google >>>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>> [email protected] >>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>> [email protected] >>>>>>>>>>>> For more options, visit this group at >>>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google >>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>> To post to this group, send email to >>>>>>>>>>> [email protected] >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> [email protected] >>>>>>>>>>> For more options, visit this group at >>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Gonçalo Oliveira >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>> To post to this group, send email to >>>>>>>>>> [email protected] >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> [email protected] >>>>>>>>>> For more options, visit this group at >>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Android Developers" group. >>>>>>>>> To post to this group, send email to >>>>>>>>> [email protected] >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> [email protected] >>>>>>>>> For more options, visit this group at >>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Gonçalo Oliveira >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Android Developers" group. >>>>>>>> To post to this group, send email to >>>>>>>> [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected] >>>>>>>> For more options, visit this group at >>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Android Developers" group. >>>>>>> To post to this group, send email to >>>>>>> [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Gonçalo Oliveira >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Android Developers" group. >>>>>> To post to this group, send email to >>>>>> [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected] >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>> >>>>> >>>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/android-developers?hl=en >>> >> >> >> >> -- >> Gonçalo Oliveira >> > > > > -- > Gonçalo Oliveira > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
