linux – UDP Packet drop – INErrors Vs .RcvbufErrors

前端之家收集整理的这篇文章主要介绍了linux – UDP Packet drop – INErrors Vs .RcvbufErrors前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我写了一个简单的UDP服务器程序来了解更多可能的网络瓶颈.

UDP服务器:创建UDP套接字,将其绑定到指定的端口和addr,并将套接文件描述符添加到epoll兴趣列表中.然后它的epoll等待传入的数据包.在接收到传入数据包(EPOLLIN)时,它读取数据包,只打印接收的数据包长度.很简单,对:)

UDP客户端:我使用hping如下所示:

hping3 192.168.1.2 –udp -p 9996 –flood -d 100

当我以每秒100个数据包发送udp数据包时,我没有发现任何UDP数据包丢失.但是当我淹没udp数据包(如上面的命令所示)时,我看到有重大的丢包.

测试1:
当从UDP客户端淹没26356个数据包时,我的示例程序只收到12127个数据包,其余14230个数据包被内核丢弃,如/ proc / net / snmp输出所示.

cat /proc/net/snmp | grep Udp:
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
Udp: 12372 0 14230 218 14230 0

对于Test1,丢包率为〜53%.

我验证了在客户端和服务器端使用“ethtool -S ethX”命令的硬件级别没有太多的损失,而在应用程序级别我看到如上所述损失了53%.

因此,为了减少丢包,我尝试了这些:
– 使用renice命令增加我的示例程序的优先级.
增加接收缓冲区大小(在系统级和进程级)

突破-20:

renice -20 2022
2022 (process ID) old priority 0,new priority -20

收到buf大小到16MB:

At Process Level:
int sockbufsize = 16777216;
setsockopt(sockfd,SOL_SOCKET,SO_RCVBUF,(char *)&sockbufsize,(int)sizeof(sockbufsize))
At Kernel Level:
cat /proc/sys/net/core/rmem_default
16777216
cat /proc/sys/net/core/rmem_max
16777216

这些变化后,执行Test2.

测试2:
当1985076数据包从UDP客户端淹没时,我的示例程序接收到1848791个数据包,其余136286个数据包被内核丢弃,如/ proc / net / snmp输出所示.

cat /proc/net/snmp | grep Udp:
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
Udp: 1849064 0 136286 236 0 0

对于Test2,丢包率为6%.

数据包丢失明显减少.但我有以下问题:

>丢包可以进一步减少吗?我知道我在这里贪婪:)但是我只是试图找出是否可能进一步减少丢包.
>与Test1不同,Test2中的InErrors与RcvbufErrors不匹配,RcvbufErrors始终为零.有人可以解释背后的原因吗? InErrors和RcvbufErrors之间的区别究竟是甚么.我理解RcvbufErrors但不是InErrors.

感谢您的帮助和时间!

解决方法

调整Linux内核的网络堆栈以减少数据包丢失有一点涉及,因为从驱动程序一直到网络堆栈有很多调整选项.

我写了一个long blog post,从上到下解释所有的调优参数,并解释了/ proc / net / snmp中的每个字段是什么意思,所以你可以弄清楚为什么这些错误发生.看看,我认为它应该帮助你让你的网络下降到0.

原文链接:https://www.f2er.com/linux/401790.html

猜你在找的Linux相关文章