终于发现lmhub的瓶颈了

 上次修改了广播的缺陷，直接写入所有通道来发送片，目的是可以同时接收对端发送的帧。（因为广播使能是不能发送片应答）

现在更主要是问题，当然不是致命问题，却是最难解决的问题。lmhub目前最大的瓶颈就是搬移片的速度太慢。

如果一次接收了所有路的片，并且假设都是接收了4片，那么就要搬移很长时间，而且搬移的过程中是关中断的。

这样必然造成丢片。

呵呵，当初脑子没转过来，为什么早没有想到关中断搬移，如果搬移时间超过10ms，就会丢片，而且使用c语言写的，执行时间很长。

但是这个问题其实不会有致命的影响，因为一般情况下通信量很小，而且帧也不会那么大，同时接收到那么多片的

可能性也比较小。所以一般不会丢片。

解决办法有两个：

第一：把搬移代码改写成汇编，但是比较困难。

第二：如果不行就只能减少通道数量了。

当初之所以没有注意到这里，不是我没想到，而是我认为内存搬移会很快，慢就慢在从FPGA读数据，从总线读数据的速度虽然慢点，但大块的搬移内存也是很慢的。有关这些操作的时间需要通过实验得到。

第二天：

早上一来和涛哥讨论了一下，立刻又发现了新亮点，上边写的原因是本质原因。一下是更清楚的分析。

程序的结构是

for（71路）

{

ipset 1

A.关中断中，先搬移一路到xmem中

ipres

B.判断这路是否已经收够片数了，如果够了就组帧。

}

 昨天我实验是把B.中尽量减少搬移的次数（把搬移的代码都注释掉了），这样B.相当于很快就完成了，大部分消耗在A.，A.是关闭中断的，循环75遍的时间关闭中断，这样肯定会丢片的。这就是昨天为什么很简单的代码，几乎相同，唯一的差别就是我减少了搬移次数，结果丢帧丢的更厉害了。原因就是连续关闭中断的时间太长了。

因为root中储存4片，所以必须在40ms内把所有71路*4个片搬走，可以让下一次中断发生时新片有root可放。

但是要注意一个很重要的现象，单发帧，可以完全接收，说明问题就在连续发送两帧的链接处。

因为当收完71路的帧的最后一片时，相当于一下进来了71个整帧，B.的处理时间一下加长了，之前只是简单的记片数，现在还要搬移整帧，然后checksum，所以这下不能在40ms内搬移完毕所有buf，所以下一帧的片再进来时就会丢帧，尤其是没有收到头片，所以后边的整个帧都会丢掉。如果连续发3帧，那么第一帧和低三帧能够收到，第二帧将丢失。

 终于发现关键点了：我把checksum去掉后双向广播发送都不丢帧。