tencent cloud

FAQ

Download
フォーカスモード
フォントサイズ
最終更新日: 2026-05-21 16:24:52
This document is for customer guidance on locating and troubleshooting problems when using Multiple Network Acceleration product.

1. Common Reasons for Business Performance Issues and Troubleshooting Methods

This section mainly introduces common causes and troubleshooting methods when business effects are not meeting expectations while users are using aggregation and real-time acceleration.
Business impact does not meet expectations. For example: video stuttering, screen glitch, or frame loss during push/pull streaming.

1.1 Common Reasons

1.1.1 Inappropriate Acceleration Mode Selection

The acceleration mode is configured inappropriately, for example, real-time mode should be used instead of aggregation mode. Choose an appropriate acceleration mode based on business type and performance requirement. For specific configuration, consult Tencent Operation and Maintenance Personnel.
For the acceleration mode query method, see Checking Acceleration Mode and Access Gateway IP address.

1.1.2 Inappropriate Business Parameter Setting

Business-related parameters: Inappropriate business-related settings, commonly used:
Excessively large MSS leads to reduced performance in UDP packet transfer.
Setting the live streaming push tolerance delay lower than the link's working RTT causes the link to not participate in aggregation or to drop packets.
Algorithm-related parameters of Multiple Network Acceleration. The default configuration can generally meet the requirements. For special requirements, consult Tencent Operation and Maintenance Personnel.

1.1.3 Poor Network Environment

Business runs normally in most scenarios and most time, but fails to meet expectations at specific physical locations or during peak hours, which might be due to poor current network environment unable to meet business needs.
In case of poor network quality in part or all links (such as excessively high latency, large latency jitter, or high packet loss rate), the issues may exist.
Aggregation mode
The aggregated bandwidth of each link is less than the business bandwidth requirement. The current network environment does not meet business needs. Physical links need to be replaced or added.
Some links are disabled. The aggregated bandwidth of the remaining links is less than the business bandwidth requirement. The current network environment does not meet business needs. Links need to be changed or physical links added.
The aggregated link bandwidth meets the business bandwidth requirement, but occasional lags, packet loss, or out-of-order packets might occur. This could be due to a sudden decrease in current network quality (jitter, packet loss, latency).
Real-time mode
The bandwidth of the selected transmission link is still less than the business requirement. The current network environment does not meet business needs. The terminal location needs to be changed or the physical link replaced.
The delay of the selected transmission link is too large, or the jitter is high, which does not meet business needs. The current network environment does not meet business needs. The terminal location needs to be changed or the physical link replaced.
Link switching is frequent, and the delay jitter does not meet business needs. The current network environment does not meet business needs. The terminal location needs to be changed or the physical link replaced.
Note:
To troubleshoot and confirm the existence of poor network environment, use one or more of the following methods for troubleshooting and confirmation.

1.2 Troubleshooting Method

1.2.1 Checking Acceleration Mode and Access Gateway IP address

curl -s -X 'GET' 'http://127.0.0.1:9801/api/v2/client/mp-speeder' -H 'accept: */*' -H 'Content-Type: application/json'
scheduleMode (acceleration mode)
bonding: aggregation
fastSwitching: real-time
redundant: dual-transmit
accGateway (access gateway IP)

1.2.2 Traffic Monitoring

Log in to the Tencent Cloud console to view the real-time network status of the specified device, including uplink traffic, downstream traffic, uplink rate, downstream rate, packet loss, and latency.
Check the rate of each link for any abnormal phenomenon such as a severe rate drop or a fall to zero.
Check the latency and packet loss rate of each link to determine whether there is a latency surge or significant jitter (for example: latency increases from 80ms to 300ms) or a packet loss rate surge (for example: packet loss rate rises from nearly zero to over 10%).
Note:
You can further verify this by analyzing the 1.2.3 SDK Log Analysis.

1.2.3 SDK Log Analysis

SDK log local file storage path: /var/log/mp-sdk.log and /var/log/mp-speeder.log.
Common analysis metrics for logs and fault judgment methods follow these steps:
Registration failed, search keywords: "sdk register failed". The issue is caused by datakey invalidation.
Trigger link disabled, search keywords: "potentiallyFailed".
Restore link after disabling, search keywords: "potentiallyOK".
datakey reuse by device causes accelerated connection interruption. Search keywords: "close session by controller".
Activate path, search keywords: "Enable PathID".
Close path, search keywords: "Close PathID".

1.2.4 udpping Speed Test

The udpping tool is an acceleration gateway service. It works by sending probe packets to designated probe points through specified network ports at assigned frequency, collecting link delay changes. It can be used to compare the delay between physical links and accelerated links.
/usr/local/bin/mp-speeder/udping -h
Usage of /usr/local/bin/mp-speeder/udping:
-C int
ping count
-I string
bind interface name
-c string
probe address, IP:PORT
-i duration
ping interval (default 1s)
-l int
payload length
-logLevel string
log level, default info
-o output to shell
-v show version
-w duration
ping timeout (default 1s)
Parameter setting suggestion:
-c string
probe address, IP:PORT
Note:
The IP address can be obtained from the "Acceleration Mode and Access Gateway IP Query" section, and the PORT is 8888.
UDP traffic generation usage example:
Assess the RTT delay from the designated network card (such as eth0) to the specified probe point (for example: access gateway IP 49.7.248.202). The command meaning: specify to collect the delay of eth0 network interface card accessing gateway 49.7.248.202, detection message length 200 bytes, one probe every 0.1s, total 100 probes.
Reference command: /usr/local/bin/mp-speeder/udping -C 100 -I eth0 -c 49.7.248.202:8888 -i 0.1s -l 200
Assess the RTT delay of the accelerated link. The following command: collects the delay of the accelerated link when the SDK accesses the gateway at 49.7.248.202, using a probe packet length of 200 bytes, one probe every 0.1 seconds, for a total of 100 probes.
Reference command: /usr/local/bin/mp-speeder/udping -C 100 -I mp_tun0 -c 49.7.248.202:8888 -i 0.1s -l 200

1.2.5 UDP Traffic Testing

UDP traffic generation uses the iperf3 service, a commonly used network speed test. UDP traffic generation can serve as an auxiliary tool to monitor link bandwidth and packet loss rate changes. Self-deployment of the iperf3 client and services is required.
UDP traffic generation usage example:
Assess the UDP transmission bandwidth from the specified network interface (eth0) to the IP address (x.x.x.x). The IP address x.x.x.x hosts the Iperf3 service, and the service port is 5201.
Reference command: iperf3 -c x.x.x.x -p 5201 -u -b 100M -B eth0
Assess the UDP bandwidth of the accelerated link. Among them, x.x.x.x is the IP provided by the Iperf3 service, and the server port is 5201.
Reference command: iperf3 -c x.x.x.x -p 5201 -u -b 100M -B 192.18.0.1

1.2.6 Network Measurement Callback Listener API

The network measurement callback listener API can obtain RTT, rate, and packet loss metrics for each in-band link. The measurement results synchronize with the business. User-saved API callback results are required.
Query the traffic statistics API.
curl -X 'GET' 'http://127.0.0.1:9801/api/v2/client/flowStatistics' -H 'accept: application/json' -H 'all: true'

2. Troubleshooting Methods for Common Issues with Linux SDK

2.1 Unable to Start Acceleration or Traffic Not Connected after Acceleration

2.1.1 Execute One-Click Detection Script

When encountering acceleration that cannot start or traffic not connected after acceleration, run the one-click detection script and make corrections based on the detection result. Until ALL check results normal.
The Linux one-click detection script supports the following detection capabilities:
Detect acceleration status (key process, policy-based routing, traffic diversion rule).
Detect rp_filter configuration.
Detect L3 feature configuration.
The detection script of V0.16.1 and later versions has been placed in this directory: /usr/local/bin/mp-speeder/mp_check.sh (if there is no mp_check.sh in this directory, copy the following files to this directory).
Code explanation Code rewrite #!/bin/bash
# Set color output
YELLOW='\\033[0;33m'
GREEN='\\033[0;32m'
RED='\\033[0;31m'
NC='\\033[0m' # No Color
# Global variable used to store the list of ENIs
interfaces=""
# Function: Check whether the process is running
check_process() {
local process_name=$1
if pgrep -f "$process_name" > /dev/null; then
echo -e "${GREEN}[✓] Process $process_name is running${NC}"
return 0
else
echo -e "${RED}[✗] Process $process_name is not running${NC}"
return 1
fi
}
# Function: Check network interface card existence and start up
check_interface() {
local interface=$1
if ip link show "$interface" &> /dev/null; then
if ip link show "$interface" | grep -q "UP"; then
echo -e "${GREEN}[✓] Network interface card $interface is started and status is normal${NC}"
return 0
else
echo -e "${RED}[✗] Network interface card $interface exists but not started${NC}"
return 1
fi
else
echo -e "${RED}[✗] Network interface card $interface does not exist${NC}"
return 1
fi
}
# Function: Check rp_filter
check_rp_filter() {
if sysctl net.ipv4.conf.mp_tun0.rp_filter | grep -q "net.ipv4.conf.mp_tun0.rp_filter = 1"; then
echo -e "${RED}[✗] rp_filter is not disabled${NC}"
return 0
else
echo -e "${GREEN}[✓] rp_filter is closed${NC}"
return 1
fi
}
# Function: Check policy-based routing
check_policy_routing() {
# Check policy rule existence
if ip rule | grep -q "from 198.18.0.1 lookup"; then
local table_num=$(ip rule | grep "from 198.18.0.1 lookup " | awk '{print $NF}')
echo -e "${GREEN}[✓] Find policy rule: from 198.18.0.1 lookup $table_num${NC}"
# Check default route in routing table
if ip route show table "$table_num" | grep -q "default dev mp_tun0"; then
echo -e "${GREEN}[✓] Correct default route exists in route table $table_num${NC}"
else
echo -e "${RED}[✗] Correct default route not found in route table $table_num${NC}"
return 1
fi
else
echo -e "${RED}[✗] Policy rule not found: from 198.18.0.1${NC}"
return 1
fi
# Check policy rule existence based on source ip
for iface in $interfaces; do
# Get the IP address of the network interface card
local ip_addr=$(ip addr show $iface | awk '/inet / {print $2}' | cut -d/ -f1|head -n 1)
if [ -z "$ip_addr" ]; then
echo -e "${YELLOW}[-] Network interface card $iface has no IP address configuration and cannot be used to speed up. Suggest checking${NC}"
continue
fi
# Check policy rule existence
if ip rule | grep -q "from $ip_addr lookup"; then
local table_num=$(ip rule | grep "from $ip_addr lookup" | awk '{print $NF}')
echo -e "${GREEN}[✓] Find policy rule for network interface card $iface ($ip_addr): lookup $table_num${NC}"
# Check whether there is a route in routing table
if ip route show table "$table_num" | grep -q "dev $iface"; then
echo -e "${GREEN}[✓] Route table $table_num configured correctly${NC}"
else
echo -e "${RED}[✗] Route not found in route table $table_num${NC}"
return 1
fi
else
echo -e "${YELLOW}[-] Policy rule for network interface card $iface ($ip_addr) not found, may affect acceleration performance, enable policy-based routing management in SDK${NC}"
fi
done
return 0
}
# Function: check speeder status
check_speeder_status() {
local response
response=$(curl -s -X 'GET' 'http://127.0.0.1:9801/api/v2/client/mp-speeder' -H 'accept: */*' -H 'Content-Type: application/json')
if echo "$response" | grep -q '"ready":true'; then
echo -e "${GREEN}[✓] speeder is running and acceleration status is normal${NC}"
# Extract list of ENIs
interfaces=$(echo "$response" | sed -n 's/.*"interfaces":\\[\\([^]]*\\)\\].*/\\1/p' | sed 's/"//g' | sed 's/:[0-9]*//g' | tr ',' ' ')
echo -e "${GREEN}[✓] List of ENIs: $interfaces${NC}"
return 0
else
echo -e "${RED}[✗] speeder is not running or acceleration status is abnormal${NC}"
return 1
fi
}
# Function: Check traffic diversion rule
check_iptables_rules() {
echo "Start checking traffic diversion rule..."
# Check traffic diversion rule
if iptables -L mp_route_mark -nv -t mangle | grep -q "0x1/0xf"; then
echo -e "${GREEN}[✓] Traffic diversion rule check passed${NC}"
else
echo -e "${YELLOW}[-] No traffic diversion rule detected, please confirm whether it meets expectations${NC}"
fi
return 0
}
# Function: Check L3 feature
check_l3_functionality() {
echo "Start checking L3 feature..."
# Check wireguard virtual port status
# /usr/local/bin/mp-speeder/wg show
# interface: 09yg7kk9di
# public key: ISh0Y01aQ3dig5gyuivFnQe8lxi8Sdp3epNReVIYVSI=
# private key: (hidden)
# listening port: 55368
# peer: RzZ9m8lgMVeFzILbkfLmlM9I3ZBuGoP4hrfe78Vjzg0=
# endpoint: 198.18.0.5:10001
# allowed ips: 192.168.18.0/28
# latest handshake: 1 minute ago
# transfer: 3.66 MiB received, 17.26 MiB sent
# persistent keepalive: every 15 seconds
local response
response=$(/usr/local/bin/mp-speeder/wg show)
if echo "$response" | grep -q "latest handshake"; then
echo -e "${GREEN}[✓] wireguard virtual port status is normal${NC}"
else
echo -e "${RED}[✗] wireguard virtual port status exception${NC}"
return 1
fi
# Check the route table
local interface_name=$(echo "$response" | grep "interface:" | awk '{print $2}')
local allowed_ips=$(echo "$response" | grep "allowed ips:" | awk '{print $3}')
if [ -z "$interface_name" ] || [ -z "$allowed_ips" ]; then
echo -e "${RED}[✗] unable to get interface name or allow IP from wireguard configuration${NC}"
return 1
fi
# Check the route table
local routing_tables=$(ip route)
local expected_route="$allowed_ips dev $interface_name scope link"
if echo "$routing_tables" | grep -q "$expected_route"; then
echo -e "${GREEN}[✓] Correct route exists in routing table: $expected_route${NC}"
else
echo -e "${RED}[✗] Correct route not found in routing table: $expected_route${NC}"
return 1
fi
# Check whether the endpoint conforms to the 198.18.x.x format
local endpoint=$(echo "$response" | grep "endpoint:" | awk '{print $2}')
if echo "$endpoint" | grep -q "198.18."; then
echo -e "${GREEN}[✓] endpoint complies with the 198.18.x.x format${NC}"
else
echo -e "${RED}[✗] endpoint does not match the 198.18.x.x format${NC}"
return 1
fi
# Check traffic diversion rule
# The following rules must exist in the output of iptables -L -nv -t mangle
# The OUTPUT chain has three chains: mp_route_bypass, mp_route_mark, and mp_l3_route, and mp_route_bypass must be first.
# 2. The mp_route_bypass chain must have one rule with destination as allowed_ips and target as ACCEPT
# 3. The mp_l3_route chain must have one rule with destination as endpoint and target as MARK
local mangle_rules=$(iptables -L OUTPUT -nv -t mangle)
# 1. Check chain sequence in OUTPUT chain
if ! echo "$mangle_rules" | grep -q "mp_route_bypass" || \\
! echo "$mangle_rules" | grep -q "mp_route_mark" || \\
! echo "$mangle_rules" | grep -q "mp_l3_route"; then
echo -e "${RED}[✗] Necessary chain lacks in OUTPUT chain${NC}"
return 1
fi
# Confirm mp_route_bypass is in the first position
if ! iptables -L OUTPUT 1 -nv -t mangle | grep -q "mp_route_bypass"; then
echo -e "${RED}[✗] mp_route_bypass is not in the first position of OUTPUT chain${NC}"
return 1
fi
# 2. Check rules in mp_route_bypass chain
if ! iptables -L mp_route_bypass -nv -t mangle | grep -q "ACCEPT.*$allowed_ips"; then
echo -e "${RED}[✗] The mp_route_bypass chain lacks an ACCEPT rule for target $allowed_ips${NC}"
return 1
fi
# 3. Check rules in mp_l3_route chain
endpoint=$(echo "$endpoint" | awk -F ':' '{print $1}')
if ! iptables -L mp_l3_route -nv -t mangle | grep -q "$endpoint.*MARK.*0x1/0xf"; then
echo -e "${RED}[✗] The mp_l3_route chain lacks a MARK rule for target $endpoint${NC}"
return 1
fi
echo -e "${GREEN}[✓] iptables rules check passed${NC}"
echo "L3 feature check done"
return 0
}
# Parse command-line parameters.
while [[ "$#" -gt 0 ]]; do
case $1 in
-h|--help)
echo "Usage: $0 [options]"
echo "Options:"
echo " -h, --help Display help information"
echo " -l, --l3-check Check L3 feature"
exit 0
;;
-l|--l3-check)
l3_check=true
shift
;;
*)
echo -e "${RED}[✗] Unknown parameter: $1${NC}"
exit 1
;;
esac
done
echo "Start system check..."
echo "----------------------------------------"
echo "1. Check process status:"
# Check mp-sdk process
check_process "mp-sdk"
if [ $? -ne 0 ]; then
echo -e "\\n${RED}Check failed, stop${NC}"
exit 1
fi
# Check mp-speeder process
check_process "mp-speeder"
if [ $? -ne 0 ]; then
echo -e "\\n${RED}Check failed, stop${NC}"
exit 1
fi
echo -e "\\n2. Check network interface card status:"
check_interface "mp_tun0"
if [ $? -ne 0 ]; then
echo -e "\\n${RED}Check failed, stop${NC}"
exit 1
fi
echo -e "\\n3. Check acceleration status:"
check_speeder_status
if [ $? -ne 0 ]; then
echo -e "\\n${RED}Check failed, stop${NC}"
exit 1
fi
echo -e "\\n4. Check rp_filter configuration:"
check_rp_filter
if [ $? -ne 0 ]; then
echo -e "\\n${RED}Check failed, stop${NC}"
exit 1
fi
echo -e "\\n5. Check routing configuration:"
check_policy_routing
if [ $? -ne 0 ]; then
echo -e "\\n${RED}Check failed, stop${NC}"
exit 1
fi
echo -e "\\n6. Check traffic diversion rule configuration:"
check_iptables_rules
if [ $? -ne 0 ]; then
echo -e "\\n${RED}Check failed, stop${NC}"
exit 1
fi
# If the --l3-check parameter is specified, then execute L3 feature check
if [ "$l3_check" = true ]; then
echo -e "\\n5. Check L3 feature:"
check_l3_functionality
if [ $? -ne 0 ]; then
echo -e "\\n${RED}L3 feature check failed${NC}"
exit 1
fi
fi
echo "----------------------------------------"
echo -e "${GREEN}ALL check items are normal${NC}"
exit 0

2.1.2 One-Click Troubleshoot Anomaly Results and Solution

Check Item
Detailed Description
Abnormal Detection Result
Solution
Check Process Status
-
Process not running.
1. The SDK process is not running: It is configured for auto-start on boot. Check the service status, or you can use Systemctl restart mp-sdk.
2. The mp-speeder process is not running: Check whether the acceleration API has been invoked. If not, invoke the acceleration API.
Check NIC Status.
-
NIC exists but not started.
Check the "Check speeder status" item.
-
NIC not present.
Check whether the tun kernel module exists (modinfo tun).
Check rp_filter.
-
rp_filter not disabled.
sysctl -w net.ipv4.conf.mp_tun0.rp_filter=0.
Check Policy Routing.
-
Correct default route not found in the routing table.
Restart the SDK.
-
Policy rule not found.
Restart the SDK.
Check whether source IP address-based policy rules exist.
Obtain NIC IP address.
NIC not configured with an IP address, acceleration via this NIC unavailable, check recommended.
Monitor it and no action is required.
Check policy rule status.
Route not found in the routing table.
Restart the SDK.
Policy rule for the NIC not found, which may affect acceleration performance. Enable SDK policy routing management.
Enable SDK policy routing management.
Check speeder Status.
-
Not running or acceleration status abnormal.
1. Call the API to start acceleration.
2. Startup failed. Check for possible causes: datakey invalidation or network disconnection.
3. For other situations, contact Tencent Cloud Ops personnel.
Check Traffic Steering Rules
-
Traffic steering rules not detected, confirm whether this is as expected.
1. Confirm whether the API has been invoked to add the traffic diversion policy.
2. Addition failures are usually caused by traffic diversion rule configuration issues, such as spelling errors (such as TCP, UDP, and so on) or port numbers exceeding 65536. Check and resolve these issues yourself.
3. For other situations, contact Tencent Cloud Ops personnel.
Check L3 Feature.
Check wireguard virtual interface status.
wireguard virtual interface status abnormal.
1. If the wireguard virtual port is missing, which may be due to network issues or loss of connection with the controller, prioritize troubleshooting these causes.
2. For other situations, contact Tencent Cloud Ops personnel.
Check routing table
Correct route not found in the routing table.
1. If a machine has a route identical to L3, an ECMP scenario should be formed, which is currently not supported.
2. For other situations, contact Tencent Cloud Ops personnel.
Check whether the endpoint matches the 198.18.x.x format.
endpoint does not match the 198.18.x.x format.
Contact Tencent Cloud Ops personnel.
Check traffic steering rules - check chain order in OUTPUT chain.
Necessary chain missing in the OUTPUT chain.
Contact Tencent Cloud Ops personnel.
mp_route_bypass is not the first chain in the OUTPUT chain.
This issue is usually caused by users manually adding other rules. Please check it yourself.
Check traffic steering rules - check rules in mp_route_bypass chain.
The mp_route_bypass chain lacks the target ACCEPT rule.
This issue is usually caused by users manually deleting the corresponding rules. Please check it yourself.
Check rules in mp_l3_route chain.
The mp_l3_route chain lacks the target MARK rule.
This issue is usually caused by users manually deleting the corresponding rules. Please check it yourself.

2.2.1.2 Partial Links Disabled Due to High Packet Loss Rate

Common Issues:
Multi-NIC acceleration performance is lower than the sum of link bandwidths.
Single ENI acceleration performance is much lower than the link bandwidth without acceleration.

2.2.1 Common Reasons and Solution

2.2.1.1 Partial Links Disabled Due to Poor Network Quality

Common Reasons for Link Disabling: Excessive RTT latency or jitter, and packet loss on the link. You can confirm the link's network latency, packet loss, and disabled status by analyzing the 1.2.3 SDK logs.
Solution:
Perform a speed test on the physical link with poor quality after network change.
Adjust the link disable condition and increase the following parameters (such as higher than the actual link delay) to make ALL links participate in aggregation as much as possible.
Note: The default parameter balances bandwidth and delay for comprehensive performance. This adjustment is only used for testing the limit of aggregate bandwidth.
MaxRttDisableAggregation: latency threshold for aggregation links.
MaxRttThreshold: threshold for linkage failures.

2.2.1.2 IoT SIM Card Issue

Scenario: One or multiple IoT SIM cards are involved in acceleration, but the IoT SIM cards have not whitelisted our server ip, which can cause poor performance. This stream will be disabled.
Solution:
Replace the network interface card with an ordinary one.
Whitelisting the server ip for IoT SIM card on Cloud Connect.

2.2.1.3 Limited CPU Capability of Endpoint Devices

Query the device CPU usage. If the CPU usage rate of each core is high (for example, 90%), it indicates that the performance is limited by the device capacity.
For performance of typical configuration, consult Tencent Operation and Maintenance Personnel.

2.2.1.4 Policy-Based Routing Not Configured Correctly

Monitor whether the traffic is sent from multiple acceleration NICs.
If not sent from multiple acceleration NICs, confirm whether policy-based routing is configured for each network interface card through following steps:
Method 1: Execute the one-click detection script to check whether policy-based routing based on source IP is configured for each accelerated network interface card. Configure the correct policy-based routing according to the prompts.
Method 2: Query IP rule and policy-based routing via command line.
A default route will be configured in the corresponding routing table.

2.2.1.5 Multiple Acceleration Network Interface Cards Use the Same Operator Exit

If multiple SIM cards in a cellular network belong to the same carrier, they may access the same base station community. Subject to the overall bandwidth capacity of the community, adding more SIM cards may not increase the total bandwidth. Consider switching to other ISP SIM cards to expand the total link bandwidth.
Query the public IP address of the network interface card.
Reference command: curl --interface eth0 ip.sb
For the carrier IP address attribute query platform, refer to this website.

2.2.1.6 Caused by Low socket buffer

Check the packet sending and receiving status during traffic testing. If udp packet sending and receiving buffer errors are detected, increase this value.
Continuously monitor the iperf server socket buffer using `netstat -su` and check for buffer errors.
Check the socket buffer size.
Adjust the socket buffer size.
Restart after adjustment to speed up.

2.2.1.7 Hardware Does Not Support Encryption and Decryption Commands

Solution:
Disable encryption and decryption.
/usr/local/etc/mp-speeder/mp_client_extend.conf file configuration -disableCrypto to disable data encryption/decryption functionality.
Use hardware that supports encryption and decryption commands.

2.3 Iperf Traffic Test Experiences Flow Interruption

Problem manifestation: During iperf TCP traffic testing for aggregated link bandwidth measurement, traffic experiences a bottoming-out phenomenon.

2.3.1 All Links Participating in Aggregation Experience Packet Loss in Weak Network Conditions

Analyze SDK logs to confirm network delay, packet loss, and disabled status.
Log retrieval keyword: potentiallyFailed.

2.3.2 Frequent Handover Between 4G/5G Mobile Networks

The basic network performance of a single network interface card is poor. Without acceleration, it also shows large latency jitter and stream interruption during traffic testing.
You can use the 4/5G module AT Instruction Set to view the network the module stays on, signal strength, and signal quality.

2.4 Policy-Based Routing Issue

2.4.1 SDK Adds Multiple Duplicate Policy Routes

Check whether the SDK is pulled up repeatedly.
View method: Check /var/log/mp-sdk.log to see whether there is multiple occurrence of "Server started on ..." at the same time.

2.4.2 Detailed Route Error or Empty

Check whether the script pulls up the program with repeated deactivation and enable policy route operations.
View method: Check /var/log/mp-sdk.log to see whether policyRouteManagement quickly calls deactivation and enable when acceleration is turned on.

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック