Re: BlueZ Central to Peripheral latency issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Barry,

I'm using the IPv6 over BLE implementation, which does not use the
GATT layer for actual data communication. It directly interacts with
the L2CAP channel, via LE Credit Based Flow Control Mode. So I'm using
neither of these methods.

Kind regards,

Mathias

On Tue, Jul 2, 2019 at 3:34 PM Barry Byford <31baz66@xxxxxxxxx> wrote:
>
> Hi Mathias,
>
> Are you using WriteValue:
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt?h=5.48#n79
> or AcquireWrite
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt?h=5.48#n94
> method?
>
> Regards,
> Barry
>
> On Tue, 2 Jul 2019 at 13:32, Mathias Baert <mathiasrobaert@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > We are using the BlueZ 5.48 version on a Raspberry PI with Raspbian Stretch 9.1.
> >
> > The setup is this PI connected with a Nordic Semiconductor nRF52840
> > device, via an IPv6 over BLE connection. The connection is using a
> > connection interval of 7.5 ms. Via throughput measurements with iperf,
> > both ways (central to peripheral and peripheral to central), we are
> > able to achieve maximally ~ 100 kbps (using the 1 Mbps PHY).
> >
> > However, when looking into individual packet exchanges, we notice a
> > significant delay (up to 1 sec) in the RTT when pinging from the
> > peripheral to the BlueZ central and back. We also see a huge
> > fluctuation in this value and it also depends on the intervals at
> > which the pings are fired (lower throughput gives a much higher
> > average individual latency). When firing ping packets at a 1 sec
> > interval, it is definitely visible.
> >
> > When looking into this, we found that the latency between the
> > peripheral and the central is quite stable and low enough. But the
> > latency between the central and peripheral is fluctuating a lot and is
> > generally quite high. Is this something you have noticed before? We
> > think that it could be a scheduling issue on the kernel, where higher
> > throughput gives more priority to Bluetooth communication?
> >
> > Thanks in advance.
> >
> > Kind regards,
> >
> > Mathias Baert



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux