**** BEGIN LOGGING AT Tue Nov 29 03:00:01 2016 Nov 29 03:00:40 gta02 you were lucky to hear a first ringtone (after resume of system) before caller quit the call Nov 29 03:01:29 gta04 never really found a way to get beyond the 60+mA(?) standby current, IIRC Nov 29 03:02:30 btw what's status of Pyra now? I expected them to ship a 3 months ago already Nov 29 03:03:50 DocScrutinizer05: actually, gta04 was around 20 mA IIRC Nov 29 03:04:24 DocScrutinizer05: also, the wakeup times on incoming calls is perfectly fine on my GTA02 with Qi bootloader and QtMoko Nov 29 03:04:25 that would be almost acceptable, so not in the class of problem I seem to recall Nov 29 03:05:08 it's other hardware and software issues that make it barely usable... Nov 29 03:05:52 hah, how do you know? do you frequently call yourself to check the delay between call INVITE established (inbound call at modem) and system being up and starting to play ringtone? Nov 29 03:07:40 DocScrutinizer05: I think I actually tried that at some point in the past. also, when my audio system is on, I hear how long the delay is between signaling starting and the ring tone starting -- it's not too long, and not significantly longer than with "regular" phones I believe Nov 29 03:07:51 resume from susp2ram is a nogo for a number of reasons Nov 29 03:08:40 it was the one most unsurmountable problem of GTA01/02 Nov 29 03:08:57 BTW, isn't the Android approach just a variation on suspend? Nov 29 03:09:08 possible Nov 29 03:09:13 though I doubt it Nov 29 03:09:17 DocScrutinizer05: again, it's definitely *not* the main problem I'm seeing that limits usability for me Nov 29 03:09:28 maybe not for you Nov 29 03:10:19 Raster and me detected it as a huge probelm while we still were developing gta02 Nov 29 03:10:19 I'm willing to believe it was a major problem with uboot, which had *significantly* longer wake up times. maybe also with other distributions (don't remember) Nov 29 03:10:34 oh, I forgot to mention ubifs as another significant factor Nov 29 03:11:16 you simply do not want a suspended device Nov 29 03:11:21 boot times are *way* lower with ubifs. I have a vague recollection that it affects wake up times as well, thogh I'm not entirely sure Nov 29 03:11:58 there's a metric shitton of wake-IRQ reasons that you don't want the device to spend seconds to service Nov 29 03:12:42 heck, GTA02 wasn't even able to wake up to tell user that connectivity got lost Nov 29 03:13:34 do other phones do that? Nov 29 03:13:40 not even to mention low battery or other events Nov 29 03:13:48 of course Nov 29 03:14:02 N900 / maemo is *always on* Nov 29 03:14:13 just irling in zeroclock Nov 29 03:14:17 idling Nov 29 03:14:23 that's not what I am asking Nov 29 03:14:35 amd it uses as little as <10mA on that Nov 29 03:15:01 I don't think I have ever seen a phone in some way notifying the user of lost connectivity, until you actually try to do calls or send messages Nov 29 03:15:07 so what is it you're asking? Nov 29 03:15:09 i.e. when it's active Nov 29 03:15:43 well, then look at mine, when I start the script doing exactly that Nov 29 03:16:34 as for battery low, I'm not entirely sure... my phone definitely does tell me about low battery sometimes -- though I don't know whether the wakeup is actually triggered by low battery, or whether it just happens as a side effect of some other wakeup... Nov 29 03:17:12 see? *some other 'wakeup'* Nov 29 03:17:55 DocScrutinizer05: I said I don't know. I'm not sure what else could trigger a random wakeup though when there are no incoming calls or massages? Nov 29 03:18:38 to make a final point: N900 can have a 50 IRQ / second and still 'idle' a 99.6% in zeroclock and consume <10mA in that state Nov 29 03:19:00 as for your custom script, that doesn't in any way prove lack of something like that is a no-go, if it's not something regular consumer phones are actually doing... Nov 29 03:19:23 aha? Nov 29 03:19:36 well, whatever you say Nov 29 03:20:29 I get your point -- zeroclock is nice and possible -- I just don't see the lack of it as the major problem of the GTA02 design Nov 29 03:20:33 GTA02/04 is anyway the ONLY two devices I know that take several seconds between user unlocking the screen and device being ready for action Nov 29 03:21:29 is zeroclock used on Android? Nov 29 03:21:42 and we had *much* fun with it when we needed to stop modem from waking up the system for all the nice little negligible messages like "signal strength changed from 6 to 5" or somesuch Nov 29 03:22:15 yeah, typical smartphones take about 1 s from what I have seen, as opposed to 2 s I have on my freerunner... slightly annoying, but not a major dealbreaker IMHO Nov 29 03:22:24 zeroclock is used on all phones (except GTA02/4) but Android freezes background tasks Nov 29 03:23:58 at least most of them Nov 29 03:24:26 you can aboid that given you got sufficient permissions and knowledge about those err wakelocks(?) Nov 29 03:25:31 my understanding was that wakelocks are just a way to prevent suspend when certain functionality is in use that requires the device to be active (such as GPS etc.) Nov 29 03:25:40 but I haven't really studied it, so might be wrong Nov 29 03:25:46 maemo follows another approach assuming app devels were competent enough to NOT code busy loops or polls or whatever shite, so all tasks are always running Nov 29 03:26:38 define: "device active" Nov 29 03:27:01 thats a pretty big assumption ;) Nov 29 03:27:03 a wakelock tells the scheduler to not freeze the task Nov 29 03:27:26 at least as far as I understand that stuff Nov 29 03:28:30 never looked too closely into it, android is pretty much fubar from a system design POV Nov 29 03:29:24 "A wake lock is a mechanism to indicate that your application needs to have the device stay on." Nov 29 03:29:57 (pretty big assumption) well, that's why there's maemo-extras-devel, maemo-extras-testing and maemo-extras repo Nov 29 03:30:25 have the devoce stay on still is undefined Nov 29 03:30:39 and that statement is BS Nov 29 03:31:33 it seems to be from official documentation Nov 29 03:31:45 I agree that "stay on" is fuzzy Nov 29 03:31:47 that doesn't help :-P Nov 29 03:32:07 it does seem to support my understanding of what wakelocks are Nov 29 03:32:23 it's a incompetent sw devel's view on how hw works Nov 29 03:32:24 but it doesn't really answer the question what typical android devices actually do when they are not active... Nov 29 03:32:58 they do zeroclock, I already told you Nov 29 03:33:17 they definitely go into *some* kind of suspend state -- but whether that is just stopping clocks, or actually powering down hardware units, is unclear Nov 29 03:33:28 I think the distinction is actually rather blurry nowadays Nov 29 03:34:02 no, from a hw perspective it's very clearly defined Nov 29 03:34:32 modern Intel systems with a dozen or so power states have a very wide range from just clocking down to shutting down power for an increasing number of components. I *suspect* ARM SoCs are not that much different in this regard... Nov 29 03:35:51 and most phone SoCs nowadays even use one (set of) CPU(s) in one chip for modem radio stack and application processor, so clearly those *never* will suspend in any other way than zeroclock whicjh has resume latencies in the microsecond range Nov 29 03:36:20 managing peripherals like GPS, screen, audio, whatever is a completely unrelated topic Nov 29 03:36:43 DocScrutinizer05: eh? first time I hear that modern SoCs have no dedicated cores for the baseband Nov 29 03:36:59 hah Nov 29 03:37:07 AFAIK it's actually the opposite: old-school feature phones often just had a single core... Nov 29 03:38:18 doesn't the baseband processor have to be somewhat active pretty much all of the time? Nov 29 03:38:26 yes Nov 29 03:38:31 exactly Nov 29 03:38:33 that's definitely not doable with the main cores of a smartphone SoC Nov 29 03:38:40 aha Nov 29 03:38:45 tell me more Nov 29 03:40:06 what do you think distinguishes the "main cores of a smartphone SoC" from the core that runs the radio stack? Nov 29 03:40:27 hint: they are identical ARM cores Nov 29 03:40:48 on at least one design I worked on at a modem manuf Nov 29 03:42:08 sure you usually will *assign* one of the cores to radio stack exclusively when you got multiple cores Nov 29 03:42:30 just for simplicity and lower overhead Nov 29 03:44:21 identical cores? I have a hard time believing that. sure, they are all ARM cores; but most likely different designs (A vs. M cores), plus they use different implementations optimised for performance vs. efficiency Nov 29 03:44:33 with pretty much the same measures you got e.g. in linux and windows too, for pinning a process to a certain (set of) core(s) Nov 29 03:45:08 no, all modems *need* at least A cores, M is waaay too weak Nov 29 03:47:01 https://en.wikipedia.org/wiki/NovaThor Nov 29 03:48:06 * pabs3 found this talk interesting, especially the multiple ISAs per chip thing: https://youtu.be/QTYiH1Y5UV0 Nov 29 03:49:55 antrik: in zero clock a A core doesn't really eat more power than an M core Nov 29 03:50:21 which is the whole point about zero clock and the low resume latency Nov 29 03:52:15 rush to idle, with sufficient computational power and speed, then zeroclock and don't eat more power than in suspend2ram state, while still being at 1.6Ghz in less than a microsecond as soon as any event (aka IRQ) happens Nov 29 03:53:22 DocScrutinizer05: I find it hard to believe that all cores have the same power consumption in zeroclock. but more importantly, we established that the baseband *can't* use zeroclock, as it is permanently active... Nov 29 03:53:35 the first amendment of all embedded, if you like to put it like that Nov 29 03:54:03 of course baseband does zeroclock, DUH! Nov 29 03:54:36 actually it idles for seconds between the short wakes Nov 29 03:55:16 BTW, on modern Intel CPUs, the lower power saving states have wakeup times way into the milisecond range. I suspect it's similar for modern ARM SoCs Nov 29 03:55:27 and it even turns down the RF-frontend and receiver during that Nov 29 03:56:11 no, since intel CPUs never were made for embedded Nov 29 03:56:28 DocScrutinizer05: I find that surprising, but since I don't know much about baseband, I'm willing to believe it... Nov 29 03:56:48 they don't do zeroclock afaik, they actually need to suspend cores Nov 29 03:57:27 zeroclock first of all means there are no dynamic storage cells in any registers, so you simply can shut down the clock and the CPU stops Nov 29 03:58:02 of course there are alsoo PLL and whatnot, that's a bit of special case, but generally speaking that's it Nov 29 03:58:23 DocScrutinizer05: again, there are a plethora of different states on modern Intel designs. some just stop the clock, some completely power down just the innermost units, some power down more units. the more they power down, the longer they take to get back to active state Nov 29 03:58:40 so? Nov 29 03:59:01 ARM has at least same complexity and granularity of power domain management Nov 29 03:59:42 so it's a wide scale between just zeroclock and full suspend; where the middle states save more power than just zeroclock Nov 29 04:00:00 if ARM has at least the same granularity, it must have similar intemediate states Nov 29 04:01:38 but what I'm talking? look at http://paste.opensuse.org/75095494 Nov 29 04:02:02 this is a device busy with charging Nov 29 04:02:28 when not hooked up to charger same thing looks less IRQ-flooded Nov 29 04:02:56 BTW, while the details evade me, I remember distinctly that the first x86 CPU with zero-clock capabilities existed a *long* time ago... might have been around the 486 age or so Nov 29 04:07:38 http://paste.opensuse.org/31099632 Nov 29 04:09:17 I have no more to add to this discussion Nov 29 04:37:18 in ^^^ you can see a few things. during the 30s observation window: CPU was busy for 3% (C0), diring that it was clocked @250MHz for 91.7% and at 600Mhz for the rest. During all that time we had an average of 43 IRQ/second which each single one woke up the CPU to service it. Yet the system consumed an average of (my averaging guess) -25mA during that time. It seems that WLAN has a wake schedule (for beacons?) of pretty much Nov 29 04:37:20 exactly 1/s Nov 29 04:38:25 and 97% ot those 30s the CPU was in different (zeroclock) idle states Nov 29 04:40:10 you also can see that the zzztop (perl script iirc) process had a wakeup latency of max 0,02s (("Actually slept for 30.020s")) Nov 29 04:41:09 ok that are 20ms which is waaay more than 1 microsecond, but... I think I made my point Nov 29 04:45:17 I have no idea what you are trying to say... **** ENDING LOGGING AT Wed Nov 30 03:00:00 2016