This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF9160 DK maximum throughput

Hi Nordic team,

We are busy testing the throughput of the nRF9160. We are having issues installing the NCS at this stage, and was thus provided with a HEX file of the Serial LTE Modem app by a Nordic team member in order to be able to test the product.

According to the nRF9160 product brief, the throughput of the modem on a LTE CATM1 network should be 300 kbps DL and 375 kbps UL.

We are testing our device on a test network using the Amarisoft Callbox Mini. When monitoring the throughput of the nRF9160 on the callbox, we only appear to be getting a UL bitrate of about 50 kbps max and a DL bitrate of 2kbps, which seems to be very low.

I thus have the following few questions that we were hoping to be assisted with:

1) Is there any way to monitor the data throughput from the UE side, for example using AT commands etc.?

2) Are there any settings we can change on the modem in order to increase data throughput?

3) Since the eNB is in my home literally next to the UE, we are expecting data throughput to be at its maximum or at least very near it. Thus how exactly is the data througput managed by the eNB and UE? What can be causing the lower bitrates?

Thanks in advance!

Regards,

Frikkie 

Parents
  • Hi,

    First, it is worth noting that those numbers are peak throughput for the physical layers, so you will most likely not see those numbers from the application.

    You should also note that it will depend on the tested/eNB if those numbers can be acheived.

    That said, those numbers sounds very low. When I use the iperf command in the newly added modem shell sample, I got averages of ~ 120 kbps UL and ~ 100 kbps downlink on the local network.

    To increase the speed, you can try to increase the PRB and MSC.

    I've also attached a precompiled version of the modem shell if you want to try that. You can find the documentation here: modem shell.

    mosh.hex

    Best regards,

    Didrik

  • Hi Didrik,

    Thanks for the precompiled version - will test it as soon as possible. Will also confirm that the tested eNB can handle this values.

    In the meantime, could you please elaborate more on how to increase the PRB and MSC? Is this done on the UE side or eNB side?

  • It is done on the eNB side.

    However, I don't have much experience with callboxes myself, so I can't really help you more than that.

  • Thanks,

    We have support on the callbox and can thus investigate that further ourselves.

    However I am also trying to understand whether there any are settings on the nRF9160 application level that can influence the throughput? If not, I would expect that the mosh.hex modem shell which you sent will give the same throughput as the application that we currently have installed? In this case it also sounds like the throughput is determine only by the eNB?

  • I am not aware of any methods for improving the throughput on the LTE level.

    However, it is possible to improve the IP throughput by tweaking the size of the shared buffers between the application and modem cores: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/include/modem/nrf_modem_lib.html#partition-manager-integration

  • Thanks for the information, Didrik.

    We have been able to start testing on a local public network in the UK and were thus able to use the iperf command to test throughput (TCP).

    We use the following command for UL test (on a public iperf3 server):

    - iperf3 -c speedtest.serverius.net -p 5002 -l 705 -t 30

    We the obtain an UL bitrate of 319kbps:

    -[ ID] Interval Transfer Bitrate
    [ 5] 0.00-30.00 sec 1.14 MBytes 319 Kbits/sec sender
    [ 5] 0.00-30.00 sec 1.14 MBytes 319 Kbits/sec receiver

    Then for the DL test:

    - iperf3 -c speedtest.serverius.net -p 5002 -l 705 -t 30 -R

    We then obtain a DL bitrate of about 200kbps:

    [ ID] Interval Transfer Bitrate Retr
    [ 5] 0.00-30.00 sec 750 KBytes 205 Kbits/sec 0 sender
    [ 5] 0.00-30.00 sec 698 KBytes 191 Kbits/sec receiver

    Could you confirm that we are using the same commands as you for this TCP throughput test? The values we are seeing is somewhat larger than the values you are seeing, and I thus assume that the differences in our and your values are only caused by the different local networks and eNBs we are using (we should see the same UL/DL values when our UE is placed next to yours on the same network).

Reply
  • Thanks for the information, Didrik.

    We have been able to start testing on a local public network in the UK and were thus able to use the iperf command to test throughput (TCP).

    We use the following command for UL test (on a public iperf3 server):

    - iperf3 -c speedtest.serverius.net -p 5002 -l 705 -t 30

    We the obtain an UL bitrate of 319kbps:

    -[ ID] Interval Transfer Bitrate
    [ 5] 0.00-30.00 sec 1.14 MBytes 319 Kbits/sec sender
    [ 5] 0.00-30.00 sec 1.14 MBytes 319 Kbits/sec receiver

    Then for the DL test:

    - iperf3 -c speedtest.serverius.net -p 5002 -l 705 -t 30 -R

    We then obtain a DL bitrate of about 200kbps:

    [ ID] Interval Transfer Bitrate Retr
    [ 5] 0.00-30.00 sec 750 KBytes 205 Kbits/sec 0 sender
    [ 5] 0.00-30.00 sec 698 KBytes 191 Kbits/sec receiver

    Could you confirm that we are using the same commands as you for this TCP throughput test? The values we are seeing is somewhat larger than the values you are seeing, and I thus assume that the differences in our and your values are only caused by the different local networks and eNBs we are using (we should see the same UL/DL values when our UE is placed next to yours on the same network).

Children
  • I simply used the command from the documentation:

    iperf3 --client ping.online.net --port 5202 -l 3540 --time 30 -V -R

    Using a smaller buffer size (like you did), would probably increase the throughput as it reduces the need for fragmentation.

  • Thanks Didrik. I also just want to make sure we are interpreting this correctly. For your above command (downloading TCP payload), we get a result of: 

    Test Complete. Summary Results:
    [ ID] Interval Transfer Bitrate Retr
    [ 5] 0.00-30.01 sec 681 KBytes 186 Kbits/sec 0 sender
    [ 5] 0.00-30.01 sec 618 KBytes 169 Kbits/sec receiver

    What is the differences between the sender and receiver bitrates? Is sender the UL bitrate and receiver the DL bitrate? If so, why then if we remove the "-R" argument (upload TCP payload) from the command we get a much larger bitrate of about 300kbps?

    It does indeed look like increasing the payload decreases the throughput, thanks

  • This and this link gives a good explanation of the iperf output.

    Normally, the client is the one to send data. This means that normally, you only measure upload datarate. With the -R flag, you reverse the roles of the server and client, so that it is the server that sends data, and the client that receives it. So  without the -R flag, you get upload, while with the -R flag you get download. The sender and receiver datarates gives you the datarate meassured by the sender (client without -R, server with) and the receiver (server without -R, client with).

Related