From a2eba1e25a56f70dbd12f0298288c570a3c70ea9 Mon Sep 17 00:00:00 2001 From: Ondrej Kosta Date: Tue, 10 Dec 2024 11:39:28 +0100 Subject: [PATCH] ci(esp_eth): added ESP32P4 to iperf CI test Updated (increased) ETH_THROUGHPUT_SPI_ETH limits. Improved iperf optimization description --- components/idf_test/include/idf_performance.h | 8 +-- examples/ethernet/.build-test-rules.yml | 2 +- examples/ethernet/iperf/pytest_eth_iperf.py | 39 +++++++++------ .../iperf/sdkconfig.ci.default_dm9051 | 10 ++-- .../iperf/sdkconfig.ci.default_dp83848 | 10 ++-- .../ethernet/iperf/sdkconfig.ci.default_ip101 | 10 ++-- .../iperf/sdkconfig.ci.default_ip101_esp32p4 | 49 +++++++++++++++++++ .../iperf/sdkconfig.ci.default_ksz8041 | 10 ++-- .../iperf/sdkconfig.ci.default_ksz8851snl | 10 ++-- .../iperf/sdkconfig.ci.default_lan8720 | 10 ++-- .../iperf/sdkconfig.ci.default_rtl8201 | 10 ++-- .../ethernet/iperf/sdkconfig.ci.default_w5500 | 10 ++-- examples/ethernet/iperf/sdkconfig.defaults | 10 ++-- .../idf_iperf_test_util/IperfUtility.py | 33 ++++++++----- 14 files changed, 164 insertions(+), 57 deletions(-) create mode 100644 examples/ethernet/iperf/sdkconfig.ci.default_ip101_esp32p4 diff --git a/components/idf_test/include/idf_performance.h b/components/idf_test/include/idf_performance.h index 84e1d897df..906fa030a2 100644 --- a/components/idf_test/include/idf_performance.h +++ b/components/idf_test/include/idf_performance.h @@ -69,16 +69,16 @@ #endif #ifndef IDF_PERFORMANCE_MIN_TCP_RX_ETH_THROUGHPUT_SPI_ETH -#define IDF_PERFORMANCE_MIN_TCP_RX_ETH_THROUGHPUT_SPI_ETH 2 +#define IDF_PERFORMANCE_MIN_TCP_RX_ETH_THROUGHPUT_SPI_ETH 6 #endif #ifndef IDF_PERFORMANCE_MIN_TCP_TX_ETH_THROUGHPUT_SPI_ETH -#define IDF_PERFORMANCE_MIN_TCP_TX_ETH_THROUGHPUT_SPI_ETH 3 +#define IDF_PERFORMANCE_MIN_TCP_TX_ETH_THROUGHPUT_SPI_ETH 8 #endif #ifndef IDF_PERFORMANCE_MIN_UDP_RX_ETH_THROUGHPUT_SPI_ETH -#define IDF_PERFORMANCE_MIN_UDP_RX_ETH_THROUGHPUT_SPI_ETH 5 +#define IDF_PERFORMANCE_MIN_UDP_RX_ETH_THROUGHPUT_SPI_ETH 8 #endif #ifndef IDF_PERFORMANCE_MIN_UDP_TX_ETH_THROUGHPUT_SPI_ETH -#define IDF_PERFORMANCE_MIN_UDP_TX_ETH_THROUGHPUT_SPI_ETH 7 +#define IDF_PERFORMANCE_MIN_UDP_TX_ETH_THROUGHPUT_SPI_ETH 10 #endif diff --git a/examples/ethernet/.build-test-rules.yml b/examples/ethernet/.build-test-rules.yml index 965eb6b820..a22daf4841 100644 --- a/examples/ethernet/.build-test-rules.yml +++ b/examples/ethernet/.build-test-rules.yml @@ -17,7 +17,7 @@ examples/ethernet/basic: examples/ethernet/iperf: disable_test: - - if: IDF_TARGET not in ["esp32"] + - if: IDF_TARGET not in ["esp32", "esp32p4"] temporary: true reason: lack of runners depends_components: diff --git a/examples/ethernet/iperf/pytest_eth_iperf.py b/examples/ethernet/iperf/pytest_eth_iperf.py index b6977a0357..ad80a84ef0 100644 --- a/examples/ethernet/iperf/pytest_eth_iperf.py +++ b/examples/ethernet/iperf/pytest_eth_iperf.py @@ -53,6 +53,8 @@ def test_esp_eth_iperf( dut: Dut, log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], + udp_tx_bw_lim: Optional[int] = NO_BANDWIDTH_LIMIT, + udp_rx_bw_lim: Optional[int] = NO_BANDWIDTH_LIMIT, spi_eth: Optional[bool] = False ) -> None: """ @@ -79,12 +81,8 @@ def test_esp_eth_iperf( # 3. run test for TCP Tx, Rx and UDP Tx, Rx test_utility.run_test('tcp', 'tx', 0, NO_BANDWIDTH_LIMIT) test_utility.run_test('tcp', 'rx', 0, NO_BANDWIDTH_LIMIT) - test_utility.run_test('udp', 'tx', 0, 80) - # Limit speed to 10Mbps for SPI Ethernet PHYs - if spi_eth: - test_utility.run_test('udp', 'rx', 0, 10) - else: - test_utility.run_test('udp', 'rx', 0, NO_BANDWIDTH_LIMIT) + test_utility.run_test('udp', 'tx', 0, udp_tx_bw_lim) + test_utility.run_test('udp', 'rx', 0, udp_rx_bw_lim) # 4. log performance and compare with pass standard for throughput_type in test_result: @@ -113,7 +111,20 @@ def test_esp_eth_iperf_ip101( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance) + test_esp_eth_iperf(dut, log_performance, check_performance, udp_tx_bw_lim=90) + + +@pytest.mark.esp32p4 +@pytest.mark.eth_ip101 +@pytest.mark.parametrize('config', [ + 'default_ip101_esp32p4', +], indirect=True) +def test_esp_eth_iperf_ip101_esp32p4( + dut: Dut, + log_performance: Callable[[str, object], None], + check_performance: Callable[[str, float, str], None], +) -> None: + test_esp_eth_iperf(dut, log_performance, check_performance, udp_tx_bw_lim=96) @pytest.mark.esp32 @@ -126,7 +137,7 @@ def test_esp_eth_iperf_lan8720( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance) + test_esp_eth_iperf(dut, log_performance, check_performance, udp_tx_bw_lim=90) @pytest.mark.esp32 @@ -139,7 +150,7 @@ def test_esp_eth_iperf_rtl8201( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance) + test_esp_eth_iperf(dut, log_performance, check_performance, udp_tx_bw_lim=90) @pytest.mark.esp32 @@ -152,7 +163,7 @@ def test_esp_eth_iperf_dp83848( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance) + test_esp_eth_iperf(dut, log_performance, check_performance, udp_tx_bw_lim=90) @pytest.mark.esp32 @@ -165,7 +176,7 @@ def test_esp_eth_iperf_ksz8041( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance) + test_esp_eth_iperf(dut, log_performance, check_performance, udp_tx_bw_lim=90) @pytest.mark.esp32 @@ -178,7 +189,7 @@ def test_esp_eth_iperf_dm9051( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance, spi_eth=True) + test_esp_eth_iperf(dut, log_performance, check_performance, spi_eth=True, udp_rx_bw_lim=10) @pytest.mark.esp32 @@ -191,7 +202,7 @@ def test_esp_eth_iperf_w5500( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance, spi_eth=True) + test_esp_eth_iperf(dut, log_performance, check_performance, spi_eth=True, udp_rx_bw_lim=10) @pytest.mark.esp32 @@ -204,4 +215,4 @@ def test_esp_eth_iperf_ksz8851snl( log_performance: Callable[[str, object], None], check_performance: Callable[[str, float, str], None], ) -> None: - test_esp_eth_iperf(dut, log_performance, check_performance, spi_eth=True) + test_esp_eth_iperf(dut, log_performance, check_performance, spi_eth=True, udp_rx_bw_lim=10) diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_dm9051 b/examples/ethernet/iperf/sdkconfig.ci.default_dm9051 index 9ab9acaecc..24446492c6 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_dm9051 +++ b/examples/ethernet/iperf/sdkconfig.ci.default_dm9051 @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_dp83848 b/examples/ethernet/iperf/sdkconfig.ci.default_dp83848 index f02a7365bd..fe5b27e8b7 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_dp83848 +++ b/examples/ethernet/iperf/sdkconfig.ci.default_dp83848 @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_ip101 b/examples/ethernet/iperf/sdkconfig.ci.default_ip101 index 82f756e542..5029460f85 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_ip101 +++ b/examples/ethernet/iperf/sdkconfig.ci.default_ip101 @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_ip101_esp32p4 b/examples/ethernet/iperf/sdkconfig.ci.default_ip101_esp32p4 new file mode 100644 index 0000000000..60f3c790ad --- /dev/null +++ b/examples/ethernet/iperf/sdkconfig.ci.default_ip101_esp32p4 @@ -0,0 +1,49 @@ +CONFIG_IDF_TARGET="esp32p4" + +# Increase main task stack size +CONFIG_ESP_MAIN_TASK_STACK_SIZE=7168 + +# Enable filesystem for console commands history storage +CONFIG_ESPTOOLPY_FLASHSIZE_4MB=y +CONFIG_PARTITION_TABLE_CUSTOM=y +CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions_example.csv" +CONFIG_PARTITION_TABLE_FILENAME="partitions_example.csv" + +# Enable FreeRTOS stats formatting functions, needed for 'tasks' command +CONFIG_FREERTOS_USE_TRACE_FACILITY=y +CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y + +# -------------------------------- +# Performance optimization options +# -------------------------------- +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. + +# Run FreeRTOS only on the first core +CONFIG_FREERTOS_UNICORE=y + +# Disable watch dog +CONFIG_ESP_INT_WDT=n +CONFIG_ESP_TASK_WDT_EN=n + +# Enable lwIP IRAM optimization +CONFIG_LWIP_IRAM_OPTIMIZATION=y + +# Enable Ethernet IRAM optimization +CONFIG_ETH_IRAM_OPTIMIZATION=y + +CONFIG_EXAMPLE_USE_INTERNAL_ETHERNET=y +CONFIG_EXAMPLE_ETH_PHY_IP101=y +CONFIG_EXAMPLE_ETH_MDC_GPIO=31 +CONFIG_EXAMPLE_ETH_MDIO_GPIO=52 +CONFIG_EXAMPLE_ETH_PHY_RST_GPIO=51 +CONFIG_EXAMPLE_ETH_PHY_ADDR=1 + +CONFIG_ETH_ENABLED=y +CONFIG_ETH_USE_ESP32_EMAC=y +CONFIG_ETH_PHY_INTERFACE_RMII=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_ksz8041 b/examples/ethernet/iperf/sdkconfig.ci.default_ksz8041 index bbb4b51c05..bc104068f5 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_ksz8041 +++ b/examples/ethernet/iperf/sdkconfig.ci.default_ksz8041 @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_ksz8851snl b/examples/ethernet/iperf/sdkconfig.ci.default_ksz8851snl index 819e36a9d2..e821789d8a 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_ksz8851snl +++ b/examples/ethernet/iperf/sdkconfig.ci.default_ksz8851snl @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_lan8720 b/examples/ethernet/iperf/sdkconfig.ci.default_lan8720 index 038777d84f..9f97cf4e22 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_lan8720 +++ b/examples/ethernet/iperf/sdkconfig.ci.default_lan8720 @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_rtl8201 b/examples/ethernet/iperf/sdkconfig.ci.default_rtl8201 index 229ffbb78a..3e2359aaf7 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_rtl8201 +++ b/examples/ethernet/iperf/sdkconfig.ci.default_rtl8201 @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.ci.default_w5500 b/examples/ethernet/iperf/sdkconfig.ci.default_w5500 index a2ec710628..ab71d29bf1 100644 --- a/examples/ethernet/iperf/sdkconfig.ci.default_w5500 +++ b/examples/ethernet/iperf/sdkconfig.ci.default_w5500 @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/examples/ethernet/iperf/sdkconfig.defaults b/examples/ethernet/iperf/sdkconfig.defaults index c6ad4c051e..057bd579cc 100644 --- a/examples/ethernet/iperf/sdkconfig.defaults +++ b/examples/ethernet/iperf/sdkconfig.defaults @@ -14,9 +14,13 @@ CONFIG_FREERTOS_USE_STATS_FORMATTING_FUNCTIONS=y # -------------------------------- # Performance optimization options # -------------------------------- -# `lwIP` and `iperf` tasks have serial dependency to each other (i.e. `iperf` must wait for `lwIP` -# to process the packets). Therefore, you don't gain much performance improvement when running -# multi core mode. On the other hand, IRAM optimizations have greater effect for single core mode. +# The lwIP and iperf tasks have a serial dependency (i.e., iperf must wait for lwIP to process packets), +# meaning that running in multi-core mode does not significantly improve performance. Additionally, +# IRAM optimizations have a more noticeable effect in single-core mode. +# However, while a single-core configuration can enhance iperf performance in controlled or isolated +# testing scenarios, it may not be optimal for real-world applications where the system also needs to +# handle additional, non-network-related tasks. In such cases, multi-core configurations might be better +# suited for balancing workloads and ensuring overall system responsiveness. # Run FreeRTOS only on the first core CONFIG_FREERTOS_UNICORE=y diff --git a/tools/ci/python_packages/idf_iperf_test_util/IperfUtility.py b/tools/ci/python_packages/idf_iperf_test_util/IperfUtility.py index 97b4bae3d7..ff248219e5 100644 --- a/tools/ci/python_packages/idf_iperf_test_util/IperfUtility.py +++ b/tools/ci/python_packages/idf_iperf_test_util/IperfUtility.py @@ -1,4 +1,4 @@ -# SPDX-FileCopyrightText: 2022-2024 Espressif Systems (Shanghai) CO LTD +# SPDX-FileCopyrightText: 2022-2025 Espressif Systems (Shanghai) CO LTD # SPDX-License-Identifier: Apache-2.0 import logging import os @@ -355,14 +355,14 @@ class IperfTestUtility(object): else: process.terminate() else: - self.dut.write('iperf -s -u -i 1 -t {}'.format(TEST_TIME)) - # wait until DUT TCP server created - try: - self.dut.expect('Socket bound', timeout=5) - except pexpect.TIMEOUT: - # compatible with old iperf example binary - logging.info('create iperf udp server fail') if bw_limit > 0: + self.dut.write('iperf -s -u -i 1 -t {}'.format(TEST_TIME)) + # wait until DUT TCP server created + try: + self.dut.expect('Socket bound', timeout=5) + except pexpect.TIMEOUT: + # compatible with old iperf example binary + logging.info('create iperf udp server fail') process = subprocess.Popen(['iperf', '-c', dut_ip, '-u', '-b', str(bw_limit) + 'm', '-t', str(TEST_TIME), '-f', 'm'], stdout=f, stderr=f) for _ in range(TEST_TIMEOUT): @@ -372,9 +372,20 @@ class IperfTestUtility(object): else: process.terminate() else: - for bandwidth in range(50, 101, 5): + start_bw = 50 + stop_bw = 100 + n = 10 + step = int((stop_bw - start_bw) / n) + self.dut.write('iperf -s -u -i 1 -t {}'.format(TEST_TIME + 4 * (n + 1))) # 4 sec for each bw step instance start/stop + # wait until DUT TCP server created + try: + self.dut.expect('Socket bound', timeout=5) + except pexpect.TIMEOUT: + # compatible with old iperf example binary + logging.info('create iperf udp server fail') + for bandwidth in range(start_bw, stop_bw, step): process = subprocess.Popen(['iperf', '-c', dut_ip, '-u', '-b', str(bandwidth) + 'm', - '-t', str(TEST_TIME / 11), '-f', 'm'], stdout=f, stderr=f) + '-t', str(TEST_TIME / (n + 1)), '-f', 'm'], stdout=f, stderr=f) for _ in range(TEST_TIMEOUT): if process.poll() is not None: break @@ -382,7 +393,7 @@ class IperfTestUtility(object): else: process.terminate() - server_raw_data = self.dut.expect(pexpect.TIMEOUT, timeout=0).decode('utf-8') + server_raw_data = self.dut.expect(pexpect.TIMEOUT, timeout=5).decode('utf-8') with open(PC_IPERF_TEMP_LOG_FILE, 'r') as f: pc_raw_data = f.read()