Difference in my calculated data rate and data rate observed through att_mtu_throughput example. Why?

[Manish Kaul]

Let me first show what parameters I am choosing for calculating the data rates :

Conn interval is 7.5ms and connection length ext is off meaning it wont extend the connection interval from 7.5ms. After I 'run' the test I get

HOWEVER,

If you theoretically calculate the throughput of continuously streaming data with connection interval 7.5ms, 1M PHY, 27byte data length (meaning 41byte LL payload) and ATT MTU as 185bytes, you should get ~194Kbps. Is there some overhead that the firmware is not accounting for like cumulative time taken for printing all that out to terminal and all ? But still there shouldn't be around 60Kbps. Can you please explain what's wrong here ?

PS: I can provide the calculation if required. 

[Manish Kaul]

Also for your further analysis I recorded some observation. 

Data Rate Calc -> Theoretical Calc ; Data Rate Meas -> Measured using the mtu_att_throughput example.

[ovrebekk]

Hi Manish

Manish Kaul said:

it should be 7. On the L2CAP layer, we'd have (185+4)bytes of data to be fragmented in packets of 27 down at LL Layer. Hence 189/27=7.

My bad, I forgot that the 3 byte attribute header is included in the ATT_MTU. I agree then that the entire packet should fit in 7 equally sized on air packets. 

Manish Kaul said:

Time taken for entire journey of ONE 41 byte (14+27) packet at LL layer is 708us(41*8+2*150+80)us and hence for 7 packets 708*7us=4956us.

I think your math is slightly off. The throughput example doesn't enable encryption, so you can remove 4 bytes for the MIC from the link layer header. 

The total then would be 676us for one complete transaction. 

Manish Kaul said:

as per the theory the device shouldn't transmit until the beginning of next conn interval to transmit a 'whole' packet 'within' a connection interval. 

There is no requirement in the Bluetooth specification to send a host level packet within a single connection interval. Attributes can be up to 512 bytes in length, and can be spread over multiple connection events if needed. 

The shorter LL packets on the other hand will need to fit into a single connection interval. 

I don't know the exact limit of how many packets can be sent in a single connection interval. The theoretical maximum is 11 (676us * 11 < 7500us), but the real limitation is probably smaller. 

If the limit is 9 packets then the throughput would be around 253kbps, which is very close to the results you are seeing. 

I know the Bluetooth stack needs some time for processing at the end of every connection event, and I have forwarded a request to the stack team if they have some numbers on this. It could be that 9 packets is the theoretical maximum once you take the stack processing into account.  

Best regards
Torbjørn

[Manish Kaul]

ovrebekk said:

The throughput example doesn't enable encryption, so you can remove 4 bytes for the MIC from the link layer header. 

Are you sure I'd remove the 4 bytes ? Or will the 4 bytes be included and contain the value(=0) which indicates no encryption ? I think the latter.

So tell me if this is what I'm not doing right; I'm taking the entire 185bytes of ATT MTU as 1 entity rather than (27+Header)bytes of data at the LL layer ? Becuase right now what I'm doing is ,708us*7=4956us; INTEGER(7500us/4956us)=1 and that leaves me with 7 packets in 7500us; rather what I should do is INTEGER(7500us/708us)=11 and hence indicates 11 packets can transmit in 7500us (theoretically). Is that correct? 

ovrebekk said:

If the limit is 9 packets then the throughput would be around 253kbps

Well, even after taking your 676us into consideration, my calculations show 244.2 Kbps only.

Okay, now that things are bit more clear to me, let me run some more observations and get back to you right away. 

Warm Regards,
Manish Kaul

[ovrebekk]

Hi Manish

Manish Kaul said:

Are you sure I'd remove the 4 bytes ? Or will the 4 bytes be included and contain the value(=0) which indicates no encryption ? I think the latter.

Have you read this somewhere? If so, do you have a link?

If you look at the Link Layer packet format on page 2865 of the Bluetooth 5.2 specification (vol 6, Part B, chapter 2.1) there is no reference to the MIC, and in the Encryption and Authentication overview" chapter on page 3184 it is mentioned that "Authentication is performed by appending a MIC field to the Payload."

In other words, the MIC field is added to the payload if authentication is enabled.

Manish Kaul said:

rather what I should do is INTEGER(7500us/708us)=11 and hence indicates 11 packets can transmit in 7500us (theoretically). Is that correct? 

Essentially this is correct, but as I mentioned the stack doesn't allow you to utilize the entire connection event for sending and receiving data, so the real number will be lower than 11. 

Manish Kaul said:

Well, even after taking your 676us into consideration, my calculations show 244.2 Kbps only.

My formula goes as follows:

(185 bytes / 7 packets) * 8 bits * 9 packets pr con event * (1000ms / 7.5ms) = 253.7kbps

How does your calculation differ?

Best regards
Torbjørn

[Manish Kaul]

ovrebekk said:

Have you read this somewhere? If so, do you have a link?

I just remember seeing the flag value as 0x00 using BLE Sniffer. But thanks for that information.

ovrebekk said:

How does your calculation differ?

So, the simple formula is (effective data/total time). Total time=7500ms. Effective Data=(27*7-7)+(27*2-7)=229bytes=1832bits(7 bytes for ATT + L2CAP headers). Data Rate=1832/7500=244.2Kbps.

But now I'm thinking, the example will take all the headers as well for calculation of data throughput as it counts the entire data packets, so that makes it, Data=27*9+10+10bytes=263bytes(10+10 because for 9 packets LL header will be transmitted twice). Therefore, data rate=(263*8)/7500=280.5Kbps. Now that's very high from what's observed (253Kbps).

Which one should be correct ?