Thanks Chris, this is very helpful. When I disable data length extension, I do get a much lower throughput. So that now makes sense. A strange side effect of disabling data length extension is that the mac's BLE stack now refuses the requested 240 MTU and sets it at 104, whereas the 240 value is accepted when data length extension is enabled.
On Wed, Dec 7, 2016 at 6:06 AM, Christopher Collins <[email protected]> wrote: > Hi Gilles, > > I'm afraid the timing figures are a bit over my head, so I'll let the > resident controller expert address those. > > Regarding data length extension on MacOS- unfortunately, I am not in a > position to test this at the moment, but I was under the impression that > recent versions of MacOS do support it. Data length extension is > enabled by default in the NimBLE controller, so this is a plausible > explanation. > > You can disable data length extension by setting the > BLE_LL_CFG_FEAT_DATA_LEN_EXT syscfg setting to 0. This can be done as > follows: > > newt target set <target-name> syscfg=BLE_LL_CFG_FEAT_DATA_LEN_EXT=0 > > Alternatively, you can edit your target's syscfg.yml file by hand > (targets/<target-name>/syscfg.yml) to include the following entry: > > syscfg.vals: > BLE_LL_CFG_FEAT_DATA_LEN_EXT: 0 > > It would be interesting to see if the throughput decreases when data > length extension is disabled. > > Thanks, > Chris > > On Tue, Dec 06, 2016 at 11:51:24PM -0800, Gilles Boccon-Gibod wrote: > > I'm struggling with some puzzling numbers I'm getting while trying to > > maximize transfer throughput over GATT. > > I have a simple setup: a macbook pro sending data by writing > > characteristics to a GATT server running on an nRF52DK board running > mynewt. > > The default MTU of 240 is accepted by the mac, and the characteristic is > > setup for Write Without Response. > > I am writing 200 bytes of characteristic value in a loop, as fast as > > possible. > > What I observe doesn't make sense: I get about 45kB/s (Kilo Bytes) > > From basic calculations, the max should less than 40kB/s, unless I'm > > missing something: > > > > When blasting characteristics that way, the master will send packets with > > the max PDU size (27), which should be 37 bytes (27 PDU + 10 bytes > > overhead). The slave will respond with Empty PDU packets of 10 bytes each > > (0 PDU + 10 bytes overhead). > > If we take into account the 150 us interframe spacing, a master/slave > > packet cycle should take: > > 296 + 150 + 80 + 150 = 676 bits (37 bytes is 296 bits). That's 676 > > microseconds. > > With a max PDU of 27 bytes, that's 39940 bytes/s of PDU throughput. > > When writing characteristics with a 200 byte value, the total payload to > > transfer is 207 bytes: 200 bytes of value + 3 bytes of GATT op code and > > attribute handle + 4 bytes of L2CAP length/flags. So that's a ratio of > > 200/207 of effective payload, which gives us 38590 bytes/s of effective > > throughput in the best case. > > > > So how can I be observing over > 45 kbytes/s in my test? Is it possible > > that the interframe spacing isn't always fixed as 150 us? Or is it that > > between macOS Sierra and the nrf52/mynewt stack the PDU isn't capped at > 27 > > (which would imply LE Data Length Extension, which I thought wasn't > > supported on MacOS)? > > > > Any clues? >
