【精彩】关于UDP千兆以太网发送程序丢包的分析探讨

admin

一直以来困扰于千兆以太网的丢包问题，后在芯路恒开源技术群里经过几位网友的讨论指点，终于找到了代码中存在的一个bug，降低了丢包率，整个讨论过程还是蛮有意义的，现分享出来。

温馨提示，文章图片比较多，电脑端通过点击图片可以查看高清大图。


【丐帮帮主】


【丐帮帮主】计算4500+05D6+70F6+4000+8011+C0A8+016E+C0A8+0164=2FFFF
【丐帮帮主】ffff+2 =1 ~1=fffe
【丐帮帮主】按照计算方法自己用计算器计算也是FPGA的计算结果，FFFE。但是实际是FFFD


【丐帮帮主】不是所有的都错，只有几个出问题
【丐帮帮主】
【丐帮帮主】我不知道是不是我理解错了首部的计算方法
【丐帮帮主】我知道是哪里原因了
【丐帮帮主】
【丐帮帮主】红色部分的求和如果有进位，也应该把进位加上再取反，代码中，没有做这步处理


【小梅哥】意思就是一旦涉及到有进位的帧，就会报错？


【小梅哥】测试了，长包比短包的丢包率高很多。我现在按照你的这个思路去核对下，丢掉的那几个，是不是刚好就是缺少进位的那几个
【小梅哥】实际就是，多执行一次加法就可以了，有进位加了就对了，没进位，加个0和没加没啥区别
【小梅哥】




【Lye】i == 0 那加法是不是太多了？timequest的时序约束 slack小于零， 我把那个连加分开了
【小梅哥】从严谨理论来说，你这样肯定一个周期完不成，但是不怕啊，这个数据要在执行计算的20个时钟周期之后才会被使用，20个时钟周期，足够他稳定下来了
【一起走】
【一起走】原来的代码没问题的
【小梅哥】但是昨天的那个网友说的确实是有问题的，我昨天已经做了计算验证





【一起走】从代码上，应该是不会丢失进位的，校验和是16位的,buff是32位的
【小梅哥】比如这个表里，第一列是待计算数据，第二列是待计算数据的十进制表示和和，第三列是和的十六进制表示，不是说会丢，而是说把高16位和低16位相加的那个地方，没有继续考虑相加结果可能高16位不为1的情况。例如上面这个表里的数据，第一次全部求和结果是2FFFE   ，第二部把高16位和低16位相加，应该是10000，这里高位依然是1.但是程序中对这种情况就没有处理了，所以遇到这种情况校验和计算就出错了。
【一起走】懂了。
【小梅哥】


【小梅哥】我现在这么改，多了第二步，但是如果第二步的时候高16位为0，是不影响结果的，没有任何改变，不为0则能够执行一次相加。整体来看，代价就是多了一个时钟周期而已


【一起走】
这样会不会更好，我这是循环
【小梅哥】没有执行i+操作，所以是循环，更好不更好的我不知道，应该时序性能都差不多http://file:///C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\Z}4JA~3{S79KP7UYELJH){7.gif，写法上简洁一点了
【小梅哥】这是按照之前的讨论修正后的代码。丢包率降低到0.2%了，之前是0.5%左右。

fzwwj95

好文，精彩！

小白的黑

精彩好文，最近在用UDP，帮助很大，给梅总点赞

laidaihua

抱歉，我没看明白那个校验和为什么还要搞个高16位加上低16位？难道数据都是32位的？那干嘛不都搞成16位的直接计算呢？反正校验和是只取16位的，按65536取模后进位是全部自然溢出了的。。

小馬哥

说白了就是只做一次低16位加高16位是没考虑此次加法的进位的可能，之所以没考虑是因为：对于只有2个数的反码运算，在将高16位加回低16位时是不可能出现进位的       第一步中多个数相加，那么就会有不同情况了，因为进位可能大于1 不知道理解的对不对