low peripheral gatt data transmit throughput with s132-5.0

RE: low peripheral gatt data transmit throughput with s132-5.0

efiLabs — Tue, 16 Jan 2018 20:41:44 GMT

thanks to Petter Myhre :

your last suggestion of increasing hvn_tx_queue_size to a larger number worked

i used the code as suggested below with the exception of setting it to 20 instead of 4

devzone.nordicsemi.com/.../

here is my code in ble_stack_init

ret_code_t err_code ;

err_code = nrf_sdh_enable_request () ;
APP_ERROR_CHECK (err_code) ;

	// Configure the BLE stack using the default settings.
	// Fetch the start address of the application RAM.
uint32_t ram_start = 0 ;
err_code = nrf_sdh_ble_default_cfg_set (APP_BLE_CONN_CFG_TAG, &ram_start) ;
APP_ERROR_CHECK (err_code) ;

	// Max Packets Per Connection Event
ble_cfg_t ble_cfg ;
::memset (&ble_cfg, 0, sizeof ble_cfg) ;
ble_cfg.conn_cfg.conn_cfg_tag = CONN_CFG_TAG ;
ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 20 ;
err_code = sd_ble_cfg_set (BLE_CONN_CFG_GATTS, &ble_cfg, ram_start) ;
APP_ERROR_CHECK (err_code) ;

	// Enable BLE stack.
err_code = nrf_sdh_ble_enable (&ram_start) ;
APP_ERROR_CHECK (err_code) ;

	// Register a handler for BLE events.
NRF_SDH_BLE_OBSERVER (m_ble_observer, APP_BLE_OBSERVER_PRIO, ::Ble_evt_handler, NULL) ;

the inserted code is under the "// Max Packets Per Connection Event" comment

i also added the following line in add_config.h

#define NRF_SDH_BLE_GAP_EVENT_LENGTH 30

the data send throughput in ble_nus_string_send -> sd_ble_gatts_hvx is now 120 byte strings in 20 byte chunks at a 45 ms period ... 120 * 22 = 2640 bytes / sec

RE: low peripheral gatt data transmit throughput with s132-5.0

Petter Myhre — Tue, 16 Jan 2018 08:36:58 GMT

Thanks for the traces. What if you increase hvn_tx_queue_size to 6? This is set when you enable the SoftDevice.

RE: low peripheral gatt data transmit throughput with s132-5.0

efiLabs — Tue, 16 Jan 2018 03:35:43 GMT

hi Petter : and thanks for the help so far

i made the following change #define NRF_SDH_BLE_GAP_EVENT_LENGTH 39 in app_config.h, but nothing changed

i also revised my testing including new wireshark traces as can be seen in a question addendum

being not too versed with ble, i do not know what to change or improve the sdk 14.2.0 results

looking at your statement : you have a connection interval of 48.75 ms

as well as looking at the data provided by ble_evt_handler -> BLE_GAP_EVT_CONNECTED i also saw the "39" * 1.25 = 48.75 ms

i assume that this can not be changed since it is enforced by the android nexus 7 central device ... or is there a way to talk the central device into it (specifically the nexus 7 or other android devices) ???

now, the sdk 12.2.0 seems to send 6 times 20 byte gatt data packages per connection interval ... can this be changed to more than 6 ???

why does the sdk 14.2.0 only seem to handle 4 or sometimes 5 times 20 byte gatt data packages per connection interval ???

how can this be changed to 6 or more ???

i read plenty of the nordic forum articles, but on some i just would not understand all the details, especially on how and where to make changes

RE: low peripheral gatt data transmit throughput with s132-5.0

Petter Myhre — Mon, 15 Jan 2018 15:32:35 GMT

From the sniffer trace I can see that you have a connection interval of 48.75 ms. This means that you should set the event length to 39.

I can also see that you have some packet loss, maybe 1 out of 4-5 packets are re-transmitted.

RE: low peripheral gatt data transmit throughput with s132-5.0

efiLabs — Mon, 15 Jan 2018 04:50:03 GMT

hi Petter :

thanks so far for your support ... i added a single wireshark trace taken from my heavy modified firmware, but the one with just the send data feed being altered from org shows the same errors in terms of dropped data ... if you could please have a quick look and maybe you can spot what's wrong with the setup

i can provide a side by side of slow and normal with the least altered firmware setups, but it's a more elaborate setup for me to create it

this trace "nrf52832-slow-varsz.pcapng" reflects test strings of "123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_123456789_" data being put into the my send queue at 100 ms periods starting with "1\r\n" and then incremented to "12\r\n" and so on until the max length and then decremented the length by 1 and so on

they are taken out of this sent queue in junks of up to 20 bytes at 5 ms periods and finally sent

please let me now if this would be sufficient for starting

RE: low peripheral gatt data transmit throughput with s132-5.0

Petter Myhre — Wed, 10 Jan 2018 10:01:02 GMT

Please send me two sniffer traces first, and we will take it from there.

RE: low peripheral gatt data transmit throughput with s132-5.0

efiLabs — Wed, 10 Jan 2018 07:32:05 GMT

to the question performance i would like to mention that the "Experimental: ATT_MTU Throughput Example" is a really nice idea, however i hope my needs for now are of easier nature like having an everyday android (nexus 7 2013) device supporting ble 4.0 communicating with the pca10040

maybe all the suggested tests with 2 pca10040 talking to each other or the larger mtu along with the data length extension are i believe options for later revs after ble 4.0, like ble 4.2 and 5.0 ... i could be wrong, sorry

i did not have a chance to repeat the wireshark traces ... no time today, but i will do it ... it's quite an elaborate setup, switching all the different firmware projects along with the right softdevices, saving the data and verifying the integrity and i'm not a wireshark expert ... worked last with it when it was called ethereal on tcp/ip pkgs i believe

with respect to the connection interval, i believe it's the central device (nexus 7) which mostly dictates the setup ... also the initial setup data is the same for both ble nus example versions 12.2 vs 14.2

measurements and observations are some stretchable terms one can be measured in time units and or data over time ... i used the term observation for the following undisturbed data amount over time

i send the following data lines, one every defined time period = 100 ms

1\r\n
12\r\n
123\r\n
1234\r\n
12345\r\n
... fill in the missing data lines
123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_1234567\r\n
123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_12345678\r\n
123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_123456789\r\n
123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_12345678\r\n
... fill in the missing data lines
124\r\n
123\r\n
12\r\n
1\r\n
123\r\n
1234\r\n
... fill in the data missing lines
and on and on

the result of this test is that as soon as the line lengths exceed about a total of 80 chars i observe (realtive measure) some data drop ... i would call this kind of setup a high level real world test setup

now the comparison measurement on a sdk 12.2 setup exhibits those data drops at a line repeat time of 30 ms which relates to a data throughput range of 3 times of the 14.2 setup

the question would be now, would this qualify as a quantified value ?

the fact from my point of view, again i could be wrong, is that both ble nus examples are as much as possible out of the box and unaltered ... the only change is that a timer feeds the nus data string of up to 20 bytes at a defined period ... the global ble configuration seems to be the same as well

i did not write either ble nus examples, nor am i an expert on the internals and details of the sdk api and softdevices ... all i provide is a measurable repeatable determined data flow into the ble nus example

so how could i effectively debug the differences of the code i didn't write

all i'm really doing is to feed the ble_nus_string_send function my data in a timed and measurable way and i do this the same way in both examples and this goes after 10 line of code directly into the soft device

the overall setup and other callback and glue is part of the example code from nordic

yes, i'm not using keil or other approved tools, my setup is in a managed project setup in eclipse

i can zip up the projects and send them to you if desired

i can also provide the wireshark traces once i repeat the testing in a couple of days

sorry for being such a pest ... all i really want to do right now is to receive and send nus data (preferably fast) and add my app code and ship it

RE: low peripheral gatt data transmit throughput with s132-5.0

Petter Myhre — Tue, 09 Jan 2018 11:29:45 GMT

What kind of performance tests do you actually want to do? Are you aware of this?

You mention sniffer traces, do you have these? Could you upload them so I can take a look at them?

Anyways, if you want to want to measure throughput in the ble_app_uart example the first step is to have some way of measuring it, so that you have a quantified value, not just observations.

You can call conn_evt_len_ext_set() from main(), like in ble_app_att_mtu_throughput example.

Status should be true if you want to enable CLE, false if you want to disable CLE.

RE: low peripheral gatt data transmit throughput with s132-5.0

efiLabs — Mon, 08 Jan 2018 21:27:34 GMT

sdk version 12.2 gets about 3 x throughput based upon the observation of data overflow at up to 100 bytes at 30 ms periods and version 14.2 experiences this overflow already at up to 100 bytes at the slower 100 ms periods

the ble nus example code has not been changed as well as any parameter #define values or any sdk_config.h values ... the sdk_config.h in each test case is the one from the matching example version

the connection interval settings on both versions are equal 20 min, 75 max and i have not changed them

the following code snippet i placed in both ble_evt_handler(s) display a min and max of 39 upon connection

switch (p_ble_evt->header.evt_id) {
case BLE_GAP_EVT_CONNECTED :
  .........
  ble_gap_conn_params_t parm = p_ble_evt->evt.gap_evt.params.connected.conn_params ;
  uint min = parm.min_conn_interval ;
  uint max = parm.max_conn_interval ;
  PRINT (" ble : Conn min %d max %d \r\n", min, max) ;
}
break ;	// BLE_GAP_EVT_CONNECTED

i have increased, as suggested, the #define NRF_SDH_BLE_GAP_EVENT_LENGTH value from it's initial value of 3 in some steps up to 15 without any really noticeable improvements

thank you for the conn_evt_len_ext_set code snippet, but where is it supposed to be placed and what value is the status parameter supposed to be or where would it come from

the android device for testing is a nexus 7 2013 running android 6.0.1 marshmallow

since both ble nus examples are being used in an out of the box fashion with the same minor test mods applied one would expect an equal behavior or even a slightly better one from the 14.2 sdk

it's hard, for a not too ble experienced person, to make freely changes not really knowing of their impacts

so far i have made many successful changes in implementing my own code, which is not ble related, like adc, uart, timer, intrs and application related classes and more, but in an other project and it's progressing fine

i just need to button up this ble performance issue and the ble related part of the app should be solved

sorry, but i'm at a beginner level when it comes to ble.

RE: low peripheral gatt data transmit throughput with s132-5.0

Petter Myhre — Mon, 08 Jan 2018 13:29:23 GMT

What throughput do you get with 12.2 versus 14.2? Do you have the same connection interval?

Have you tried to increase the event length? NRF_SDH_BLE_GAP_EVENT_LENGTH

Have you enabled connection event length extension?

static void conn_evt_len_ext_set(bool status)
{
    ret_code_t err_code;
    ble_opt_t  opt;

    memset(&opt, 0x00, sizeof(opt));
    opt.common_opt.conn_evt_ext.enable = status ? 1 : 0;

    err_code = sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt);
    APP_ERROR_CHECK(err_code);
}