linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Mathias Baert <mathiasrobaert@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	subhoshankar.basu@ugent.be, Jeroen.Hoebeke@ugent.be
Subject: Re: BlueZ Central to Peripheral latency issue
Date: Tue, 2 Jul 2019 22:22:26 +0300	[thread overview]
Message-ID: <CABBYNZL-0mXtoQ1vUs=SWcBywET1y6A_xfd4KjTVLoE5gyp8vA@mail.gmail.com> (raw)
In-Reply-To: <CAEzhej0YJ6b+=nFXHiiZPJnSdOm=F_OaXR5kWFjvbw2107X94Q@mail.gmail.com>

Hi Mathias,

On Tue, Jul 2, 2019 at 3:33 PM Mathias Baert <mathiasrobaert@gmail.com> 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?

So I assume this is using the experimental IPSP support with Zephyr as
peripheral? Usually, the Linux side is quite a bit more complex so it
is not surprising it can take more time but not 1 sec. so it got to be
something that is causing the extra lag, perhaps you can paste the
actual commands you are using to ping one another.

-- 
Luiz Augusto von Dentz

  reply	other threads:[~2019-07-02 19:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-02 12:30 BlueZ Central to Peripheral latency issue Mathias Baert
2019-07-02 19:22 ` Luiz Augusto von Dentz [this message]
2019-08-12 11:35   ` Mathias Baert
     [not found] ` <CAAu3APb3LtRkbsGp7kFiBLYMmgKGXiqxnc96ZuBNf93E7ygXSA@mail.gmail.com>
2019-08-01 14:23   ` Mathias Baert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABBYNZL-0mXtoQ1vUs=SWcBywET1y6A_xfd4KjTVLoE5gyp8vA@mail.gmail.com' \
    --to=luiz.dentz@gmail.com \
    --cc=Jeroen.Hoebeke@ugent.be \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=mathiasrobaert@gmail.com \
    --cc=subhoshankar.basu@ugent.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).