throughput output

[Martijn Jonkers]

Hi,

I have the following ouput using the throughput example:

[local] sent 660264 bytes (644 KB) in 4540 ms at 1190912 bps (145 kBps)
[peer] received 660264 bytes (644 KB) in 2706 GATT writes at 1135105 bps (138 kBps)

Altered output format a bit to give me the same for local and peer.

But I was wondering why there is a significant difference between transfer by local and reception by peer. Shouldn't this be about the same and not 7 kBps difference? What is transferred is received on the other end, so the same throughput, right?

[Håkon Alseth]

Hi,

 

You're right, the timing anchor is stored before receiving the first "payload" packet:

https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/bluetooth/services/throughput.c#L61-L67

 

The connection interval is a factor as well. I tested quickly by updating "clock_cycles" on the first entry of the "else", and lowered the connection interval; it showed a more equal result, but still differed a bit (1327 kBit/s vs. 1313 kBit/s at my end). Longer interval shows higher difference.

 

Kind regards,

Håkon

[Martijn Jonkers]

I played a bit with this and I do not really get what is going on. I also set the 'clock_cycles' on the fist entry of else:

	if (len == 1) {
		/* reset metrics */
		kb = 0;
		met_data->write_count = 0;
		met_data->write_len = 0;
		met_data->write_rate = 0;
		clock_cycles = 0;
	} else {
		if(met_data->write_count == 0) {
			clock_cycles = k_cycle_get_32();
		}
		met_data->write_count++;
		met_data->write_len += len;
		met_data->write_rate =
		    ((uint64_t)met_data->write_len << 3) * 1000000000 / delta;
	}

and set the connection interval to 3200 units and I do not understand this result. Why would the reception rate be higher than the transmission rate?

[local] sent 660264 bytes (644 KB) in 7254 ms at 745472 bps (91 kBps)
[peer] received 660264 bytes (644 KB) in 2706 GATT writes at 1401786 bps (171 kBps)

When I set the connection interval to 6 units. Now I get this as a result, which is more as expected. but still not the same.

[local] sent 660264 bytes (644 KB) in 5170 ms at 1045504 bps (127 kBps)
[peer] received 660264 bytes (644 KB) in 2706 GATT writes at 1018568 bps (124 kBps)

[Håkon Alseth]

It looks like your first result is shifted by up to one connection interval:

Martijn Jonkers said:

3200 units

3200*1.25ms = 4 seconds.

7.254s - 644kB/171kB = 3.5 s.

 

In your updated approach, "delta" will now be incorrectly calculated from 0, and this is likely the reason for the strange timing result.

 

Kind regards,

Håkon

 

[Martijn Jonkers]

ah ok! The lower reception throughput I get now.

I noticed it too, as you say, 'delta' is incorrect the first time with my implementation. But delta is only used for calculating 'met_data->write_rate' and that value is overwritten each time data comes in. So the final write_rate should be as expected. right? So, I suspect the reception rate should be correct. Which corresponds to 1.368 kbps, which is almost the max as described here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fble_data_throughput%2Fble_data_throughput.html . And is the transfer rate I expected was possible.

Because the clock_cycles is set on first reception with my implementation, this skips the 500ms delay on the master and 4 sec connection interval. So, the data rate is measured from first packet to last, without any connection interval delays. correct?

I did notice in the original implementation the timing is started on the peer when the metrics are reset. But the central adds a 500ms delay after resetting the metrics to let any ble procedures complete. This 500ms is also added to the time it takes to receive data. But on the master this 500ms is skipped, beecause the start time is determined after the delay. This would always result in a lower reception rate compared to tranmission rate, right? reception time is always 500ms longer than transfer time.

[Martijn Jonkers]

another question: I notice the overall throughput goes down when I set a connection interval of 6 units. Is there a connection overhead for the connection interval? It looks like as if more data is transferred, even between data packets.