[Bluez-devel] Inquiry cache management (clock offset)

[Bluez-devel] Inquiry cache management (clock offset)

[Marco Pracucci]

Hi,

I have read a portion of bluez kernel sources and I have noticed, if I'm
not wrong, that bluez looks up the inquiry cache before establish an ACL
link, in order to get the clock offset of the remote device (returned
from a previuos inquiry). This is a great features to speed up the
paging process.

However, the scope of the inquiry cache is bounded to the interface that
do an inquiry. So, suppose that I have 2 interfaces: the "interface A"
does an inquiry and, after, the "interface B" creates a baseband
connection. This last interface (B) sends an HCI "create connection"
command with the default clock offset instead of the real clock offset,
as determined by interface A.

Now, If we suppose that I can't inquiry and create the connection with
the same interface, I think there are two solutions:
- Kernel side: patch the kernel and let hci_inquiry_cache_lookup() to
lookup the inquiry cache of each interface
- Application side: create a baseband connection with
hci_create_connection() before establish a L2CAP/RFCOMM communication

What are the main advantages/disadvantages of the above solutions?
Do you have any suggestion?

Thanks,
Marco Pracucci


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Inquiry cache management (clock offset)

[Marcel Holtmann]

Hi Marco,

> I have read a portion of bluez kernel sources and I have noticed, if I'm
> not wrong, that bluez looks up the inquiry cache before establish an ACL
> link, in order to get the clock offset of the remote device (returned
> from a previuos inquiry). This is a great features to speed up the
> paging process.
> 
> However, the scope of the inquiry cache is bounded to the interface that
> do an inquiry. So, suppose that I have 2 interfaces: the "interface A"
> does an inquiry and, after, the "interface B" creates a baseband
> connection. This last interface (B) sends an HCI "create connection"
> command with the default clock offset instead of the real clock offset,
> as determined by interface A.
> 
> Now, If we suppose that I can't inquiry and create the connection with
> the same interface, I think there are two solutions:
> - Kernel side: patch the kernel and let hci_inquiry_cache_lookup() to
> lookup the inquiry cache of each interface
> - Application side: create a baseband connection with
> hci_create_connection() before establish a L2CAP/RFCOMM communication
> 
> What are the main advantages/disadvantages of the above solutions?
> Do you have any suggestion?

the main disadvantage is that it gives you nothing. You can't move the
clock offset around from adapter A to adapter B. As the word says, it is
a clock _offset_ and this means it depends on the local clock on the
chip. So a received clock offset on adapter A is invalid on adapter B
and it might happen that the connection establishment takes longer than
if you would have used no clock offset at all.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Inquiry cache management (clock offset)

[Marco Pracucci]

Hi Marcel,
> the main disadvantage is that it gives you nothing. You can't move the
> clock offset around from adapter A to adapter B. As the word says, it is
> a clock _offset_ and this means it depends on the local clock on the
> chip. So a received clock offset on adapter A is invalid on adapter B
> and it might happen that the connection establishment takes longer than
> if you would have used no clock offset at all.
>   
you're perfectly right. I didn't consider this "little" detail.

Thanks,
Marco Pracucci


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Inquiry cache management (clock offset)

[Pierre-Yves Paulus]

Hi Marcel,

> the main disadvantage is that it gives you nothing. You can't move the
> clock offset around from adapter A to adapter B. As the word says, it is
> a clock _offset_ and this means it depends on the local clock on the
> chip. So a received clock offset on adapter A is invalid on adapter B
> and it might happen that the connection establishment takes longer than
> if you would have used no clock offset at all.

And what about computing the clock offset between local adapters, and 
then based on this information compute the proper clock offset with the 
remote device for the adapter actually used to connect it?

Regards,
Pierre-Yves

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Inquiry cache management (clock offset)

[Marcel Holtmann]

Hi Pierre-Yves,

> > the main disadvantage is that it gives you nothing. You can't move the
> > clock offset around from adapter A to adapter B. As the word says, it is
> > a clock _offset_ and this means it depends on the local clock on the
> > chip. So a received clock offset on adapter A is invalid on adapter B
> > and it might happen that the connection establishment takes longer than
> > if you would have used no clock offset at all.
> 
> And what about computing the clock offset between local adapters, and 
> then based on this information compute the proper clock offset with the 
> remote device for the adapter actually used to connect it?

with Bluetooth 1.2 you can even read the local clock and do your
computation from there. However I doubt that this will give any real
improvement. Feel free to prove me otherwise, but please make sure that
your testing is done with real life scenarios. Meaning moving targets.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Inquiry cache management (clock offset)

[Cris]

On Thu, 21 Dec 2006 13:53:18 +0100
Marcel Holtmann <marcel@holtmann.org> wrote:

> Hi Pierre-Yves,
> 
> > > the main disadvantage is that it gives you nothing. You can't move the
> > > clock offset around from adapter A to adapter B. As the word says, it is
> > > a clock _offset_ and this means it depends on the local clock on the
> > > chip. So a received clock offset on adapter A is invalid on adapter B
> > > and it might happen that the connection establishment takes longer than
> > > if you would have used no clock offset at all.
> > 
> > And what about computing the clock offset between local adapters, and 
> > then based on this information compute the proper clock offset with the 
> > remote device for the adapter actually used to connect it?
> 
> with Bluetooth 1.2 you can even read the local clock and do your
> computation from there. However I doubt that this will give any real
> improvement. Feel free to prove me otherwise, but please make sure that
> your testing is done with real life scenarios. Meaning moving targets.

Sorry to kick in like that, but moving targets don't matter here: One
device will get the offset from peer. The other device, which is on
the same host, and which want's to use the inquiry's result, won't
move in relation to the first. There is a drift between the two local
devices, such that some correction may be necessary from time to time,
but if you know the offset between the two local devices, it should be
possible to compute the offset from peer to the second device. Once
the connection is established, it's the link manager (hardware) who
takes care of the adjustments. OTOH, the paging process is really only
a few time slots and it is doubtful that a human being is able to feel
the difference. As such, it shouldn't be difficult to compute the
correctly derived offset, but it's probably not worth even that.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Inquiry cache management (clock offset)

[Marco Pracucci]

Hi Marcel,
> with Bluetooth 1.2 you can even read the local clock and do your
> computation from there. However I doubt that this will give any real
> improvement. Feel free to prove me otherwise, but please make sure that
> your testing is done with real life scenarios. Meaning moving targets.
>   
I have just done some simple tests and I have *not* noticed any
significant differences in performance, as you say.

Marco Pracucci


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel