Connection time behaviour question

Connection time behaviour question

[Simon Hay]

Hi,

I have a question about behaviour establishing connections that seems  
to have changed between different versions of BlueZ, and I'm hoping  
someone will be good enough to help explain what's going on for me!

I have a test program that opens an L2CAP connection to a device,  
reads the RSSI, closes it again, waits a few seconds and repeats the  
process.  Optionally, it will do clock caching - i.e. read the clock  
offset when a connection is established and pass this in when making  
the next connection.  Using version 3.18 the BlueZ libraries, this  
behaves more or less as I would expect:  if clock caching is not  
turned on, the connection times are distributed fairly evenly and if  
it is they are much quicker and fairly constant (e.g. 1300 ms, plus or  
minus a hundred or so for a particular device).  Using various  
subsequent versions however (in particular 3.29 and 4.22) we see  
different behaviour: whether clock caching is turned on or not, the  
connection times follow a sawtooth pattern, starting very low (about  
100 ms), then going up steadily in increments of a couple of hundred  
ms until they reach a peak (1000-2000) and then fall back to a very  
low value and the process repeats.  I'm somewhat confused as to why  
this is happening - I've tried to read through the code changes but  
without much success.  Can anyone shed any light on this for me?

Thanks very much in advance for your help!

Simon

Re: Connection time behaviour question

[Marcel Holtmann]

Hi Simon,

> I have a question about behaviour establishing connections that seems  
> to have changed between different versions of BlueZ, and I'm hoping  
> someone will be good enough to help explain what's going on for me!
> 
> I have a test program that opens an L2CAP connection to a device,  
> reads the RSSI, closes it again, waits a few seconds and repeats the  
> process.  Optionally, it will do clock caching - i.e. read the clock  
> offset when a connection is established and pass this in when making  
> the next connection.  Using version 3.18 the BlueZ libraries, this  
> behaves more or less as I would expect:  if clock caching is not  
> turned on, the connection times are distributed fairly evenly and if  
> it is they are much quicker and fairly constant (e.g. 1300 ms, plus or  
> minus a hundred or so for a particular device).  Using various  
> subsequent versions however (in particular 3.29 and 4.22) we see  
> different behaviour: whether clock caching is turned on or not, the  
> connection times follow a sawtooth pattern, starting very low (about  
> 100 ms), then going up steadily in increments of a couple of hundred  
> ms until they reach a peak (1000-2000) and then fall back to a very  
> low value and the process repeats.  I'm somewhat confused as to why  
> this is happening - I've tried to read through the code changes but  
> without much success.  Can anyone shed any light on this for me?

I don't see any issue here, but the whole concept of connecting to a
remote device to read its RSSI is broken by design. The RSSI value of an
already connection is basically useless. What you want is the link
quality, but even that doesn't really help you since it is vendor
specific and every company defines it differently.

Regards

Marcel

Re: Connection time behaviour question

[Simon Hay]

Hi Marcel,

On 19 Dec 2008, at 18:49, Marcel Holtmann wrote:

>
> I don't see any issue here, but the whole concept of connecting to a
> remote device to read its RSSI is broken by design. The RSSI value  
> of an
> already connection is basically useless. What you want is the link
> quality, but even that doesn't really help you since it is vendor
> specific and every company defines it differently.


Thanks for the reply.  I appreciate your point about RSSI vs link  
quality, and understand the issue there, but actually that's  
incidental to the point I'm really trying to understand - reading the  
RSSI is just something to do with the connection before I throw it  
away again.  I'm trying to get to the bottom of what's changed to  
cause the different behaviour in the connection times - why passing in  
a clock offset doesn't seem to make a difference any more, and why we  
see this regular pattern of times going up and up then jumping back  
down again.  Is there anything that was deliberately changed in this  
regard, or is it a side effect of something else?

I really appreciate all your help and patience on this!

Simon

Re: Connection time behaviour question

[Marcel Holtmann]

Hi Simon,

> > I don't see any issue here, but the whole concept of connecting to a
> > remote device to read its RSSI is broken by design. The RSSI value  
> > of an
> > already connection is basically useless. What you want is the link
> > quality, but even that doesn't really help you since it is vendor
> > specific and every company defines it differently.
> 
> 
> Thanks for the reply.  I appreciate your point about RSSI vs link  
> quality, and understand the issue there, but actually that's  
> incidental to the point I'm really trying to understand - reading the  
> RSSI is just something to do with the connection before I throw it  
> away again.  I'm trying to get to the bottom of what's changed to  
> cause the different behaviour in the connection times - why passing in  
> a clock offset doesn't seem to make a difference any more, and why we  
> see this regular pattern of times going up and up then jumping back  
> down again.  Is there anything that was deliberately changed in this  
> regard, or is it a side effect of something else?

you can't pass in the clock offset except you use the low-level HCI
Create Connection command. And that is not guaranteed to work as
expected at all. The kernel has full control over these information and
you should not mess with it. However when reading the clock offset of a
remote connection the kernel will store that clock offset and reuse
during the next connection attempt. You have to create proper L2CAP
connections and not just fake them via HCI Create Connection.

Regards

Marcel