toggle quoted messageShow quoted text
I guess that is because with more buffer one can queue more data and
is less affected by the speed in which the controller acknowledge
their transmissions, obviously this increase the footprint but it is
the usual trade of size for speed. Btw, if the improvement is
substantial maybe we should have 3 by default, though we need to
figure if the crash on windows is due to some misbehaviour on our side
when are operating with more buffers.
On Fri, Sep 21, 2018 at 1:58 PM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:
Copying a few people to this thread.
From: firstname.lastname@example.org <email@example.com> on
behalf of firstname.lastname@example.org <email@example.com>
Sent: Thursday, September 20, 2018 11:56 AM
Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack
I am working on a BLE HID keyboard application using zephyr 1.13.
I was playing around with Tx buffers (specifically Maximum number of pending
TX buffers, Number of Tx buffers).
With default buffer settings the characters were transmitted very slowly due
to small number of buffers. But as soon as
i increased it to 3 pending buffers and 3 Tx buffers i saw significant
improvement in the speed of characters transmitted.
My question is how to choose the buffer values for this?.
The reason is currently i face a compatibility problem with my HID
application, where it works fine in Linux, Android, iOS devices
with increased number of buffers, but crashes on windows system. When i
debugged the HCI log (from btmon) i saw that with
increased buffers, characters are sent very quickly on the order of 500 us
for each character. This causes the data (of 20 characters)
to be transmitted within one or two connection intervals. Maybe this causes
some overflow in windows systems. I would like to know
what are the implications of choosing a number of Tx buffers and pending
It will be helpful if anyone can tell how to choose the number of Tx
buffers? or even point to some direction in the BLE specification?
Dhananjay G J