From: Andras Domokos <andras.domokos@nokia.com>
To: ofono@ofono.org
Subject: Re: [PATCH 0/5] Call Counters (2nd)
Date: Fri, 10 Dec 2010 10:14:26 +0200 [thread overview]
Message-ID: <4D01E162.8090000@nokia.com> (raw)
In-Reply-To: <1291935199.30085.7.camel@aeonflux.mpl.access-company.com>
[-- Attachment #1: Type: text/plain, Size: 3119 bytes --]
Hi,
On 12/10/2010 12:53 AM, ext Marcel Holtmann wrote:
> Hi Kai,
>
>
>>>> I share the concern for the IO/CPU cost, but I don't think it
>>>> matters much in which daemon this is done. Especially if some slack
>>>> is> allowed for the timers (which should be the case), ofonod will be
>>>> scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts
>>>> wake up pulseaudio).
>>>>
>>> this is not really true. We can not wakeup ofonod every single second.
>>> You might wanna start running powertop.
>>>
>> uhm, but I'm not claiming that. I was just stating that moving
>> the timers to e.g. pulseaudio in this case won't save much if
>> anything (the CPU will be woken up anyways, and the cost between
>> scheduling ofonod or a thread from PA, has really no difference
>> to overall consumption.. the CPU is woken up anyways and roughly
>> the same code to handle the timer is run).
>>
>> So whether this code is in oFono or elsewhere, does not matter
>> much (to overall power consumption). The main question is of course
>> how often the counters are synced.
>>
> actually it does matter since you have no extra context switch and in
> addition you not accidentally wake up PA and then ofonod. You have one
> centralized wakeup of one thread.
>
> Of course this should be smart and done along with the PA audio
> processing and not async to that one.
>
> If we consider that the only sensible thing is to track the actual
> talking time, then PA becomes a nice choice for this.
>
> This doesn't mean that you should be implementing it, but I am still
> maintaining that this would be a pretty damn smart way of solving this
> efficiently.
>
>
Obviously, there are many implementation options, we have to
decide only about whether we want to have this implemented
in oFono or not, or in first place, whether the feature is needed
at all or not. For the latter part I am collecting more info from
our people.
>> Personally I think the every-10sec interval is too short.
>> It's also highly system specific when wakeups start to get
>> too costly, so picking up one value seems difficult.
>>
> My take here is that a granularity of 1 minute is enough.
>
> Doing this every 10 seconds and displaying it on a per second level
> sounds insane to me.
>
That second level D-Bus query of the call counters should be forgotten,
probably is not going to happen and anyways, querying is something
that can be controlled/tuned outside ofono. In fact any method can be
"abused" in a similar way, is not oFono's responsibility to prevent such
"misuse" from happening.
There is a single value to tune, the sync interval, we can either settle
on a reasonable value, or we can make it a configurable parameter (the
default value would disable the periodic syncing), then everybody can
do whatever with its own product.
> Regards
>
> Marcel
>
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
>
Regards,
Andras
next prev parent reply other threads:[~2010-12-10 8:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 16:25 [PATCH 0/5] Call Counters (2nd) Andras Domokos
2010-11-22 16:25 ` [RFC PATCH 1/5] history: expand history API include file Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 2/5] history: expand history API Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 3/5] voicecall: take into use the new history function Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 4/5] plugins: add call counters Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 5/5] doc: call counters API doc Andras Domokos
2010-12-07 12:57 ` [PATCH 0/5] Call Counters (2nd) Aki Niemi
2010-12-07 18:33 ` Denis Kenzior
2010-12-08 9:03 ` Marcel Holtmann
2010-12-08 9:34 ` Aki Niemi
2010-12-08 12:41 ` Marcel Holtmann
2010-12-08 13:28 ` Mika.Liljeberg
2010-12-08 16:01 ` Andras Domokos
2010-12-08 16:12 ` Marcel Holtmann
2010-12-08 17:30 ` Andras Domokos
2010-12-08 22:32 ` Marcel Holtmann
2010-12-08 21:02 ` Kai.Vehmanen
2010-12-08 22:35 ` Marcel Holtmann
2010-12-09 12:25 ` Kai.Vehmanen
2010-12-09 18:10 ` Marcel Holtmann
2010-12-09 19:52 ` Kai.Vehmanen
2010-12-09 22:53 ` Marcel Holtmann
2010-12-10 8:14 ` Andras Domokos [this message]
2010-12-10 17:57 ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2010-12-10 18:34 ` Marcel Holtmann
2010-12-10 23:57 ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2010-12-11 14:57 ` Marcel Holtmann
2010-12-13 7:56 ` Kai.Vehmanen
2010-12-12 15:46 ` Kai.Vehmanen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D01E162.8090000@nokia.com \
--to=andras.domokos@nokia.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.