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. 

[ovrebekk]

Hi Manish

How many packets are you calculating per connection interval?

When you have two nRF52 devices talking to each other there is really no upper limit on the number of packets you can send in one connection interval, other than the total time it takes to send them. In other words you should be able to send as much as 11-12 packets pr connection interval, depending on the length of each packet. 

With this in mind my calculations point to something around 250 kbps, assuming you don't have any packet loss. 

Best regards
Torbjørn

[Manish Kaul]

packets per interval are maximum as it's a continuous stream.
If I've set a conn. interval of 7.5ms and in this example also set the connection interval extension OFF, I would assume it won't extend the length of the connection beyond 7.5ms. So depending on the ATT_MTU, Data length at LL, I believe it would take the max packets that can transfer in one interval. 
With the above mentioned input parameters (MTU=185bytes, data length=27, conn interval=7.5ms, conn_len_ext=off) total time it takes for 1 entire data packet to transfer is 4956us (including IFS and response packet timings) and hence in a 7.5ms(7500us) interval I take 2 packets in that connection interval and that corresponds to ~194Kbps of actual throughput. 

[ovrebekk]

Hi Manish

Manish Kaul said:

I would assume it won't extend the length of the connection beyond 7.5ms.

Correct. 

Manish Kaul said:

total time it takes for 1 entire data packet to transfer is 4956us

When you say '1 entire packet', I assume you mean the entire 185 byte attribute MTU?

If my math is correct each 185 byte attribute MTU would have to be split in 8 on air packets, with a data length of only 27 bytes. 

The first packet would contain 20 bytes of attribute data plus the attribute and L2CAP headers. The following 6 packets would contain 27 bytes of attribute data, while the last packet would contain the remaining 3 bytes of attribute data. 

The total time to send this, including 2x TIFS and the empty packet from the peer, should be 5216us if my math is correct. 

A single 185 byte payload pr 7.5ms interval is close to the 194Kbps throughput you mention, but since there is still 2284us free after sending the 8 packets I mentioned earlier the stack should be able to start on the next 8 packet sequence before the connection event is over, which is why the actual throughput will be higher. 

Best regards
Torbjørn

[Manish Kaul]

ovrebekk said:

When you say '1 entire packet', I assume you mean the entire 185 byte attribute MTU?

Yes, that's what I mean.

ovrebekk said:

split in 8 on air packets,

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.

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.

Now for the remaining 2544us (or 2284us acc to your calculation) 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. 

Is what you're saying that, connection interval in a way extends by the remaining time amount(2544us/2284us) or are you saying that only data that can be transmitted in the remaining time of the conn interval(2544us/2284us) is transmitted and the rest is done at the onset of next interval ? Because this makes me question the whole concept of connection interval then.

What exactly is implemented in this stack and is it a standard practice or way of measuring the throughput?

[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