Inquiry cache management (clock offset)
Marcel Holtmann
maintainerHi Marco,
Quoted 20 lines
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 lethci_inquiry_cache_lookup()to lookup the inquiry cache of each interface
- Application side: create a baseband connection withhci_create_connection()before establish a L2CAP/RFCOMM communication
Quoted 2 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Quoted 7 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Quoted 6 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Pierre-Yves,
Quoted 10 lines
Quoted 6 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoted 9 lines · On Thu, 21 Dec 2006 13:53:18 +0100 Marcel Holtmann <[email protected]> wrote:
Hi Pierre-Yves,
Quoted 7 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 3 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel