Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Petter Myhre — Tue, 09 Jan 2018 14:12:54 GMT

Correct! No problem :) I didn't get it correct the first time I looked at it either ;)

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Mathias — Tue, 09 Jan 2018 14:01:29 GMT

Here I indeed forgot that DLE ON ONLY influences the SoftDevice check, not the real communication because indeed the MTU is still only 23.

For DLE ON

With the 80 µs for the empty packet and DLE only influencing the full packet exchange check , this gives 708 µs for one real exchange (full one way, empty the other) and 4540 µs for the full both ways check exchange. Here substracting 7.5 ms with 708 µs before 4540 µs doesn't fit in it anymore, this is possible 5 times but indeed again the last substraction is already from 4668 µs which is already close to 4540 µs so in a non ideal situation with other factors influencing, 4 times or thus 4 packets is more reachable.

Do I understand it correctly now? Thanks for all your help already Petter, as always!

Kind regards

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Mathias — Tue, 09 Jan 2018 13:54:52 GMT

Yeah, wasn't sure about the empty packet being encrypted or not. So thats 80 µs for an empty packet under the given conditions, instead of 112 µs.

Aha, I think I get were I'm wrong now. The check is done after each exchange and only for the next exchange. That's what I forgot I think. So:

For DLE OFF

With the 80 µs for the empty packet, this gives 708 µs for one real exchange (full one way, empty the other) and 956 µs for the full both ways check exchange. 708 µs fits 10 times into 7.5 ms. If I substract it 9 times from 7.5 ms, I get 1128 µs. 956 µs still fits there, so here a 10th packet would theoretically still be possible. But as you say, there is only around 150 µs of extra time here so in a non ideal situation this will be 9 then as we get in the experiment. 2nd comment following below.

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Petter Myhre — Tue, 09 Jan 2018 13:36:57 GMT

For DLE ON Yes. The SoftDevice will check that. So when a connection event starts it will check, do one exchange, check if there is more time, do one exchange, check and so on, until there isn't time to do a full packet exchange because the connection event is ending. Checking isn't the same as doing a full packet exchange.

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Petter Myhre — Tue, 09 Jan 2018 13:33:38 GMT

For DLE OFF Yes, it does. There is no MIC in empty or un-encrypted packets. Anyways, after 9 packet pairs have been exchanged (full one way, empty one way) the SoftDevice will check if there is time to do one more exchange, with full packets both ways. And because of this I assume you end up with 9, not 10. Also remember that your calculations are not only theoretical, they are ideal, not including clock drift, SoftDevice overhead and so on.

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Mathias — Tue, 09 Jan 2018 10:31:38 GMT

For DLE ON Yes, I also know this. But in this question you commented on your answer that the SoftDevice checks if it is possible to send a full packet before scheduling a next packet in a connection event (and in this case, the SoftDevice takes 251 bytes for a full packet's L2CAP part I think). If I use your remark about the empty RX also being used in the check of the SoftDevice, I here get 7.5 ms / (112 µs + 150 µs + 2120 µs + 150 µs) = 2.96 => 2 packets. This gives (2 packets * 20 bytes * 8) / 7.5 ms = 42.66 kbps, which is still less then the experimental throughput that I get for this case.

I'm sorry Petter, but it's still unclear to me what I'm doing/assuming wrongly here... Very sorry for the inconvenience and trouble.

Kind regards

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Mathias — Tue, 09 Jan 2018 10:25:26 GMT

For DLE OFF Yes, I know this. That's what I mean by the real RX packet being much smaller (empty PDU) but I thought that for checking if another packet could be scheduled in the connection event, the SoftDevice uses a RX & TX check for both full packets. Anyway, if I calculate the time for an empty packet, I get (1 (Preamble) + 4 (Access Address) + 2 (LL Header) + 4 (MIC, because encryption seems to be done in the example as well) + 3 (CRC) bytes) * 8 ) / 1 Mbps = 112 µs. If I then calculate the amount of packets per interval again, I get 7.5 ms / (112 µs + 150 µs + 328 µs + 150 µs) = 10.135 => 10 packets. This gives a theoretical throughput of (10 packets * 20 bytes * 8) / 7.5 ms = 213.33 kbps, which is more then what the experiment produces. Again, I think I should calculate 9 packets per connection interval to get around the same throughput as in the experiment. 2nd comment following below.

RE: Theoretical throughput doesn't match experiments done via ble_app_att_mtu_throughput example

Petter Myhre — Tue, 09 Jan 2018 09:57:13 GMT

For DLE OFF - you are assuming that you are sending full packets both ways, which you are not. You are sending full packets one way, empty the other.

For DLE ON - Here I assume you still have an ATT MTU of 23? Then the L2CAP packets will still be 27 bytes. You need to increase the ATT MTU to take advantage of DLE.

Is anything still unclear?