High concurrency situation, returning packet loss,

[blade83lee]

High concurrency situation, returning packet loss,
2024/05/14 18:44:32 ping.go:201: D! no packets received, stats: &{{0 5 0 100 10.10.25.117 10.10.25.117 [] 0s 0s 0s 0s} 0}
but tcpdump has packet return
18:44:27.903699 IP 10.4.3.20 > 10.10.25.117: ICMP echo request, id 22102, seq 0, length 64
18:44:27.925773 IP 10.10.25.117> 10.4.3.20: ICMP echo reply, id 22102, seq 0, length 64
18:44:28.904025 IP 10.4.3.20 > 10.10.25.117: ICMP echo request, id 22102, seq 1, length 64
18:44:28.926564 IP 10.10.25.117 > 10.4.3.20: ICMP echo reply, id 22102, seq 1, length 64
18:44:29.903706 IP 10.4.3.20 > 10.10.25.117: ICMP echo request, id 22102, seq 2, length 64
18:44:29.928764 IP 10.10.25.117 > 10.4.3.20: ICMP echo reply, id 22102, seq 2, length 64
18:44:30.903703 IP 10.4.3.20 > 10.10.25.117: ICMP echo request, id 22102, seq 3, length 64
18:44:30.927299 IP 10.10.25.117 > 10.4.3.20: ICMP echo reply, id 22102, seq 3, length 64
18:44:31.903708 IP 10.4.3.20 > 10.10.25.117: ICMP echo request, id 22102, seq 4, length 64
18:44:31.926030 IP 10.10.25.117 > 10.4.3.20: ICMP echo reply, id 22102, seq 4, length 64

How to optimize

[ZhaoBaymax]

On the sending end: the CPU will allocate a socket connection for each ICMP. That is to say, even in the case of coroutines, it is necessary to wait for the CPU to switch contexts. The start time is calculated in user mode, and there is still some time before the packet is actually sent out. Similarly, on the receiving end, this situation also exists. You can check the scheduling time of the service CPU to confirm this problem.