Asymmetric UDP goodput in scenario 1009

[Novak Boskov]

We are measuring UDP goodput between two UEs on the same base station.

Suppose that the host name of the base station is `scope-0` and the two UEs are `scope-1` (172.16.0.4) and `scope-2` (172.16.0.3). We use SCOPE to set up srsRAN and the Colosseum scenario.

On `scope-1`:
$ iperf3 -s

On `scope-2`:
$ iperf3 -c 172.16.0.4 -u -b 0
Connecting to host 172.16.0.4, port 5201
[  5] local 172.16.0.3 port 40740 connected to 172.16.0.4 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   710 MBytes  5.95 Gbits/sec  513910
[  5]   1.00-2.00   sec   712 MBytes  5.97 Gbits/sec  515360
[  5]   2.00-3.00   sec   712 MBytes  5.97 Gbits/sec  515500
[  5]   3.00-4.00   sec   712 MBytes  5.97 Gbits/sec  515420
[  5]   4.00-5.00   sec   711 MBytes  5.97 Gbits/sec  515080
[  5]   5.00-6.00   sec   711 MBytes  5.97 Gbits/sec  515120
[  5]   6.00-7.00   sec   710 MBytes  5.96 Gbits/sec  514490
[  5]   7.00-8.00   sec   710 MBytes  5.96 Gbits/sec  514410
[  5]   8.00-9.00   sec   711 MBytes  5.97 Gbits/sec  514970
[  5]   9.00-10.00  sec   711 MBytes  5.96 Gbits/sec  514930
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  6.94 GBytes  5.96 Gbits/sec  0.000 ms  0/5149190 (0%)  sender
[  5]   0.00-10.42  sec  5.04 MBytes  4.06 Mbits/sec  4.317 ms  5144256/5147906 (1e+02%)  receiver

That is, goodput from `scope-2` to `scope-1` is about 4.06 Mbits/sec.

Then again on `scope-2`, but now iperf3 in reverse mode:
$ iperf3 -c 172.16.0.4 -u -b 0 -R
Reverse mode, remote host 172.16.0.4 is sending
[  5] local 172.16.0.3 port 38529 connected to 172.16.0.4 port 5201
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   402 KBytes  3.29 Mbits/sec  2.378 ms  306571/306855 (1e+02%)
[  5]   1.00-2.00   sec   386 KBytes  3.16 Mbits/sec  7.548 ms  500689/500962 (1e+02%)
[  5]   2.00-3.00   sec   414 KBytes  3.39 Mbits/sec  3.574 ms  446919/447212 (1e+02%)
[  5]   3.00-4.00   sec   392 KBytes  3.21 Mbits/sec  4.316 ms  486877/487154 (1e+02%)
[  5]   4.00-5.00   sec   407 KBytes  3.34 Mbits/sec  2.193 ms  464333/464621 (1e+02%)
[  5]   5.00-6.00   sec   400 KBytes  3.28 Mbits/sec  9.571 ms  524842/525125 (1e+02%)
[  5]   6.00-7.00   sec   417 KBytes  3.42 Mbits/sec  2.294 ms  451555/451850 (1e+02%)
[  5]   7.00-8.00   sec   406 KBytes  3.32 Mbits/sec  3.533 ms  515781/516068 (1e+02%)
[  5]   8.00-9.00   sec   397 KBytes  3.26 Mbits/sec  3.639 ms  445331/445612 (1e+02%)
[  5]   9.00-10.00  sec   390 KBytes  3.20 Mbits/sec  2.335 ms  473347/473623 (1e+02%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.08  sec  6.54 GBytes  5.58 Gbits/sec  0.000 ms  0/4852450 (0%)  sender
[  5]   0.00-10.00  sec  3.92 MBytes  3.29 Mbits/sec  2.335 ms  4616245/4619082 (1e+02%)  receiver

Which gives us about 3.29 Mbits/sec (< 4.06 Mbits/sec) of goodput in the other direction.

Since the discrepancy is not negligible, I was wondering where it comes from?
Is it implicitly controlled by a SCOPE or srsRAN parameter?

Best regards,
--
    Novak Boškov
    PhD Candidate
    Electrical & Computer Engineering Department
    Boston University

[Leonardo Bonati]

Hi Novak,

This is due to the fact that you are transmitting with UDP over a real system with real radios (possibly saturating the available bandwidth, hence the packet losses).

Regards,

Leonardo

--
You received this message because you are subscribed to the Google Groups "Colosseum Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to colosseum-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/colosseum-users/390cf290-1598-4351-9c42-7f351ce89bf4n%40googlegroups.com.

[Novak Boškov]

Hi Leonardo,

Yes, packet losses come from `-b 0` that I use (burst mode). But, I use the same option in both directions (`scope-1` to `scope-2`, and `scope-2` to `scope-1`).

The question is why is effective throughput much smaller in one direction? Or the other way around, why would packet loss be higher in one direction than the other?

Best regards,
--
    Novak Boškov
    PhD Candidate
    Electrical & Computer Engineering Department
    Boston University

[theca...@gmail.com]

Hi Novak,

Andrea Lacava here, from the Colosseum team.
In general, it is normal on Colosseum that rates might not be symmetric due to different radios being used in the emulation. Also, the specific scenario being used can largely affect the performance experienced by each node. Can you confirm that you are using the 0 dB path loss scenario? If yes, the difference is likely due to the different radios. If not, the difference is likely due to the nodes being in different locations and experiencing different channel conditions. Also, if you are using SCOPE, it can be beneficial to look at MCS, RSSI-related, and throughout metrics to understand if the mismatch comes from different MCS being used. Note that the scheduling performed by the base stations might be different for different users, so I would look at those first to understand where (and why) the difference is coming from.

Hope this helps!

Best regards,

[Novak Boškov]

Hi Andrea, thanks for answering!

Yes, the scenario is 1009 (0 db path-loss per docs). The nodes should be experiencing the same channel conditions. I don't see anything in the scenario description that may indicate otherwise. Correct me if I'm wrong.
Also, the discrepancy between UDP goodputs in the two direction repeated even in several reservations that allocate different nodes. It's not only one reservation.

Yes, we use SCOPE. But keep it very simple (no network slicing, for example). Here is our config file:

{
  "capture-pkts": "False",
  "colosseumcli": "True",
  "iperf": "False",
  "users-bs": "3",
  "write-config-parameters": "True",
  "network-slicing": "False",
  "global-scheduling-policy": "0",
  "slice-scheduling-policy": "[1, 1, 1]",
  "tenant-number": "3",
  "slice-allocation": "{0: [0, 5], 1: [6, 11], 2: [12, 16]}",
  "slice-users": "{0: [3, 6, 9, 14, 17, 20, 25, 28, 31, 36, 39, 42], 1: [4, 7, 10, 15, 18, 21, 26, 29, 32, 37, 40, 43], 2: [2, 5, 8, 11, 13, 16, 19, 22, 24, 27, 30, 33, 35, 38, 41, 44]}",
  "custom-ue-slice": "True",
  "force-dl-modulation": "False",
  "heuristic-params": "{'buffer_thresh_bytes': [1000, 2000], 'thr_thresh_mbps': [0.25, 0.75]}",
  "bs-config": "{'dl_freq': 980000000, 'ul_freq': 1020000000, 'n_prb': 50}",
  "ue-config": "{'dl_freq': 980000000, 'ul_freq': 1020000000, 'force_ul_amplitude': 0.9}"
}

How do we obtain "MCS and RSSI-related metrics"?
The only "mcs" related settings that I've managed to find is `pusch_max_mcs = 16` in `/root/radio_code/srsLTE/config_files/general_config/enb.conf` and it is the same in all SRNs in our reservation.

Best regards,
--
    Novak Boškov
    PhD Candidate
    Electrical & Computer Engineering Department
    Boston University

To view this discussion on the web visit https://groups.google.com/d/msgid/colosseum-users/d4c0b711-e5e7-4184-a7fe-1b39d2ab6fefn%40googlegroups.com.

[Novak Boskov]

Quick update.

We looked at `srsue` traces in scenario  #1009. According to these traces, we typically see around 54 dB path-loss (and `rsrp` of -54 dBm). Should we expect ~0 dB path-loss in 1009?
https://colosseumneu.freshdesk.com/support/solutions/articles/61000277641-test-scenario-all-paths-0-db-1009-

[Davide Villa]

Hi Novak,

Colosseum has some internal noises given by all its components that usually create a constant pathloss of around 55 dB even in perfect channel conditions, i.e. with a scenario of 0 dB pathloss as the 1009 that you are running.

Therefore, the value that you have found should be actually correct and means that the system is working fine.

Thanks.

Best Regards,

Davide

[Novak Boskov]

Got it! Thanks, Davide.