Download client slows down when using CONFIG_DFU_TARGET

[samuel4]

Hi

We encountered speed issues with the download client library and CONFIG_DFU_TARGET. The problem can be reproduced using the download example. Without any changes I usually get download speeds arround 15-25 KB/s.

Adding the configuration options

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_DFU_TARGET=y

lead to download speeds below 10 KB/s. I repeated that a lot to ensure there is a correlation and in fact, it is really reproducible here.

Do you have any idea what's going wrong there?

Test enviroment:
NRF9160DK (current revision)
SDK: v2.1.0
Modem: v1.3.2

Regards
Samuel

[Håkon Alseth]

Hi,

 

At my end, the RSRP is around 40 (ie. -100 dBm), so the signal strength might throw me off when testing, but I do see that things like printing etc will have a great effect on the overall download time.

We encountered speed issues with the download client library and CONFIG_DFU_TARGET. The problem can be reproduced using the download example. Without any changes I usually get download speeds arround 15-25 KB/s.

Adding the configuration options

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_DFU_TARGET=y

Since the dfu_target library isn't directly used in the samples/nrf9160/download sample, it will not be compiled in either (ie. it is dumped by the linker), so it is very strange that this has an overall effect on the  download speed itself.

I tried to only enable one, or the other, and did not see any difference directly with CONFIG_BOOTLOADER_MCUBOOT myself.

In both cases, I was able to see between 8-12 kB/s, but my signal strength can have a greater impact. In a peak-scenario, I got 17 kB/s.

 

How is the RSRP at your end?

Does the speed change if you reset the nRF? 

 

Note: if you reset several times within a short timeframe, the modem reset loop detection will hit and you'll need to power cycle your DK.

 

Kind regards,

Håkon

[samuel4]

Hi

Thanks for your answer. I checked the signal strength. It's always between 48 and 49, so -91...92dBm.

I also did  some measurements again, it is very reproducible here and it's really just that one config option commented in or out:

Bytes/s DFU_TARGET=n	Bytes/s DFU_TARGET=y
20480	9208
18899	8323
17793	7808
14228	7364
17492	8437
17936	8694
17591	7918
13368	8604
16936	8453

Between the runs I either flashed the other application, did resets or power cycles. Resetting the nrf9160 gives similar download speeds for each column.

Håkon Alseth said:

I tried to only enable one, or the other, and did not see any difference directly with CONFIG_BOOTLOADER_MCUBOOT myself.

CONFIG_BOOTLOADER_MCUBOOT is always enabled here. I can't enable CONFIG_DFU_TARGET without mcuboot, because it results in compiler errors.

Enabling CONFIG_BOOTLOADER_MCUBOOT doesn't change the download speed, but enabling CONFIG_DFU_TARGET additionally.

I agree, that the behaviour is really strange, but the speed difference is significant :/

Regards,
Samuel

EDIT:

I have got an idea - it might be easier than I have thaught: CONFIG_DFU_TARGET sets CONFIG_DFU_TARGET_MODEM_DELTA, which sets CONFIG_DOWNLOAD_CLIENT_RANGE_REQUESTS. If I get it right, without range requests data will be send without flow control. If the nrf9160 is too slow too handle incoming data, packets get lost and need to be retransmitted.

To be honest, I am not sure, if it's a good idea to enable range request, since the penalty seems to be high.

[Håkon Alseth]

Hi,

 

samuel4 said:

I have got an idea - it might be easier than I have thaught: CONFIG_DFU_TARGET sets CONFIG_DFU_TARGET_MODEM_DELTA, which sets CONFIG_DOWNLOAD_CLIENT_RANGE_REQUESTS. If I get it right, without range requests data will be send without flow control. If the nrf9160 is too slow too handle incoming data, packets get lost and need to be retransmitted.

Thanks for updating with your findings. This issue had me, and colleagues, quite puzzled, as the DFU_TARGET itself was completely removed by the linker. However, this little detail which is implied by the DFU_TARGET_MODEM_DELTA kconfig entry has an impact on the overall throughput. Great work on finding this!

 

Using range requests is good if you're downloading a larger file, and your connection is somehow interrupted, which allows you to resume your download. Even though this adds some overhead, it can potentially save you bandwidth if conditions are a bit rough when downloading.

 

Kind regards,

Håkon