• State Verified Answer
  • Replies 3 replies
  • Subscribers 96 subscribers
  • Views 731 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 298725
Options

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

Parents
  • 0

    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

  • +1 in reply to Håkon Alseth

    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.

  • 0 in reply to samuel4

    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

Reply
  • 0 in reply to samuel4

    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

Children
No Data
Related
Terms of service