4:25 p.m.
Here a proposal for call counters implementation for keeping track
of the total incoming and outgoing call duration counters. Each
established call instance is contributing to either of the call
duration counters. The 2 counters are updated periodically when
there is an established call and the information is stored in
a file. The bookkeeping of the call duration counters are per IMSI
number.
The implementation makes use of the history framework which had to be
expanded with a function for marking the beginning of a voice call.
There is a D-Bus interface to call counters for reading and clearing
the counters.
Andras Domokos (5):
history: expand history API include file
history: expand history API
voicecall: take into use the new history function
plugins: add call counters
doc: call counters API doc
Makefile.am | 3 +
doc/callcounters-api.txt | 18 ++
include/history.h | 3 +
plugins/callcounters.c | 388 ++++++++++++++++++++++++++++++++++++++++++++++
src/history.c | 24 +++
src/ofono.h | 4 +
src/voicecall.c | 3 +
7 files changed, 443 insertions(+), 0 deletions(-)
create mode 100644 doc/callcounters-api.txt
create mode 100644 plugins/callcounters.c
4:25 p.m.
New subject: [RFC PATCH 1/5] history: expand history API include file
---
include/history.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/history.h b/include/history.h
index c1c4aa1..a2490f6 100644
--- a/include/history.h
+++ b/include/history.h
@@ -49,6 +49,9 @@ struct ofono_history_driver {
const char *name;
int (*probe)(struct ofono_history_context *context);
void (*remove)(struct ofono_history_context *context);
+ void (*call_started)(struct ofono_history_context *context,
+ const struct ofono_call *call,
+ time_t start);
void (*call_ended)(struct ofono_history_context *context,
const struct ofono_call *call,
time_t start, time_t end);
--
1.7.0.4
4:26 p.m.
New subject: [RFC PATCH 2/5] history: expand history API
---
src/history.c | 24 ++++++++++++++++++++++++
src/ofono.h | 4 ++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/src/history.c b/src/history.c
index 0229cf5..31efadb 100644
--- a/src/history.c
+++ b/src/history.c
@@ -114,6 +114,30 @@ void __ofono_history_probe_drivers(struct ofono_modem *modem)
}
}
+static void history_call_started(struct ofono_atom *atom, void *data)
+{
+ struct ofono_history_context *context = __ofono_atom_get_data(atom);
+ struct history_call_foreach_data *hfd = data;
+
+ if (context->driver->call_started == NULL)
+ return;
+
+ context->driver->call_started(context, hfd->call, hfd->start);
+}
+
+void __ofono_history_call_started(struct ofono_modem *modem,
+ const struct ofono_call *call,
+ time_t start)
+{
+ struct history_call_foreach_data hfd;
+
+ hfd.call = call;
+ hfd.start = start;
+
+ __ofono_modem_foreach_atom(modem, OFONO_ATOM_TYPE_HISTORY,
+ history_call_started, &hfd);
+}
+
static void history_call_ended(struct ofono_atom *atom, void *data)
{
struct ofono_history_context *context = __ofono_atom_get_data(atom);
diff --git a/src/ofono.h b/src/ofono.h
index 4d76d20..61a0637 100644
--- a/src/ofono.h
+++ b/src/ofono.h
@@ -368,6 +368,10 @@ void __ofono_netreg_set_base_station_name(struct ofono_netreg
*netreg,
void __ofono_history_probe_drivers(struct ofono_modem *modem);
+void __ofono_history_call_started(struct ofono_modem *modem,
+ const struct ofono_call *call,
+ time_t start);
+
void __ofono_history_call_ended(struct ofono_modem *modem,
const struct ofono_call *call,
time_t start, time_t end);
--
1.7.0.4
4:26 p.m.
New subject: [RFC PATCH 3/5] voicecall: take into use the new history function
---
src/voicecall.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/voicecall.c b/src/voicecall.c
index bd64432..b40d284 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -630,6 +630,7 @@ static void voicecall_emit_multiparty(struct voicecall *call, gboolean
mpty)
static void voicecall_set_call_status(struct voicecall *call, int status)
{
+ struct ofono_modem *modem = __ofono_atom_get_modem(call->vc->atom);
DBusConnection *conn = ofono_dbus_get_connection();
const char *path;
const char *status_str;
@@ -658,6 +659,8 @@ static void voicecall_set_call_status(struct voicecall *call, int
status)
const char *timestr;
call->start_time = time(NULL);
+ __ofono_history_call_started(modem, call->call,
+ call->start_time);
timestr = time_to_str(&call->start_time);
ofono_dbus_signal_property_changed(conn, path,
--
1.7.0.4
4:26 p.m.
New subject: [RFC PATCH 4/5] plugins: add call counters
---
Makefile.am | 3 +
plugins/callcounters.c | 388 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 391 insertions(+), 0 deletions(-)
create mode 100644 plugins/callcounters.c
diff --git a/Makefile.am b/Makefile.am
index f841b4c..7ae4a74 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -295,6 +295,9 @@ builtin_modules += example_nettime
builtin_sources += examples/nettime.c
endif
+builtin_modules += cc
+builtin_sources += plugins/callcounters.c
+
builtin_modules += smart_messaging
builtin_sources += plugins/smart-messaging.c
diff --git a/plugins/callcounters.c b/plugins/callcounters.c
new file mode 100644
index 0000000..a1306e5
--- /dev/null
+++ b/plugins/callcounters.c
@@ -0,0 +1,388 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2009-2010 Nokia Corporation and/or its subsidiary(-ies).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <string.h>
+#include <time.h>
+#include <glib.h>
+#include <gdbus.h>
+
+#include "ofono.h"
+
+#include "common.h"
+#include "storage.h"
+
+#define CC_TIMEOUT 10000
+#define CC_STORE "callcounters"
+#define CC_GROUP "CallCounters"
+#define CC_INTERFACE "org.ofono.CallCounters"
+
+struct call_item {
+ unsigned int id;
+ int dir;
+ time_t start_time;
+};
+
+struct call_counters {
+ struct ofono_history_context *context;
+ const char *imsi;
+ GKeyFile *file;
+ time_t ibase;
+ time_t obase;
+ time_t incoming;
+ time_t outgoing;
+ gint timeout_source;
+ GSList *calls;
+};
+
+static time_t cc_time()
+{
+ struct timespec now;
+
+ clock_gettime(CLOCK_MONOTONIC, &now);
+
+ return now.tv_sec;
+}
+
+static gboolean cc_no_calls(struct call_counters *cc)
+{
+ return cc->calls == NULL;
+}
+
+static struct call_item *cc_find_ci(struct call_counters *cc, unsigned int id)
+{
+ struct call_item *ci;
+ GSList *l;
+
+ for (l = cc->calls; l; l = l->next) {
+ ci = l->data;
+ if (ci->id == id)
+ return ci;
+ }
+
+ return NULL;
+}
+
+static void cc_load(struct call_counters *cc)
+{
+ struct ofono_modem *modem = cc->context->modem;
+ struct ofono_atom *atom;
+ struct ofono_sim *sim;
+ GError *error1 = NULL, *error2 = NULL;
+
+ cc->incoming = cc->ibase = 0;
+ cc->outgoing = cc->obase = 0;
+
+ atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
+ sim = __ofono_atom_get_data(atom);
+
+ cc->imsi = ofono_sim_get_imsi(sim);
+ if (cc->imsi == NULL)
+ return;
+
+ cc->file = storage_open(cc->imsi, CC_STORE);
+ if (cc->file == NULL)
+ return;
+
+ cc->incoming = g_key_file_get_integer(cc->file, CC_GROUP,
+ "Incoming", &error1);
+
+ if (error1) {
+ g_key_file_set_integer(cc->file, CC_GROUP,
+ "Incoming", cc->incoming);
+ storage_sync(cc->imsi, CC_STORE, cc->file);
+ }
+
+ cc->ibase = cc->incoming;
+
+ cc->outgoing = g_key_file_get_integer(cc->file, CC_GROUP,
+ "Outgoing", &error2);
+
+ if (error2) {
+ g_key_file_set_integer(cc->file, CC_GROUP,
+ "Outgoing", cc->outgoing);
+ }
+
+ cc->obase = cc->outgoing;
+
+ if (error1 != NULL || error2 != NULL)
+ storage_sync(cc->imsi, CC_STORE, cc->file);
+}
+
+static void cc_save(struct call_counters *cc)
+{
+ if (cc->file == NULL)
+ return;
+
+ g_key_file_set_integer(cc->file, CC_GROUP,
+ "Incoming", cc->incoming);
+ g_key_file_set_integer(cc->file, CC_GROUP,
+ "Outgoing", cc->outgoing);
+ storage_sync(cc->imsi, CC_STORE, cc->file);
+}
+
+static void cc_close(struct call_counters *cc)
+{
+ if (cc->file)
+ storage_close(cc->imsi, CC_STORE, cc->file, TRUE);
+
+ cc->file = NULL;
+}
+
+static void cc_update(struct call_counters *cc, struct call_item *ci)
+{
+ time_t now = cc_time();
+ time_t idiff = 0, odiff = 0;
+ struct call_item *lci;
+ GSList *l;
+
+ for (l = cc->calls; l; l = l->next) {
+ lci = l->data;
+ if (lci->dir == CALL_DIRECTION_MOBILE_ORIGINATED) {
+ if (lci != ci)
+ odiff += now - lci->start_time;
+ else
+ cc->obase += now - lci->start_time;
+ } else {
+ if (lci != ci)
+ idiff += now - lci->start_time;
+ else
+ cc->ibase += now - lci->start_time;
+ }
+ }
+
+ cc->outgoing = cc->obase + odiff;
+ cc->incoming = cc->ibase + idiff;
+
+ cc_save(cc);
+}
+
+static gboolean cc_timeout(gpointer user_data)
+{
+ struct call_counters *cc = user_data;
+ cc_update(cc, NULL);
+ return TRUE;
+}
+
+static DBusMessage *cc_dbus_get(DBusConnection *conn,
+ DBusMessage *msg, void *data)
+{
+ struct call_counters *cc = data;
+ DBusMessage *reply;
+ DBusMessageIter iter;
+ DBusMessageIter dict;
+
+ if (cc_no_calls(cc)) {
+ cc_load(cc);
+ cc_close(cc);
+ } else {
+ cc_update(cc, NULL);
+ }
+
+ reply = dbus_message_new_method_return(msg);
+ if (!reply)
+ return NULL;
+
+ dbus_message_iter_init_append(reply, &iter);
+ dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
+ OFONO_PROPERTIES_ARRAY_SIGNATURE,
+ &dict);
+ ofono_dbus_dict_append(&dict, "Incoming", DBUS_TYPE_UINT32,
+ &cc->incoming);
+ ofono_dbus_dict_append(&dict, "Outgoing", DBUS_TYPE_UINT32,
+ &cc->outgoing);
+ dbus_message_iter_close_container(&iter, &dict);
+
+ return reply;
+}
+
+static DBusMessage *cc_dbus_clear(DBusConnection *conn,
+ DBusMessage *msg, void *data)
+{
+ struct call_counters *cc = data;
+ DBusMessage *reply;
+
+ if (cc_no_calls(cc)) {
+ cc_load(cc);
+ cc->incoming = cc->ibase = 0;
+ cc->outgoing = cc->obase = 0;
+ cc_save(cc);
+ cc_close(cc);
+ reply = dbus_message_new_method_return(msg);
+ } else {
+ reply = __ofono_error_failed(msg);
+ }
+
+ return reply;
+}
+
+static GDBusMethodTable cc_methods[] = {
+ {"Get", "", "a{sv}", cc_dbus_get},
+ {"Clear", "", "", cc_dbus_clear},
+ { }
+};
+
+static void cc_dbus_register(struct call_counters *cc)
+{
+ DBusConnection *conn = ofono_dbus_get_connection();
+ const char *path = ofono_modem_get_path(cc->context->modem);
+
+ if (!g_dbus_register_interface(conn, path,
+ CC_INTERFACE,
+ cc_methods, NULL, NULL,
+ cc, NULL)) {
+ ofono_error("Could not create %s interface", CC_INTERFACE);
+ return;
+ }
+
+ ofono_modem_add_interface(cc->context->modem, CC_INTERFACE);
+}
+
+static gboolean cc_dbus_unregister(struct call_counters *cc)
+{
+ DBusConnection *conn = ofono_dbus_get_connection();
+ const char *path = ofono_modem_get_path(cc->context->modem);
+
+ ofono_modem_remove_interface(cc->context->modem, CC_INTERFACE);
+
+ return g_dbus_unregister_interface(conn, path, CC_INTERFACE);
+}
+
+static int cc_probe(struct ofono_history_context *context)
+{
+ struct call_counters *cc;
+
+ ofono_debug("Call Counters probe for modem: %p", context->modem);
+
+ cc = g_try_new0(struct call_counters, 1);
+ if (cc == NULL)
+ return -1;
+
+ context->data = cc;
+ cc->context = context;
+ cc_dbus_register(cc);
+
+ return 0;
+}
+
+static void cc_remove(struct ofono_history_context *context)
+{
+ struct call_counters *cc = context->data;
+
+ ofono_debug("Call Counters remove for modem: %p", context->modem);
+
+ cc_dbus_unregister(cc);
+
+ if (cc->timeout_source != 0)
+ g_source_remove(cc->timeout_source);
+
+ cc_update(cc, NULL);
+ g_slist_free(cc->calls);
+
+ if (cc->file)
+ storage_close(cc->imsi, CC_STORE, cc->file, TRUE);
+
+ g_free(context->data);
+}
+
+static void cc_call_started(struct ofono_history_context *context,
+ const struct ofono_call *call, time_t start)
+{
+ time_t now = cc_time();
+ struct call_counters *cc = context->data;
+ struct call_item *ci;
+
+ ofono_debug("Call started on modem: %p", context->modem);
+
+ if (call->type != 0)
+ return;
+
+ ci = g_try_new0(struct call_item, 1);
+ if (ci == NULL)
+ return;
+
+ if (cc_no_calls(cc))
+ cc_load(context->data);
+
+ ci->id = call->id;
+ ci->dir = call->direction;
+ ci->start_time = now;
+ cc->calls = g_slist_append(cc->calls, ci);
+
+ if (cc->timeout_source == 0)
+ cc->timeout_source = g_timeout_add(CC_TIMEOUT, cc_timeout, cc);
+}
+
+static void cc_call_ended(struct ofono_history_context *context,
+ const struct ofono_call *call,
+ time_t start, time_t end)
+{
+ struct call_counters *cc = context->data;
+ struct call_item *ci = cc_find_ci(cc, call->id);
+
+ ofono_debug("Call ended on modem: %p", context->modem);
+
+ if (call->type != 0)
+ return;
+
+ if (ci == NULL)
+ return;
+
+ cc_update(cc, ci);
+ cc->calls = g_slist_remove(cc->calls, ci);
+
+ if (cc_no_calls(cc)) {
+ if (cc->timeout_source != 0)
+ g_source_remove(cc->timeout_source);
+
+ cc->timeout_source = 0;
+
+ if (cc->file)
+ storage_close(cc->imsi, CC_STORE, cc->file, TRUE);
+
+ cc->file = NULL;
+ }
+}
+
+static struct ofono_history_driver cc_driver = {
+ .name = "Call Counters",
+ .probe = cc_probe,
+ .remove = cc_remove,
+ .call_started = cc_call_started,
+ .call_ended = cc_call_ended,
+};
+
+static int cc_init(void)
+{
+ return ofono_history_driver_register(&cc_driver);
+}
+
+static void cc_exit(void)
+{
+ ofono_history_driver_unregister(&cc_driver);
+}
+
+OFONO_PLUGIN_DEFINE(cc, "Call Counters plugin",
+ VERSION, OFONO_PLUGIN_PRIORITY_DEFAULT,
+ cc_init, cc_exit)
--
1.7.0.4
4:26 p.m.
New subject: [RFC PATCH 5/5] doc: call counters API doc
---
doc/callcounters-api.txt | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 doc/callcounters-api.txt
diff --git a/doc/callcounters-api.txt b/doc/callcounters-api.txt
new file mode 100644
index 0000000..271d9f4
--- /dev/null
+++ b/doc/callcounters-api.txt
@@ -0,0 +1,18 @@
+CallCounters hierarchy
+======================
+
+Service org.ofono
+Interface org.ofono.CallCounters
+Object path [variable prefix]/{modem0,modem1,...}
+
+Methods dict Get()
+
+ Returns the total duration in seconds of the incoming
+ and outgoing calls. Separate counters are maintained for
+ each SIM card.
+
+ void Clear()
+ Resets the call duration counters to 0. The operation
+ succeeds only if there are no ongoing calls.
+
+ Possible Errors: [service].Error.Failed
--
1.7.0.4
12:57 p.m.
Hi Andras,
2010/11/22 Andras Domokos <Andras.Domokos(a)nokia.com>:
Here a proposal for call counters implementation for keeping track
of the total incoming and outgoing call duration counters. Each
established call instance is contributing to either of the call
duration counters. The 2 counters are updated periodically when
there is an established call and the information is stored in
a file. The bookkeeping of the call duration counters are per IMSI
number.
The implementation makes use of the history framework which had to be
expanded with a function for marking the beginning of a voice call.
There is a D-Bus interface to call counters for reading and clearing
the counters.
This set looks good to me, and I believe you fixed the issues from
previous review comments. Denis, are you ok with this?
Cheers,
Aki
6:33 p.m.
Hi Aki,
On 12/07/2010 06:57 AM, Aki Niemi wrote:
Hi Andras,
2010/11/22 Andras Domokos <Andras.Domokos(a)nokia.com>:
> Here a proposal for call counters implementation for keeping track
> of the total incoming and outgoing call duration counters. Each
> established call instance is contributing to either of the call
> duration counters. The 2 counters are updated periodically when
> there is an established call and the information is stored in
> a file. The bookkeeping of the call duration counters are per IMSI
> number.
> The implementation makes use of the history framework which had to be
> expanded with a function for marking the beginning of a voice call.
> There is a D-Bus interface to call counters for reading and clearing
> the counters.
This set looks good to me, and I believe you fixed the issues from
previous review comments. Denis, are you ok with this?
I'm still catching up, let me take another look.
Regards,
-Denis
9:03 a.m.
Hi Aki,
> Here a proposal for call counters implementation for keeping
track
> of the total incoming and outgoing call duration counters. Each
> established call instance is contributing to either of the call
> duration counters. The 2 counters are updated periodically when
> there is an established call and the information is stored in
> a file. The bookkeeping of the call duration counters are per IMSI
> number.
> The implementation makes use of the history framework which had to be
> expanded with a function for marking the beginning of a voice call.
> There is a D-Bus interface to call counters for reading and clearing
> the counters.
This set looks good to me, and I believe you fixed the issues from
previous review comments. Denis, are you ok with this?
so Denis and I talked about this a little bit and I am not fine with
this at all.
Lets take this one step and please explain to me what your requirements
and objectives are. I also wanna see a top to bottom from UI down to the
modem usage of this API.
My main concerns are here that we are waking up ofonod every 10 seconds
and consuming heavy IO with writing this information to disk. In
addition to that there is no clear UI usage for the getter API.
What are the granularity there. What is the expected user experience
with this API. I don't see any clear usage model here.
In addition to that, what is the problem with just updating the stats
after the call has ended?
Are you really expecting realtime updates of call time stats for some
hidden UI stats menu? This would be a really expensive change for just
doing that.
Has anybody looked at how we are doing realtime stats inside ConnMan?
Regards
Marcel
9:34 a.m.
Hi Marcel,
2010/12/8 Marcel Holtmann <marcel(a)holtmann.org>:
so Denis and I talked about this a little bit and I am not fine with
this at all.
Next time, can you invite me to join your little talk?
Lets take this one step and please explain to me what your
requirements
and objectives are. I also wanna see a top to bottom from UI down to the
modem usage of this API.
We need a UI showing total MO and MT call times. They also need to be
able to be reset, if the user so wishes. The data needs to be
reasonably reliable.
and consuming heavy IO with writing this information to disk. In
addition to that there is no clear UI usage for the getter API.
What do you mean? Do you mean your iPhone has no such UI?
The reason these are not properties is just because it makes no sense
to update the counters "live". The UI can poll if it so wishes, but
the poll interval is not something we want to decide.
What are the granularity there. What is the expected user experience
with this API. I don't see any clear usage model here.
In addition to that, what is the problem with just updating the stats
after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference
call, your timers are not updated and become worthless. Obviously,
this is a compromise between how reliable the counters are and how
many wakeups and IO we can bear.
Andras has some data on what reasonable reliability here means.
Cheers,
Aki
12:41 p.m.
Hi Aki,
> so Denis and I talked about this a little bit and I am not fine
with
> this at all.
Next time, can you invite me to join your little talk?
because you are not sitting next to me right now ;)
> Lets take this one step and please explain to me what your
requirements
> and objectives are. I also wanna see a top to bottom from UI down to the
> modem usage of this API.
We need a UI showing total MO and MT call times. They also need to be
able to be reset, if the user so wishes. The data needs to be
reasonably reliable.
Fair enough, but when I look at such a feature as a whole, then my
question is when does it need to be shown? What is your user interaction
requirement with this data?
Andras, please explain what reasonable reliable means.
> and consuming heavy IO with writing this information to disk.
In
> addition to that there is no clear UI usage for the getter API.
What do you mean? Do you mean your iPhone has no such UI?
I have actually tested this with an iPhone and it has such an UI
element, but it is not realtime. It gets updated after the call has been
completed.
So why can't we just update/reset this in Tracker via the history plugin
in a general way. I am failing to see the need for this inside oFono. It
seems to me that doing this within the scope of the Tracker integration
is a lot cleaner and better for CPU and IO usage.
The reason these are not properties is just because it makes no
sense
to update the counters "live". The UI can poll if it so wishes, but
the poll interval is not something we want to decide.
> What are the granularity there. What is the expected user experience
> with this API. I don't see any clear usage model here.
>
> In addition to that, what is the problem with just updating the stats
> after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference
call, your timers are not updated and become worthless. Obviously,
this is a compromise between how reliable the counters are and how
many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't
the system daemon just shutdown all calls when the battery reaches
critical limit.
You will never fully run down the battery anyway. One of the system
health components in the system will prevent it and then can cleanly
shutdown oFono and thus all calls. The only case where the system could
potentially misfunction in this area would be an emergency call. But
that is a total different use case anyway.
Regards
Marcel
1:28 p.m.
Hi,
> Because if your battery runs out in the middle of a 4 hour
conference
> call, your timers are not updated and become worthless. Obviously,
> this is a compromise between how reliable the counters are and how
> many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't
the system daemon just shutdown all calls when the battery reaches
critical limit.
You will never fully run down the battery anyway. One of the system
health components in the system will prevent it and then can cleanly
shutdown oFono and thus all calls. The only case where the
system could
potentially misfunction in this area would be an emergency call. But
that is a total different use case anyway.
There are other ways in which the device might reset without warning:
- hardware glitch triggering an involuntary reset
- software glitch triggering an involuntary reset
- device drops and battery connection is momentarily broken when it hits the ground
- user rips out the battery in mid-use
While periodically syncing call and data counters to permanent memory is by no means
appealing, we have certain accuracy requirements for the stored counters. The only way
those requirements can be met is by syncing the counters to storage at reasonable
intervals. Whether this should be part of oFono is a matter for discussion, I guess, but
at minimum we need to have the enablers to do this.
MikaL
4:01 p.m.
Hi,
On 12/08/2010 02:41 PM, ext Marcel Holtmann wrote:
Hi Aki,
>> so Denis and I talked about this a little bit and I am not fine with
>> this at all.
>>
> Next time, can you invite me to join your little talk?
>
because you are not sitting next to me right now ;)
>> Lets take this one step and please explain to me what your requirements
>> and objectives are. I also wanna see a top to bottom from UI down to the
>> modem usage of this API.
>>
> We need a UI showing total MO and MT call times. They also need to be
> able to be reset, if the user so wishes. The data needs to be
> reasonably reliable.
>
Fair enough, but when I look at such a feature as a whole, then my
question is when does it need to be shown? What is your user interaction
requirement with this data?
Andras, please explain what reasonable reliable means.
The call counters are shown to the user when he or she opens up
an application/applet whatever UI component that is meant for
showing this information.
Coming to the reliability part, saving the call counters information
often enough, gives us sort of hard guarantee that whatever happens
with any subsystem, be that SW or HW, the call counters will stay enough
accurate. Syncing to the permanent storage, based on our product
requirements, should take place in fact every 5 sec, or could be
configurable.
There might be some liability issues if for some reason the counters would
"loose" time, the user my blame the phone manufacturer for the extra
expenses incurred by inaccurate counters.
>> and consuming heavy IO with writing this information to disk.
In
>> addition to that there is no clear UI usage for the getter API.
>>
> What do you mean? Do you mean your iPhone has no such UI?
>
I have actually tested this with an iPhone and it has such an UI
element, but it is not realtime. It gets updated after the call has been
completed.
So why can't we just update/reset this in Tracker via the history plugin
in a general way. I am failing to see the need for this inside oFono. It
seems to me that doing this within the scope of the Tracker integration
is a lot cleaner and better for CPU and IO usage.
We can discuss the place of the call counters plugin, but I think using the
ofono history framework is a reasonable choice, with the note that the it
needs to be expanded with a history function called in the beginning
of a call.
The call counters plugin could be an optionally compiled/included (dynamic)
plugin or "downgraded" to experimental status.
> The reason these are not properties is just because it makes no sense
> to update the counters "live". The UI can poll if it so wishes, but
> the poll interval is not something we want to decide.
>
>
>> What are the granularity there. What is the expected user experience
>> with this API. I don't see any clear usage model here.
>>
>> In addition to that, what is the problem with just updating the stats
>> after the call has ended?
>>
> Because if your battery runs out in the middle of a 4 hour conference
> call, your timers are not updated and become worthless. Obviously,
> this is a compromise between how reliable the counters are and how
> many wakeups and IO we can bear.
>
I think this is not a good idea to have oFono handles this. Why can't
the system daemon just shutdown all calls when the battery reaches
critical limit.
You will never fully run down the battery anyway. One of the system
health components in the system will prevent it and then can cleanly
shutdown oFono and thus all calls. The only case where the system could
potentially misfunction in this area would be an emergency call. But
that is a total different use case anyway.
It was already pointed out by Mika Liljeberg there could be cases when we
might not get the chance to sync our data. We need to be prepared to cope
with such cases as well (syncing the data often "enough").
Regards
Marcel
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
Regards,
Andras
4:12 p.m.
Hi Andras,
>>> Lets take this one step and please explain to me what
your requirements
>>> and objectives are. I also wanna see a top to bottom from UI down to the
>>> modem usage of this API.
>>>
>> We need a UI showing total MO and MT call times. They also need to be
>> able to be reset, if the user so wishes. The data needs to be
>> reasonably reliable.
>>
> Fair enough, but when I look at such a feature as a whole, then my
> question is when does it need to be shown? What is your user interaction
> requirement with this data?
>
> Andras, please explain what reasonable reliable means.
>
>
The call counters are shown to the user when he or she opens up
an application/applet whatever UI component that is meant for
showing this information.
do we have a clear use case requirement from an UI point of view on how
this is expected to be working.
I checked with my iPhone and how it does it. Basically it just updates
after the call and only after you re-entered that menu.
So here again, do we have a requirement to make this realtime or not.
And I mean that from an user interaction point of view.
Coming to the reliability part, saving the call counters information
often enough, gives us sort of hard guarantee that whatever happens
with any subsystem, be that SW or HW, the call counters will stay enough
accurate. Syncing to the permanent storage, based on our product
requirements, should take place in fact every 5 sec, or could be
configurable.
Writing and syncing something to disk every 5 seconds costs us IO. Is
this really a sacrifice that is acceptable.
There might be some liability issues if for some reason the counters
would
"loose" time, the user my blame the phone manufacturer for the extra
expenses incurred by inaccurate counters.
To be honest the counters can not be considered accurate anyway. Only
the billing system has the final say.
>>> and consuming heavy IO with writing this information to
disk. In
>>> addition to that there is no clear UI usage for the getter API.
>>>
>> What do you mean? Do you mean your iPhone has no such UI?
>>
> I have actually tested this with an iPhone and it has such an UI
> element, but it is not realtime. It gets updated after the call has been
> completed.
>
> So why can't we just update/reset this in Tracker via the history plugin
> in a general way. I am failing to see the need for this inside oFono. It
> seems to me that doing this within the scope of the Tracker integration
> is a lot cleaner and better for CPU and IO usage.
>
We can discuss the place of the call counters plugin, but I think using the
ofono history framework is a reasonable choice, with the note that the it
needs to be expanded with a history function called in the beginning
of a call.
The call counters plugin could be an optionally compiled/included (dynamic)
plugin or "downgraded" to experimental status.
So I am actually thinking that doing that inside PulseAudio is a lot
more efficient solution.
The idea is that PA already runs in the user session and has to monitor
the uplink/downlink state (and additionally could monitor call states as
well if needed). So it knows when a call is active and it is active
anyway doing the audio processing. So it could just then go ahead and
write your call accounting into Tracker.
Would such an architecture work for you guys?
>> The reason these are not properties is just because it makes
no sense
>> to update the counters "live". The UI can poll if it so wishes, but
>> the poll interval is not something we want to decide.
>>
>>
>>> What are the granularity there. What is the expected user experience
>>> with this API. I don't see any clear usage model here.
>>>
>>> In addition to that, what is the problem with just updating the stats
>>> after the call has ended?
>>>
>> Because if your battery runs out in the middle of a 4 hour conference
>> call, your timers are not updated and become worthless. Obviously,
>> this is a compromise between how reliable the counters are and how
>> many wakeups and IO we can bear.
>>
> I think this is not a good idea to have oFono handles this. Why can't
> the system daemon just shutdown all calls when the battery reaches
> critical limit.
>
> You will never fully run down the battery anyway. One of the system
> health components in the system will prevent it and then can cleanly
> shutdown oFono and thus all calls. The only case where the system could
> potentially misfunction in this area would be an emergency call. But
> that is a total different use case anyway.
>
It was already pointed out by Mika Liljeberg there could be cases when we
might not get the chance to sync our data. We need to be prepared to cope
with such cases as well (syncing the data often "enough").
Are these cases are really real life problems. For example with devices
moving toward hotswap SIM cards, the exchange of battery and
accidentally (or on purpose) removal seems to become more and more
unrealistic.
Regards
Marcel
5:30 p.m.
Hi Marcel,
On 12/08/2010 06:12 PM, ext Marcel Holtmann wrote:
Hi Andras,
>>>> Lets take this one step and please explain to me what your requirements
>>>> and objectives are. I also wanna see a top to bottom from UI down to the
>>>> modem usage of this API.
>>>>
>>>>
>>> We need a UI showing total MO and MT call times. They also need to be
>>> able to be reset, if the user so wishes. The data needs to be
>>> reasonably reliable.
>>>
>>>
>> Fair enough, but when I look at such a feature as a whole, then my
>> question is when does it need to be shown? What is your user interaction
>> requirement with this data?
>>
>> Andras, please explain what reasonable reliable means.
>>
>>
>>
> The call counters are shown to the user when he or she opens up
> an application/applet whatever UI component that is meant for
> showing this information.
>
do we have a clear use case requirement from an UI point of view on how
this is expected to be working.
In our case, it is expected to have the counters information shown to the
user continuously updated with about 1 second granularity, as long as the
user keeps opened the UI showing the counters. This practically means
"live" call counters in the UI.
I checked with my iPhone and how it does it. Basically it just
updates
after the call and only after you re-entered that menu.
So here again, do we have a requirement to make this realtime or not.
And I mean that from an user interaction point of view.
> Coming to the reliability part, saving the call counters information
> often enough, gives us sort of hard guarantee that whatever happens
> with any subsystem, be that SW or HW, the call counters will stay enough
> accurate. Syncing to the permanent storage, based on our product
> requirements, should take place in fact every 5 sec, or could be
> configurable.
>
Writing and syncing something to disk every 5 seconds costs us IO. Is
this really a sacrifice that is acceptable.
I agree, from pure technical point of view it's a costly operation.
> There might be some liability issues if for some reason the
counters would
> "loose" time, the user my blame the phone manufacturer for the extra
> expenses incurred by inaccurate counters.
>
To be honest the counters can not be considered accurate anyway. Only
the billing system has the final say.
I think any info we decide to show to the user has to be accurate enough,
otherwise becomes meaningless.
>>>> and consuming heavy IO with writing this information
to disk. In
>>>> addition to that there is no clear UI usage for the getter API.
>>>>
>>>>
>>> What do you mean? Do you mean your iPhone has no such UI?
>>>
>>>
>> I have actually tested this with an iPhone and it has such an UI
>> element, but it is not realtime. It gets updated after the call has been
>> completed.
>>
>> So why can't we just update/reset this in Tracker via the history plugin
>> in a general way. I am failing to see the need for this inside oFono. It
>> seems to me that doing this within the scope of the Tracker integration
>> is a lot cleaner and better for CPU and IO usage.
>>
>>
> We can discuss the place of the call counters plugin, but I think using the
> ofono history framework is a reasonable choice, with the note that the it
> needs to be expanded with a history function called in the beginning
> of a call.
> The call counters plugin could be an optionally compiled/included (dynamic)
> plugin or "downgraded" to experimental status.
>
So I am actually thinking that doing that inside PulseAudio is a lot
more efficient solution.
The idea is that PA already runs in the user session and has to monitor
the uplink/downlink state (and additionally could monitor call states as
well if needed). So it knows when a call is active and it is active
anyway doing the audio processing. So it could just then go ahead and
write your call accounting into Tracker.
Would such an architecture work for you guys?
I don't know at the moment whether this solution is good and elegant
enough, we need to think about it.
>>> The reason these are not properties is just because it
makes no sense
>>> to update the counters "live". The UI can poll if it so wishes,
but
>>> the poll interval is not something we want to decide.
>>>
>>>
>>>
>>>> What are the granularity there. What is the expected user experience
>>>> with this API. I don't see any clear usage model here.
>>>>
>>>> In addition to that, what is the problem with just updating the stats
>>>> after the call has ended?
>>>>
>>>>
>>> Because if your battery runs out in the middle of a 4 hour conference
>>> call, your timers are not updated and become worthless. Obviously,
>>> this is a compromise between how reliable the counters are and how
>>> many wakeups and IO we can bear.
>>>
>>>
>> I think this is not a good idea to have oFono handles this. Why can't
>> the system daemon just shutdown all calls when the battery reaches
>> critical limit.
>>
>> You will never fully run down the battery anyway. One of the system
>> health components in the system will prevent it and then can cleanly
>> shutdown oFono and thus all calls. The only case where the system could
>> potentially misfunction in this area would be an emergency call. But
>> that is a total different use case anyway.
>>
>>
> It was already pointed out by Mika Liljeberg there could be cases when we
> might not get the chance to sync our data. We need to be prepared to cope
> with such cases as well (syncing the data often "enough").
>
Are these cases are really real life problems. For example with devices
moving toward hotswap SIM cards, the exchange of battery and
accidentally (or on purpose) removal seems to become more and more
unrealistic.
Probably this whole data reliability issue shouldn't be an oFono concern
after all, there must be a backend doing that and not only for oFono
data but any other highly important data.
Regards
Marcel
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
Regards,
Andras
10:32 p.m.
Hi Andras,
>> The call counters are shown to the user when he or she opens
up
>> an application/applet whatever UI component that is meant for
>> showing this information.
>>
> do we have a clear use case requirement from an UI point of view on how
> this is expected to be working.
>
In our case, it is expected to have the counters information shown to the
user continuously updated with about 1 second granularity, as long as the
user keeps opened the UI showing the counters. This practically means
"live" call counters in the UI.
are your interaction designers aware of that users wanna use their phone
for making phone calls and not watching call counters increasing every
single second?
My iPhone has a granularity of 1 minute and I actually had to go out of
my normal calling behavior to watch that counter. And it does not update
actually during the call. It only updates when the call end.
And just to be clear here. Calling a D-Bus method every single second is
not acceptable. That is a sure way to drain you battery.
> I checked with my iPhone and how it does it. Basically it just
updates
> after the call and only after you re-entered that menu.
>
> So here again, do we have a requirement to make this realtime or not.
> And I mean that from an user interaction point of view.
>
>
>> Coming to the reliability part, saving the call counters information
>> often enough, gives us sort of hard guarantee that whatever happens
>> with any subsystem, be that SW or HW, the call counters will stay enough
>> accurate. Syncing to the permanent storage, based on our product
>> requirements, should take place in fact every 5 sec, or could be
>> configurable.
>>
> Writing and syncing something to disk every 5 seconds costs us IO. Is
> this really a sacrifice that is acceptable.
>
>
I agree, from pure technical point of view it's a costly operation.
So here is my problem with this whole idea. How much do you care about
battery life and call time?
You keep waking up ofonod during the call (which is not needed) and you
keep the IO active. So from how I am looking at this problem, ofonod is
the wrong place to solve this.
>> There might be some liability issues if for some reason the
counters would
>> "loose" time, the user my blame the phone manufacturer for the extra
>> expenses incurred by inaccurate counters.
>>
> To be honest the counters can not be considered accurate anyway. Only
> the billing system has the final say.
>
I think any info we decide to show to the user has to be accurate enough,
otherwise becomes meaningless.
Even if we entertain this for a bit, does a user really care about
seconds of overall call time. For a single call, maybe, but for your
overall call time. Is minutes not enough? How accurate does this really
have to be?
>> We can discuss the place of the call counters plugin, but I
think using the
>> ofono history framework is a reasonable choice, with the note that the it
>> needs to be expanded with a history function called in the beginning
>> of a call.
>> The call counters plugin could be an optionally compiled/included (dynamic)
>> plugin or "downgraded" to experimental status.
>>
> So I am actually thinking that doing that inside PulseAudio is a lot
> more efficient solution.
>
> The idea is that PA already runs in the user session and has to monitor
> the uplink/downlink state (and additionally could monitor call states as
> well if needed). So it knows when a call is active and it is active
> anyway doing the audio processing. So it could just then go ahead and
> write your call accounting into Tracker.
>
> Would such an architecture work for you guys?
>
I don't know at the moment whether this solution is good and elegant
enough, we need to think about it.
Please think about this. While not obvious at first, it seems pretty
much reasonable to me. PA will be most likely active anyway.
However here is one thing that is unclear to me. Are we tracking talk
time or call time. In case of call time, how do we deal with multiparty
calls etc. Is a call on hold equals double time and so on.
So does this have to reflect billed time or actual time spent talking on
the phone.
I am really missing a well defined features requirement from top to
bottom with these details explained.
>>>> The reason these are not properties is just because
it makes no sense
>>>> to update the counters "live". The UI can poll if it so
wishes, but
>>>> the poll interval is not something we want to decide.
>>>>
>>>>
>>>>
>>>>> What are the granularity there. What is the expected user
experience
>>>>> with this API. I don't see any clear usage model here.
>>>>>
>>>>> In addition to that, what is the problem with just updating the
stats
>>>>> after the call has ended?
>>>>>
>>>>>
>>>> Because if your battery runs out in the middle of a 4 hour conference
>>>> call, your timers are not updated and become worthless. Obviously,
>>>> this is a compromise between how reliable the counters are and how
>>>> many wakeups and IO we can bear.
>>>>
>>>>
>>> I think this is not a good idea to have oFono handles this. Why can't
>>> the system daemon just shutdown all calls when the battery reaches
>>> critical limit.
>>>
>>> You will never fully run down the battery anyway. One of the system
>>> health components in the system will prevent it and then can cleanly
>>> shutdown oFono and thus all calls. The only case where the system could
>>> potentially misfunction in this area would be an emergency call. But
>>> that is a total different use case anyway.
>>>
>>>
>> It was already pointed out by Mika Liljeberg there could be cases when we
>> might not get the chance to sync our data. We need to be prepared to cope
>> with such cases as well (syncing the data often "enough").
>>
> Are these cases are really real life problems. For example with devices
> moving toward hotswap SIM cards, the exchange of battery and
> accidentally (or on purpose) removal seems to become more and more
> unrealistic.
>
Probably this whole data reliability issue shouldn't be an oFono concern
after all, there must be a backend doing that and not only for oFono
data but any other highly important data.
I would highly recommend against making oFono responsible here. Since
the ofonod process should be mostly sleeping during a voice call and not
being busy with IO.
Regards
Marcel
9:02 p.m.
Hi,
On 08 Dec 2010, Marcel Holtmann wrote:
So I am actually thinking that doing that inside PulseAudio is a lot
more efficient solution.
The idea is that PA already runs in the user session and has to monitor
the uplink/downlink state (and additionally could monitor call states
as well if needed). So it knows when a call is active and it is active
anyway doing the audio processing. So it could just then go ahead and
write your call accounting into Tracker.
Pulseaudio (or the meego PA modules for voice) isn't really an option
for at least the following reasons:
- lots of modems still handle all audio and PA will know nothing
about calls at all with these modems
- PA does not really care about individual calls, but whether
the audio traffic channel is connected or not
- multi-call cases, cases were traffic channel is reconnected
mid-call, etc, etc, PA simply does not know enough (and should
not)
I guess this could be done in higher layers on top of oFono (telepathy-ring,
dialer app, policy framework, etc), but I don't really know enough about
the call timer stuff to comment on the pro/cons of this.
br,
--
Kai Vehmanen
10:35 p.m.
Hi Kai,
> So I am actually thinking that doing that inside PulseAudio is a
lot
> more efficient solution.
>
> The idea is that PA already runs in the user session and has to monitor
> the uplink/downlink state (and additionally could monitor call states
> as well if needed). So it knows when a call is active and it is active
> anyway doing the audio processing. So it could just then go ahead and
> write your call accounting into Tracker.
Pulseaudio (or the meego PA modules for voice) isn't really an option
for at least the following reasons:
- lots of modems still handle all audio and PA will know nothing
about calls at all with these modems
actually Denis raised the same question, but then again this is for a
product specific requirement. And for that product we know that PA will
do the audio processing.
- PA does not really care about individual calls, but whether
the audio traffic channel is connected or not
- multi-call cases, cases were traffic channel is reconnected
mid-call, etc, etc, PA simply does not know enough (and should
not)
And that is my point (see other email). This should be tracking talk
time and not individual call time. And thus it would be fitting nicely
into PA in that case.
I guess this could be done in higher layers on top of oFono
(telepathy-ring,
dialer app, policy framework, etc), but I don't really know enough about
the call timer stuff to comment on the pro/cons of this.
Important for me is to weight the extra costs of IO and CPU consumption
when doing this inside oFono. And since ofonod itself would actually not
wake up during a phone call, I think this is not a good fit.
It could be that PA is not a good candidate either, but to me it looks
like a pretty smart place to handle this.
Regards
Marcel
12:25 p.m.
Hi,
On 09 Dec 2010, Marcel Holtmann wrote:
> - lots of modems still handle all audio and PA will know
nothing
> about calls at all with these modems
actually Denis raised the same question, but then again this is for a
product specific requirement. And for that product we know that PA will
do the audio processing.
not really. We need modem adaptation for call counters and need
an API that works with all modems. And I'd assume other handset
vendors need such an API as well (either in oFono or somewhere else).
Important for me is to weight the extra costs of IO and CPU
consumption
when doing this inside oFono. And since ofonod itself would actually
not wake up during a phone call, I think this is not a good fit.
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). So the big cost of bringing CPU, memories et al online are
already taken at this point, and the additional cost of running ofonod
for a while is minimal (compared to waking up some non-realtime thread of
pulseaudio, or some other component, to do the same).
But yeah, there is a IO/CPU cost in any case, I agree about that.
Br,
--
Kai Vehmanen
6:10 p.m.
Hi Kai,
>> - lots of modems still handle all audio and PA will know
nothing
>> about calls at all with these modems
>
> actually Denis raised the same question, but then again this is for a
> product specific requirement. And for that product we know that PA will
> do the audio processing.
not really. We need modem adaptation for call counters and need
an API that works with all modems. And I'd assume other handset
vendors need such an API as well (either in oFono or somewhere else).
> Important for me is to weight the extra costs of IO and CPU consumption
> when doing this inside oFono. And since ofonod itself would actually
> not wake up during a phone call, I think this is not a good fit.
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). So the big cost of bringing CPU, memories et al online are
already taken at this point, and the additional cost of running ofonod
for a while is minimal (compared to waking up some non-realtime thread of
pulseaudio, or some other component, to do the same).
this is not really true. We can not wakeup ofonod every single second.
You might wanna start running powertop.
Regards
Marcel
7:52 p.m.
Hello Marcel,
On 09 Dec 2010, Marcel Holtmann wrote:
> 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.
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.
br,
--
Kai Vehmanen
10:53 p.m.
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.
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.
Regards
Marcel
8:14 a.m.
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
5:57 p.m.
On Friday 10 December 2010 00:53:19 ext Marcel Holtmann, you wrote:
> > this is not really true. We can not wakeup ofonod every
single second.
> > You might wanna start running powertop.
Yes we can. PulseAudio is going to be waking up the CPU 10 times per seconds
or more.
> 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.
No! The one extra context switch is negligible compared to the several few
system calls that updating the call counter requires. And as Kai already said,
the CPU will wake up anyway.
The real power consumption difference lies in the I/O, which would not happen
if it weren't for fault-tolerant call counters. In that respect, which process
writes, PulseAudio, oFono, or something else, is irrelevant.
Of course this should be smart and done along with the PA audio
processing and not async to that one.
No. PulseAudio has no business with the call counters. It might not know that
it is a call. And even if it did know, it might not know whether the call is
ringing or connected.
oFono on the other hand has the informations. Also, if we gave up on fault
tolerance to save power, oFono would be the logical place to provide call
counters (through D-Bus). So it only makes sense that oFono does this - if
anyone.
And then, it's our nor your decision to make how often (if at all) the call
counters need to be flushed to the memory card. That's a matter for the
vendor's legal & liability departement. So it really just needs to be
configurable, including the ability to disable the feature altogether if it is
not needed.
If we consider that the only sensible thing is to track the actual
talking time, then PA becomes a nice choice for this.
I don't think so.
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.
> 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.
There are definitely call fares with sub-minute granularity. The minute is
definitely INSUFFICIENT.
Doing this every 10 seconds and displaying it on a per second level
sounds insane to me.
So I made a lengthy call to my mum this morning, using a desk phone. And it
was showing minute:second, not just minutes. I have never seen a phone that
does not show seconds and it would look pretty dumb to me.
But of course, that's a matter for UI designers, not for middleware oFono
software engineers anyway.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
6:34 p.m.
Hi Remi,
> > 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.
There are definitely call fares with sub-minute granularity. The minute is
definitely INSUFFICIENT.
let me repeat my question here. Does this suppose to be represent spent
time on calls (what I called talk time) or actual billing minutes.
If we talk about correct billing minutes then you are just opening
pandora's box. Since we don't know the billing. And difference between
air time, incoming/outgoing calls, multiparty calls, hold calls etc. and
their billing schemes make this just insane.
So what is the actual requirement here. So far ever single answer was
not satisfying. And that is why I proposed to just make this count the
talk time.
> Doing this every 10 seconds and displaying it on a per second
level
> sounds insane to me.
So I made a lengthy call to my mum this morning, using a desk phone. And it
was showing minute:second, not just minutes. I have never seen a phone that
does not show seconds and it would look pretty dumb to me.
You do realize that this is NOT the feature we are talking about here.
The actual display of the duration of a call is pretty simple and
currently easy to handle inside the UI. And that can be done up to the
millisecond display if you or your UI designer wants it.
The proposed call counters here are long term counters showing your
overall time. So showing minutes seems to be precise enough.
Regards
Marcel
11:57 p.m.
On Friday 10 December 2010 20:34:47 ext Marcel Holtmann, you wrote:
Hi Remi,
> > > 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.
>
> There are definitely call fares with sub-minute granularity. The minute
> is definitely INSUFFICIENT.
let me repeat my question here. Does this suppose to be represent spent
time on calls (what I called talk time) or actual billing minutes.
As said earlier, this is about the talk time. The scenario is a user ejects
the battery during an already long-standing call or gets the device to crash
or reset, gets billed, and comes and complain to its operator that (s)he gets
overcharged. The counters will be much more wrong if we do not flush them to
disk frequently.
We do not need to "implement" the billing policy for that. This is only about
the total talk time.
If we talk about correct billing minutes then you are just opening
pandora's box. Since we don't know the billing. And difference between
air time, incoming/outgoing calls, multiparty calls, hold calls etc. and
their billing schemes make this just insane.
Sure. We don't wants this.
So what is the actual requirement here. So far ever single answer
was
not satisfying. And that is why I proposed to just make this count the
talk time.
The requirement is that the user cannot deduct (much) talk time from the call
counters.
> > Doing this every 10 seconds and displaying it on a per
second level
> > sounds insane to me.
>
> So I made a lengthy call to my mum this morning, using a desk phone. And
> it was showing minute:second, not just minutes. I have never seen a
> phone that does not show seconds and it would look pretty dumb to me.
You do realize that this is NOT the feature we are talking about here.
The actual display of the duration of a call is pretty simple and
currently easy to handle inside the UI. And that can be done up to the
millisecond display if you or your UI designer wants it.
The proposed call counters here are long term counters showing your
overall time. So showing minutes seems to be precise enough.
Showing minutes, as in flushing the counters every 60 seconds might work, but
I'd rather make this a configurable knob.
That said, I do believe the stored value has to be more precise than minutes.
Otherwise per call "error" may add up far too quickly.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
2:57 p.m.
Hi Remi,
> > > > 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.
> >
> > There are definitely call fares with sub-minute granularity. The minute
> > is definitely INSUFFICIENT.
>
> let me repeat my question here. Does this suppose to be represent spent
> time on calls (what I called talk time) or actual billing minutes.
As said earlier, this is about the talk time. The scenario is a user ejects
the battery during an already long-standing call or gets the device to crash
or reset, gets billed, and comes and complain to its operator that (s)he gets
overcharged. The counters will be much more wrong if we do not flush them to
disk frequently.
We do not need to "implement" the billing policy for that. This is only about
the total talk time.
> If we talk about correct billing minutes then you are just opening
> pandora's box. Since we don't know the billing. And difference between
> air time, incoming/outgoing calls, multiparty calls, hold calls etc. and
> their billing schemes make this just insane.
Sure. We don't wants this.
> So what is the actual requirement here. So far ever single answer was
> not satisfying. And that is why I proposed to just make this count the
> talk time.
The requirement is that the user cannot deduct (much) talk time from the call
counters.
is actually everybody in agreement here that we talk about actual time
spent on the phone talking? Denis and myself clearly see it that this is
a sensible approach to overall call counters.
And if that is the case, then this maps closely to what PA has to track
anyway. The more and more we talk about this, the more and more it makes
sense to me to do this as a plugin to PA that stores the overall call
time values into Tracker. And then can also be reset via Tracker.
This would satisfy all my concern that I have from an process wakeup and
IO utilization overhead and battery consumption point of view.
> > > Doing this every 10 seconds and displaying it on a per
second level
> > > sounds insane to me.
> >
> > So I made a lengthy call to my mum this morning, using a desk phone. And
> > it was showing minute:second, not just minutes. I have never seen a
> > phone that does not show seconds and it would look pretty dumb to me.
>
> You do realize that this is NOT the feature we are talking about here.
>
> The actual display of the duration of a call is pretty simple and
> currently easy to handle inside the UI. And that can be done up to the
> millisecond display if you or your UI designer wants it.
>
> The proposed call counters here are long term counters showing your
> overall time. So showing minutes seems to be precise enough.
Showing minutes, as in flushing the counters every 60 seconds might work, but
I'd rather make this a configurable knob.
That said, I do believe the stored value has to be more precise than minutes.
Otherwise per call "error" may add up far too quickly.
I don't see this as a problem at all. This does not add up.
So if you loose 59 seconds in a 4 hours call, then that is pretty much
statistically irrelevant. And that is only the case if you magically
loose your battery.
In case you run out of battery or end the call properly, you will still
get the accurate counter to the second. Since the device management
daemon or oFono will inform you about it.
What you should really ask yourself is what you present to the user. If
you use your phone for 3 phone calls that are less than three seconds,
you might wanna display seconds. However in that case you have the
accurate counter when ending the call in the first place. If you loose
your battery and have not used the phone longer than a minute, why
bother. This is not the problem that needs to be solved.
If you spent something crazy like 60 hours on the phone per month and
then loose 59 seconds, it makes no difference either. At that point that
inaccuracy is statistically irrelevant and can be ignored. And again,
this is only a problem if you battery magically gets loose and flies
away. Otherwise you are accurate to the second.
So in conclusion having an IO sync of the ongoing call every 60 seconds
seems to be reasonable enough. And at the same time you keep a down to
the second call time in case of a healthy device.
With all this in mind. How often does someone magically loose the
battery and then goes complain to someone about a "big" difference in
the bills. Or is this more an esoteric feature request. Can we not try
to solve this sensible without going overboard and trying to solve world
hunger ;)
Regards
Marcel
7:56 a.m.
Hello,
On 11 Dec 2010, Denis-Courmont Remi wrote:
> let me repeat my question here. Does this suppose to be represent
spent
> time on calls (what I called talk time) or actual billing minutes.
As said earlier, this is about the talk time. The scenario is a user
ejects the battery during an already long-standing call or gets the device
to crash or reset, gets billed, and comes and complain to its operator that
(s)he gets overcharged. The counters will be much more wrong if we do not
I'm no longer sure what you guys mean with "billing minutes" and "talk
time" here, so maybe we should talk in terms of code. E.g. look
at the patches Andras sent to the list to see what is tracked and how:
- each call is tracked separately (e.g. counter still running for
held calls)
- tracking separately for MO/MT calls
- call starts when state goes to ACTIVE (from INCOMING/ALERTING/DIALING/WAITING)
- call terminates to DISCONNECTED
In case of conflict, what's actually in Andras' patches
overrides my interpretation above. ;)
This concept is already in oFono core (call->start_time is created
when calls start, and __ofono_history_call_ended is called when
calls end, matching the above).
That said, I do believe the stored value has to be more precise than
minutes.
Otherwise per call "error" may add up far too quickly.
Yes, but I agree with Marcel that a 60sec update interval sounds
reasonable (so higher resolution for stored values, but updates
at e.g. every minute). Even better if the refresh rate can be tuned.
3:46 p.m.
Hello Marcel,
I'll answer to two separates mails (of this thread) in one go:
On 10 Dec 2010, Marcel Holtmann wrote:
Kai Vehmanen wrote:
> 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.
You cannot do this with one thread wakeup. The real-time parts implementing
voice data path in pulseaudio (and ones waking up to hw interrupts) need to
follow soft-realtime practises to maximize execution determinism. I.e. these
threads are run with SCHED_FIFO/RR and any calls to possibly-blocking system
calls must be avoided (this includes dynamic memory allocation, access to
file/sokcets, etc, etc). See e.g. JACK audio server project's guidelines for
client apps for a good overview of what these limitations mean in practise.
Storing the call counters requires file/socket i/o, so doing this from
a real-time thread is a big no-no (and if done anyways, would be a likely
cause to audio hickups).
So you need to wake up another thread in any case (e.g. PA has separate
threads for DBus and talking to PA clients). Of course an explicit
wake-up is better than relying on timer slack to coalesce the wakeup
of ofonod and pulseaudio, so I agree using a PA thread is technically
better and more robust way to ensure no extra wakeups occur, but if/when
implemented properly, waking up ofonod really has no penalty either.
But the above is really a minor issue I think. I think the most
important argument against doing this in PA is (quoting my earlier
reply):
--cut--
- lots of modems still handle all audio and PA will know nothing
about calls at all with these modems
--ct---
This needs to be done in a component that is tracking calls,
independently of what modem is used.
And then one further comment to a more recent mail in this thread:
On 12 Dec 2010, Marcel Holtmann wrote:
is actually everybody in agreement here that we talk about actual
time
spent on the phone talking? Denis and myself clearly see it that this is
a sensible approach to overall call counters.
And if that is the case, then this maps closely to what PA has to track
anyway.
No, no. Surely what matters are the individual calls, and their
state w.r.t. signaling. And this is what the patches Andras' has sent
are tracking.
PA on the other hand tracks the traffic channel state and that cannot be
used. E.g. in common real-life cases (handovers), the traffic channel can
be temporarily disconnected during an active call (PA will see this, but
it is _not_ visible in either the phone UI nor in billing). For to PA
to implement call counters, it would have to be extended to track individual
call state.
Br,
--
Kai Vehmanen
4260
days inactive
4281
days old
28 comments
8 participants
participants (8)
-
Aki Niemi -
Andras Domokos -
Andras Domokos
-
Denis Kenzior -
Kai.Vehmanen＠nokia.com -
Marcel Holtmann -
Mika.Liljeberg＠nokia.com -
Rémi Denis-Courmont