I was in the midst of writing a reply when I saw this so it looks like the question is answered. :-)
BTW: the 150 usec IFS is always fixed and cannot change. > On Dec 7, 2016, at 10:07 AM, Gilles Boccon-Gibod <[email protected]> wrote: > > 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? >>
