• State Verified Answer
  • Replies 6 replies
  • Subscribers 75 subscribers
  • Views 1696 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 264087
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF Connect DFU speed difference Windows vs Mac OS

WoutEcto

Hi,

We are using the nRF Connect for Desktop app to update production devices to the latest FW version of our application. I (on Windows) am normally the only person in my organization to do this, but yesterday my colleague (on Mac) helped out because we had a higher than normal number of devices to update. While I'm normally getting only around 0.25kB/s during the DFU (which I already found was very low), I noticed that my colleague got a throughput of around 2.2kB/s. Is there a (known) difference in the throughput between Windows and Mac?

We both have nRF Connect v3.6.1 installed, we both use the nRF52 DK v2.1.0 as the central and we are both updating the exact same hardware with the exact same bootloader and softdevice pre-installed with the exact same application firmware. This seems to rule out this issue (if that's still a thing even).

I have not tried to use the nRF Sniffer yet to see if there are different connection parameters negotiated, but since we are both just connecting and updating, I would expect the default settings to apply for both. Unless the default settings for Windows and Mac are known to differ, I can try to sniff the communication if that would help.

Best, Wout

Parents
  • 0

    Hi Wout, 

    I need the Sniffer log to check. Please kindly provide the sniffer log if it is possible. 

    -Amanda H.

  • 0 in reply to Amanda Hsieh

    Hi Amanda,

    Thank you for your quick response. I have only been able to get the sniffer log today, you can find both attached. I had a very quick look through both of them side by side but I couldn't find an immediate reason.

    windows_nrf_connect_dfu.pcapng

    mac_nrf_connect_dfu.pcapng

    Best, Wout

  • 0 in reply to WoutEcto

    Hi Wout, 

    I'm normally getting only around 0.25kB/s during the DFU (which I already found was very low), I noticed that my colleague got a throughput of around 2.2kB/s. Is there a (known) difference in the throughput between Windows and Mac?

    Which SDK you are using?

    I use BLE bootloader in SDK 17.0.2 and nRF Connect for Desktop app on windows to update with hrs application. I see the average throughput is around 2.4 kB/s.

     

    -Amanda H.

  • 0 in reply to Amanda Hsieh

    Hi Amanda,

    We are indeed using a pretty old SDK, SDKV14.0.0. I'm aware that there have been some major improvements with later SDK versions that would speed up the process, but it's a piece of legacy code that we would like to keep as it is for the moment.

    My main trigger for asking this question was why there's such a big difference between using different computers when performing the DFU. I have asked another colleague who has a Windows system and he was able to reach 1.6kB/s. Still not as high as the 2.2kB/s that the (single) Mac system could achieve, but at least already an order of magnitude higher than the throughput I can achieve. 

    Since we are using the exact same nRF Connect version, bootloader version, application version, nRF52DK version and softdevice version, is there any known reason why the USB communication or even the PC itself may be the bottleneck in performing the DFU?

    I have a fair bit of software development tools installed on my system, especially compared to my other colleagues who have tried to perform the DFU as well. Could it be that there is some core library outside of the nRF Connect installed code that has changed or is outdated on my system that may be responsible for slowing things down?

    The throughput is similar after performing a restart, so it doesn't seem to be a driver issue.

    Best, Wout

  • +1 in reply to WoutEcto

    Hi Wout, 

    The throughput in the sniffer logs looks the same for me. 

    WoutEcto said:
    is there any known reason why the USB communication or even the PC itself may be the bottleneck in performing the DFU?

    The USB communication could be the reason because the protocol in connectivity is very verbose and the drivers at least on Windows are known to be slow. The protocol used between the application and connectivity firmware is H5. In H5 every packet sent is acknowledged.

    WoutEcto said:
    Could it be that there is some core library outside of the nRF Connect installed code that has changed or is outdated on my system that may be responsible for slowing things down?

    You could try the following, but I don't think that will improve a lot. I use J-link v6.88a and disable the mass storage device functionality to test SDK v14 BLE DFU update hr app to nRF52DK. I see the throughput is around 0.28kB/s in the ble app.

    -Amanda H.

Reply
  • +1 in reply to WoutEcto

    Hi Wout, 

    The throughput in the sniffer logs looks the same for me. 

    WoutEcto said:
    is there any known reason why the USB communication or even the PC itself may be the bottleneck in performing the DFU?

    The USB communication could be the reason because the protocol in connectivity is very verbose and the drivers at least on Windows are known to be slow. The protocol used between the application and connectivity firmware is H5. In H5 every packet sent is acknowledged.

    WoutEcto said:
    Could it be that there is some core library outside of the nRF Connect installed code that has changed or is outdated on my system that may be responsible for slowing things down?

    You could try the following, but I don't think that will improve a lot. I use J-link v6.88a and disable the mass storage device functionality to test SDK v14 BLE DFU update hr app to nRF52DK. I see the throughput is around 0.28kB/s in the ble app.

    -Amanda H.

Children
  • 0 in reply to Amanda Hsieh

    Hi Amanda,

    Unfortunately, your picture is not visible to me, but I'm also on J-Link v6.88a.

    I have tried to follow your steps but the throughput stays the same. Small note, after updating the J-Link firmware version (from here), the nRF52 DK again shows up as MSD. So I guess disabling the MSD should come after updating the firmware? Or did you not mean to follow those steps sequentially?

    In any case, it seems that I'm stuck with slow drivers/hardware then. Since this was not really an issue but more a question to try and understand what's going on, I'll close my question and mark your response as the answer.

    Thank you for helping me!

    Best, Wout

Related
Terms of service