TCE1保序功能开发-----续

                                                                                                                                                                                            09.12.6    

        进入测试部之后，发现的主要问题是：当存在背景流（即不是我们关注的其它流量）的时候，会导致排序能力下降。主要原因是背景流同样会占用排序的缓存，干扰了我们关注的流量的排序。这个问题暴露了前期方案的一个大缺陷。而测试的结果是不能满足外场应用的。

        该如何解决？

                                                                                                                                                                                          09.12.13

         到今天的时候，问题已经基本弄清，也有了一个解决办法，就是把排序缓存的大小从16扩大到了32。一条多链在绑定了16个子链（0-31时隙全部用上，每个子链2M带宽）的情况，发50%带宽的混长包，只有极少量乱序。

         感谢部长和大庆的陪伴。那段时间感觉压力很大。尤其是某位领导施压之后，内心孤独无助。你们给我带来了力量。让我镇定下来。我要同那位施压的领导说，其实你给了我很好的思路，但是在当时那样的情况下。你只需要告诉我问题的紧迫性就可以了。每个人的内心都是想向好的方向努力的。千万不要矫枉过正。你的不信任让我感觉很不好。

        仍然要感谢那位施压的领导，我理解你的压力可能比我更大。任何正的或是反的反馈都是对我的促进。就是千万不要对我沉默不语！我会伤心的，呵呵。

         解决的方案是在和大家尤其是和部长的讨论中形成的。尽管我起的作用很小，故障的解决仍然给了我信心。如果以后遇到了新的故障，我有信心解决它。这个过程中我学到了很多的东西。有一些方法很重要。

        1.统计的方法。

        当我没有办法从理论上对故障的现象进行解释的时候，感觉是一片的迷茫。不知道该如何下手。从哪个方面去解决它？故障的现象就是大量的包超出了排序的能力，这一点在我加的计数中可以看到。可是接下去呢？

        “对超出了排序的报文进行统计！看看到底超出的范围是多少.”

          看起来很简单的一句话提醒了我，也就是靠着统计，我们找到了应该把缓存扩大到多少的。

         “一步一步来排除，找到问题的根源在哪？”

         接着，对流量的大小，报文的长度，流量的时延，下载的速度等影响因素进行了统计。把原来的版本和修改后的进行对比，果然，又得到了一些新的思考角度和初步结论。

          回想以前老大们的讨论。这一回，我有些理解了。从这些初步结论中，又返回到 发送端的处理，流量特征，，TCE1传输链路特点以及ftp网络时延的理论分析，终于问题的根源渐渐显露出来。

         2.自测的方法。

         按照扩大缓存的方案修改完之后，第一次我把测试的方案写在了纸上。

         1.用一个包，将基本流程走一遍。

         2.用一个包，把LM和sram两种处理方式的流程走一遍。

         3.在代码中模拟随机范围为1~64多链。

         整个过程走下来，大概花了2个小时的时间。但是却省去了以前一些零星思考的时间，和时不时的担心。我才知道，以前的偷懒，其实是伴随着时间的浪费和心理的担忧的。是事倍功半。

         虽然星期天还是因为一个故障，测试人员打电话给了我。但是我依然很有底气不去加班，因为上面的工作给了我信心。