Hello,
the patch alone doesn't help to accelerate connection establishment.
And of course you are right, that the clock offset event is only
generated
if someone requests it for an existing acl-conenction. But maybe
some people want to do this.
But maybe if you terminate the connection and want to establish it again
without inquiry (just using the inquiry cache), the clock offset event
is
helpful (why do we have the inquiry cache?). Especially if you want to
do this automatically. For the normal user this has no benefit until
now.
In this context INQUIRY_ENTRY_AGE_MAX should be set to e.g. one hour
(see the mails from 30th. of January, Subject "Connecting with clock
offset").
But the main reason for integrating this event in bluez is:
The clock offset event exists in the spec
and can be generated if someone wants to do this
and there is no reason to omit these few lines of code.
Regards
Marcel Holtmann schrieb:
>
> Hi Wolfgang,
>
> > I added support for the clock offset event to bluez-kernel. The
> > attached patch is very simple and applies cleanly to bluez-kernel-2.3.
> > If you like, you can commit it. Then bluez gets one more step more
> > complete.
> > The clock information in the corresponding
> > entry of the inquiry cache is updated in case of a clock offset event.
> >
> > Clock offset is important for very fast connection establishment.
>
> thanks for the patch. Can you please explain how it should help to get a
> fast connection establishment. I have been through the spec. and the
> clock offset event will only be generated if you request it with the
> read clock offset command. This command requires a connection handle of
> an ACL link and if you got the connection handle you will already have a
> established connection. So I can't see how this patch will give us any
> advantages.
>
> Regards
>
> Marcel
--
Fraunhofer Einrichtung f?r Systeme der Kommunikationstechnik (ESK)
Wolfgang Heidrich Hansastra?e 32
Dipl.-Ing. 80686 M?nchen / Germany
Phone : +49(0)89-547088-376
E-Mail: [email protected] Fax : +49(0)89-547088-221
Hi Wolfgang,
> the patch alone doesn't help to accelerate connection establishment.
> And of course you are right, that the clock offset event is only
> generated
> if someone requests it for an existing acl-conenction. But maybe
> some people want to do this.
> But maybe if you terminate the connection and want to establish it again
> without inquiry (just using the inquiry cache), the clock offset event
> is
> helpful (why do we have the inquiry cache?). Especially if you want to
> do this automatically. For the normal user this has no benefit until
> now.
>
> In this context INQUIRY_ENTRY_AGE_MAX should be set to e.g. one hour
> (see the mails from 30th. of January, Subject "Connecting with clock
> offset").
>
> But the main reason for integrating this event in bluez is:
> The clock offset event exists in the spec
> and can be generated if someone wants to do this
> and there is no reason to omit these few lines of code.
the reason to omit these few lines is that we don't get any advantages
of it and we should keep the kernel code as small as possible. We don't
put code into the kernel only because it is in the spec. The Bluetooth
spec. is not as good as it seems at some points and this is one of them.
If the clock offset event will be automaticly send on disconnect or
something else I would say "go and include it", but the fact that this
event must be requested and can only be requested with an existing
connection is the reason for me to leave it out.
If you talk about fast reconnection you will see that such a thing is
already in the kernel with the HCI_DISCONN_TIMEOUT. In this time it is
possible to reuse the ACL link.
Anyway, I have included the hci_read_clock_offset() command into the
Bluetooth library for completeness.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel