linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
To: Kim Schulz <kim@schulz.dk>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [RFC 0/3] LE Connection parameter tuning (first step)
Date: Mon, 5 Nov 2012 15:52:24 +0100	[thread overview]
Message-ID: <20121105145224.GA18358@echo> (raw)
In-Reply-To: <2375c7de623938c6e2f1fe8e7687db7d@server1.devteam.dk>

Hi,

On 14:42 Mon 05 Nov, Kim Schulz wrote:
> Den 2012-11-05 14:25, Vinicius Costa Gomes skrev:
> >Hi,
> >
> >Right now, we are using only one set of (hardcoded) connection
> >parameters for LE.  I guess the first step to have different
> >connection parameters classes for different Profiles requirements
> >(think "Low Latency", "Low Power", etc.) is to have a nice set of
> >parameters. For that we need to measure and see which are the sweet
> >spots, This series aims to help the measuring part.
> >
> >This is an idea so we can easily change the connection parameters
> >without need for recompiling the kernel side, so tests can be more
> >practical.
> >
> [snip]
> 
> 
> Good idea to split them out as every single profile defines their
> own. Have you
> concidered what should happen if two LE connections to two different
> profils should
> happen at the same time and the connection parameters are different?
> i.e. should bluez
> maybe have a per-profile set of connection parameters?

The current plan is to have the most restrictive (in terms of latency)
set of parameters to prevail over the others.

> Also make room in the struct for Preferred Connection Paramters (the
> values read
> from the peer DB after connection) as these can differ from the ones
> the profile proposes.

I don't think that this information should be in the kernel side, but thank
you for reminding me of this. About the problem, that could be dealt with
having that as another set of parameters (perhaps with a higher priority). 

> 
> -- 
> Kim Schulz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers,
-- 
Vinicius

      reply	other threads:[~2012-11-05 14:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 13:25 [RFC 0/3] LE Connection parameter tuning (first step) Vinicius Costa Gomes
2012-11-05 13:25 ` [RFC 1/3] Bluetooth: Keep the LE connection parameters in its own structure Vinicius Costa Gomes
2012-11-05 13:25 ` [RFC 2/3] Bluetooth: Add LE connection parameters to debugfs Vinicius Costa Gomes
2012-11-12  9:36   ` Andrei Emeltchenko
2012-11-05 13:25 ` [RFC 3/3] Bluetooth: Add support for setting LE connection parameters via debugfs Vinicius Costa Gomes
2012-11-05 13:42 ` [RFC 0/3] LE Connection parameter tuning (first step) Kim Schulz
2012-11-05 14:52   ` Vinicius Costa Gomes [this message]

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=20121105145224.GA18358@echo \
    --to=vinicius.gomes@openbossa.org \
    --cc=kim@schulz.dk \
    --cc=linux-bluetooth@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).