一个响应ping包延迟偏大的问题

        前段时间客户反馈一个使用pc上的命令行ping无线设备(WiFi4)时,设备平均响应时间(测试时长2小时,1秒Ping一次)相比其它机型偏慢的问题,并上传上具体的时间的Log.从log中看到,大多数包的响应还是比较快的,只是个别响应时间较长,且响应时间长的包时间几乎都是一样的100多ms.如下是部分响应时间截图.

       整个2小时的测试时间里,总是时不时的出这么上102,104ms的响应时间,这直接导致了平均响应时间被拉大.于是本地测试,也发现了类似的延迟.本地测试时,现象略有不同,具体现象是Pc每ping28包,设备就有一次响应时间100ms的现象出现.连续测试多次都是这样的规律.将路由设备成open模式,使用抓包卡抓Ping包,发现pc发出echo的时间是很准的,就是默认的1次一包;而设备回复的echo reply则时快时慢,慢的时候也正是有将近100ms的延迟.即收到echo后100多ms才有看到echo reply发出,于是可以确认延迟是设备侧的处理问题,与发送侧无关.具体抓包的延迟见下图(下图不是100ms,而是50ms,是因为这是已经找到了延迟的地方了,所以改了延迟的时间以进一步确认是否找对地方.):

后面就在接收流程上加打印,确认延迟是卡在哪个步骤上.通过步步调试,最终确认延迟是因为接收的802.11数据的seqnum不连续,导致umac层进行了reorder的处理.即umac检测到丢了一个seqnum,于是将这个新来的数据包放到了一个reorder的队列(Q_r),而不是放的正常的给到上层(tcpstack)的队列(Q_t).而reorder队列会等一段时间(默认100ms),只为了等到那个丢失的seqnum的数据包,之后再将Q_r中的数据重新放回Q_t中,以供上层处理.如果100ms内那个丢失的seqnum来了,会重新排序后立即放回Q_t中,但是这里因为每次那个丢失seqnum都不来,所以每次都是100ms超时.

那么,那个seqnum为什么总是丢?还这么有规律,去哪了?是个什么包呢? 继续抓包看吧!

见上图,通过加打印丢失的seqnum与抓包对应,发现是本次丢失的seqnum是177,原来是个arp_req!!!

好吧,明白了.