Re: [Bluez-devel] varying time to connect

Re: [Bluez-devel] varying time to connect

[Peter Wippich]

Hello Ronny,

the clock offset is only usefull (if at all.....) if the most recent
inquiry wasn't to long ago and both devices were not powered down (or
reset) in between. From our experiences it doesn't help alot under normal
conditions to speed up connection setup.
Of cause you can do an inquiry just before connection setup to get the
actual clock offset, but in total your connection setup time will
increase.

Further, if I remember right, most Bluetooth modules cache clock offsets
internaly.

I think these are the reasons why BlueZ doen't make use of it.

Ciao,

Peter

On Wed, 15 Jun 2005, Ronny L Nilsson wrote:

>
>
> Hi
> Following up my own question on the users-list at
> http://sourceforge.net/mailarchive/forum.php?thread_id=7501858&forum_id=1883
> I've made futher investigations regarding the optimise-connect issue.
>
> Reading the BT 1.2 spec it seems like HCI support an optional clock
> offset parameter when doing connects. However, it seems like BlueZ
> doesn't utilise it. My guess is this might be the case to the very much
> varying delays when establishing a connection with
>    hcitool cc 00:11:22:33:44:55
>
> Anyone who can confirm this? Or is there a reason why the clock offset
> parameter ain't used? I'm thinking of perhaps modifying hcid to cache
> clocks from most resent inqury to reuse them later, at a subsequent
> connect. Or is there a better way?
>
> Regards
> /Ronny Nilsson
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

|	Peter Wippich 			Voice: +49 30 46776411		|
|	G&W Instruments GmbH		fax:   +49 30 46776419		|
|	Gustav-Meyer-Allee 25, Geb. 12	Email: pewi@gw-instruments.de	|
|	D-13355 Berlin  / Germany					|




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] varying time to connect

[Ronny L Nilsson]

Hi
Following up my own question on the users-list at
http://sourceforge.net/mailarchive/forum.php?thread_id=7501858&forum_id=1883
I've made futher investigations regarding the optimise-connect issue.

Reading the BT 1.2 spec it seems like HCI support an optional clock 
offset parameter when doing connects. However, it seems like BlueZ 
doesn't utilise it. My guess is this might be the case to the very much 
varying delays when establishing a connection with 
   hcitool cc 00:11:22:33:44:55

Anyone who can confirm this? Or is there a reason why the clock offset 
parameter ain't used? I'm thinking of perhaps modifying hcid to cache 
clocks from most resent inqury to reuse them later, at a subsequent 
connect. Or is there a better way?

Regards
/Ronny Nilsson




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] varying time to connect

[Marcel Holtmann]

Hi Ronny,

> Following up my own question on the users-list at
> http://sourceforge.net/mailarchive/forum.php?thread_id=7501858&forum_id=1883
> I've made futher investigations regarding the optimise-connect issue.
> 
> Reading the BT 1.2 spec it seems like HCI support an optional clock 
> offset parameter when doing connects. However, it seems like BlueZ 
> doesn't utilise it. My guess is this might be the case to the very much 
> varying delays when establishing a connection with 
>    hcitool cc 00:11:22:33:44:55

using "hcitool cc ..." is not the right way for creating an ACL link.
The kernel will create the ACL links on demand and use the clock offset
from its inquiry cache if it is not outdated.

> Anyone who can confirm this? Or is there a reason why the clock offset 
> parameter ain't used? I'm thinking of perhaps modifying hcid to cache 
> clocks from most resent inqury to reuse them later, at a subsequent 
> connect. Or is there a better way?

Don't use "hcitool cc ...". It is not needed and only available for
testing.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] varying time to connect

[Ronny L Nilsson]

> the clock offset is only usefull (if at all.....) if the most recent
> inquiry wasn't to long ago and both devices were not powered down (or
> reset) in between. From our experiences it doesn't help alot under
> normal conditions to speed up connection setup.

Hi
Ok. If one is sure of none of the devices has reset, for aprox how long 
is a clock offset cache usable? I suspect they drift somewhat. 
Seconds, minutes or hours?

/Ronny



-----
> Of cause you can do an inquiry just before connection setup to get
> the actual clock offset, but in total your connection setup time will
> increase.
> Further, if I remember right, most Bluetooth modules cache clock
> offsets internaly.
> I think these are the reasons why BlueZ doen't make use of it.
> Peter


-------
> On Wed, 15 Jun 2005, Ronny L Nilsson wrote:
> > http://sourceforge.net/mailarchive/forum.php?thread_id=7501858&foru
> > Anyone who can confirm this? Or is there a reason why the clock
> > offset parameter ain't used? I'm thinking of perhaps modifying hcid
> > to cache clocks from most resent inqury to reuse them later, at a
> > subsequent connect. Or is there a better way?
> > /Ronny Nilsson



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel