You could try using the UI in the Settings Data usage screen, but it's going to be hard to select a small enough time slice. Perhaps if you left it for a while so you had a bigger window to work from.
On Mon, Dec 17, 2012 at 9:01 AM, Goncalo Oliveira <gonc...@minkan.net>wrote: > Guess I need a rooted device for that... > > ------ QTAGUID STATS INFO (su root cat /proc/net/xt_qtaguid/stats) ------ > > *** exec(su): Permission denied > > > On 17 December 2012 16:33, Robert Greenwalt <rgreenw...@google.com> wrote: > >> Interesting. >> >> If you run a test and take a bugreport you whould be able to look at >> "QTAGUID STATS INFO" in the bugreport. It shows the packets/bytes sent per >> app. Take a bugreport first, let your device sit for 10 minutes and take >> another. The 4th column is the UID of the app and you should be able to >> figure our who is responsible for the data. >> >> R >> >> >> On Mon, Dec 17, 2012 at 7:00 AM, Goncalo Oliveira <gonc...@minkan.net>wrote: >> >>> Robert, some more information that might be relevant. >>> As I told you, I was using a sim card that connects through our own APN, >>> that restricts access to our servers. >>> Today I decided to try the same scenario with a different SIM, so I >>> plugged a "generic" 3G sim card, without the APN restrictions. The result >>> was that I no longer had the stall problem... Could any Android background >>> service be failing to connect and giving this outcome? >>> Also, browsing the web I found this issue: >>> http://code.google.com/p/android/issues/detail?id=35856 might it be >>> related? >>> >>> Cheers >>> >>> >>> >>> On 17 December 2012 12:22, Goncalo Oliveira <gonc...@minkan.net> 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 <gonc...@minkan.net> 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 <rgreenw...@google.com>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 < >>>>>> rgreenw...@google.com> 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 < >>>>>>> rgreenw...@google.com> 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 < >>>>>>>> gonc...@minkan.net> 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 <rgreenw...@google.com >>>>>>>>> > 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 < >>>>>>>>>> gonc...@minkan.net> 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 < >>>>>>>>>>> rgreenw...@google.com> 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 < >>>>>>>>>>>> gonc...@minkan.net> 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 < >>>>>>>>>>>>> rgreenw...@google.com> 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 < >>>>>>>>>>>>>> gonc...@minkan.net> 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 >>>>>>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>>>>> 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 >>>>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>>>> 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 >>>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>>> 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 >>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>> 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 >>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>> 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 >>>>>>>>> android-developers@googlegroups.com >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>> 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 >>>>>> android-developers@googlegroups.com >>>>>> To unsubscribe from this group, send email to >>>>>> android-developers+unsubscr...@googlegroups.com >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gonçalo Oliveira >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 android-developers@googlegroups.com >>> To unsubscribe from this group, send email to >>> android-developers+unsubscr...@googlegroups.com >>> 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 android-developers@googlegroups.com >> To unsubscribe from this group, send email to >> android-developers+unsubscr...@googlegroups.com >> 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 android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
