L2CAP COC: buffer configuration errors

[haukepetersen]

Hej guys,

I am currently struggling with the configuration of NimBLE's buffer sizes. I was under the impression, that my fixes in #315 did actually lead to a more efficient and better memory usage. Now after some digging, I found that the new default value for MYNEWT_VAL_BLE_L2CAP_COC_MTU which I introduced it somehow leading to all l2cap_coc packets > 250 bytes to be dropped silently by NimBLE. I was under the impression, that this value is only used for internal packet fragmentation in the host, but is it possible, that this MTU size is also somehow related to the actual packet size that is used by the controller?

Could someone maybe help me to understand a little better so I can provide a proper fix... Especially why the limit seems to be exactly 250 would be nice to know and I could not yet figure it out from the code.

For now my work-around is simply to set the value to 250 for my test code, but it would be nicer to do something like min(250, MYNEWT_VAL_MSYS_1_BLOCK_SIZE - 8) or the like...

[haukepetersen]

To add to the (or better my) confusion: when setting the L2CAP_COC_MTU to 100, the throughput of my test setup is significantly better then setting the same value to 250, roughly by the factor of 2. I actually would expect a similar performance as the link layer MTU should be the same(?!), so I wonder where this heavy decrease in throughput in coming from...

Test setup:

• two nodes running NimBLE (a7b3c93) on RIOT: https://github.com/haukepetersen/RIOT/tree/add_ccnble/examples/l2cap_echo
• one is a simple L2CAP COC echo server, simply sending everything back it receives on a given L2CAP COC channel
• the other sends an increasing payload, starting from 4 bytes up to 5000 bytes. Each time a chunk is sent, the client waits for the packet to be returned by the server.

[rymanluk]

could you please check if "silently dropping" can be solved with this PR #378 ?

I renamed BLE_L2CAP_COC_MTU -> MPS as that might be confusing. MTU in the context of COC is whan applications sets for complete SDU.

Regarding your test setup - what is the MSYS_1 block size?

[haukepetersen]

yes certainly, will do a test run tomorrow (anyone else at the IETF hackathon in Prague by the way?)

Sorry for not giving the complete details on my test setup, I am using the default values from porting/npl/riot/include/syscfg/syscfg.h, namely #define MYNEWT_VAL_MSYS_1_BLOCK_SIZE (292).

I also PRed my test application to RIOT, so it might be easier for others to reproduce my results: RIOT-OS/RIOT#11235

[haukepetersen]

The 'stuck' issue is solved by #378.

However, I am still wondering what is causing the throughput degradation for larger L2CAP MPS values, I can't seem to find a valid explanation (yet)...

[haukepetersen]

Its been a while and I recently did some more experiments in this direction: I setup a raw-L2CAP flood test between two nrf52dk boards, using the NimBLE host and controller. For the test, I repeatedly send 5000 chunks with a given size as fast as I could (looping the l2cap_send() function until all 5000 chunks got a positive return code). I then repeated this for varying chunksizes from 1 to 1200 bytes:

For some reasons, the throughput decreases significantly for selected chunk sizes. I wonder if this behavior is connected to the observations described above?!