对大宋下一代高端通信系统设计的七个展望

作者 | 2011-06-14 18:21 | 类型 通讯产品 | 117条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




高端通信系统设计从来就是一个困难的话题。一个优秀的系统设计往往决定了其竞争力和相应的生命周期。

本文试图阐述笔者对下一代高端通信系统设计的一些展望。抛豆腐引砖块，其目的是通过读者的评论，使得美军，共军，国军，伪军等的知识和经验可以共享。使得Open Source的精神发扬光大。

1。 LDF Rule（Legacy Decides Future）
系统都是演变的，而非设计的。一个好的系统设计必须首先满足对历史系统，历史代码的演进路标。否则，就是在做Science，而非Engineering。这方面最大的挑战就是在哪个release去掉哪些历史遗留问题。改良的代价一定是小于革命。

在这个第一重要的法则里，要求的是系统设计师必须了解细节。需要能进能出［想歪了的同学请自己惩罚一下自己邪恶的心灵］。要的是能bottom up。然后在bottom up的基础上，进行top down的设计。缺一不可。只能bottom inside，是一个单纯的工程师；只能top through就是一个玩胶片的大忽悠。

2。 CDMD Convergence Rule
（Control Plane，Data Plane，Management Plane and Debug Plane Convergence）
这个rule类似与我大宋气功中的一句经典法则：人身无处不丹田。啥意思呢？
控制平面，数据平面，管理平面，调试平面都将是一个逻辑的概念，而非一个物理的实体，例如控制平面卡，数据平面卡。。。

上述的各个Plane都是你中有我，我中有你。［想歪了的同学请自己惩罚一下自己邪恶的心灵］。

在任何一个环节都需要有相应的逻辑部分。整体系统的任何一个平面是通过分布在系统各个环节中的子平面来共同构成的。

这方面最大的挑战是：系统架构师必须对分布式系统的设计非常过敏，sorry，敏感。

在分布式系统设计中，一个最重要的理论悖论是： 在分布式系统中，在任何时刻，在任何一个节点上，是无法知道当时的全局状态的。

这是啥意思呢？

就是，除了上帝，你在一个时刻点Ti，是不可能知道Ti时刻系统其他信息的。你能知道的信息只能是T（i＋Delta）。这个Delta就是通信开销所带来的。

大白话就是，杨小姐（杨贵妃），从理论上，Y从来就没有吃过新鲜的荔枝，no matter驿道上的马儿跑的有多快。

在这个分布式天生的死穴问题上，带来的问题是最多的。

作为系统架构师，必须对时序逻辑（Temporal Logic）有所掌握。Otherwise, 系统设计一定是漏洞十出。

另外，分布式系统的nature决定了任何全局算法的优化一定不是最优的，而是次优的。
在CDMD Convergence的设计基础上，一个很大的演变就是：C，D，M，D的计算资源的自适应（Adaptive）的调配。而非静态的划分。

要充分利用计算池的模型，Processing on Demand。

3。CTP（Close To Port, Close To Packet， Close To Payload） Rule
计算或者存储能力一定要离端口（Port）近，离数据（Packet Descriptor和Payload）近。越远，越歇火。 当官是要离党中央近。做系统是要离Traffic近。

这里的一个设计Case study 是：要充分利用系统中线卡，处理卡，I/O卡上的计算能力。这些计算能力是离端口最近的，对Traffic而言，是Local Bus的距离，而非Interconnect的长途跋涉。

计算是分布的。分布计算的集合就是系统的总体计算和（或）处理能力。

4。 CCNUMA Adoption Rule
CCNUMA一定会被广泛的用在将来的高端通信系统中。

只有CCNUMA的应用，才能达到分布式技术的同时，又能支持历史系统，CDMD的融合和Close to Port的法则。

在CCNUMA系统设计中，必须对Memory的分布非常敏感。跨Interconnect，例如QPI，的过分存取，一定是带来硬伤。

系统架构师必须对Cache，L1，L2，和L3和ccNUMA－Interconnect，例如QPI等一些知识有足够的积累和实战能力。否则，很难把握CCNUMA系统。

5。 Hybrid Model Rule
ASIC，FPGA等等不会消亡。消亡的是你革命的心。任何设计都是一个性价比的折衷。
天下没有最美丽的女子；只有最适合你的女人。
在这个设计法则方面，要格外注意ASIC或者FPGA上的控制CPU的计算能力的浪费。
在CCNUMA的基础上，所有的CPU的整合就是一个CPU。所不同的是处理的数据可以不同而已。

6。 MapReduce Rule

经典的并行计算的MIMD模型应该被广泛的应用。

多个计算流形成一个计算池；
多个数据流形成一个数据池。

MapReduce不应该只是Loosely Coupled Distributed Computing的宠儿，例如Google，Facebook。

MapReduce的思想精髓应该，而且也会被广泛的应用在高端通信系统（Tightly Coupled Distributed Computing）的设计上。

7。 x86＋ zero－overhead Linux
x86＋Linux的在通信系统中一定会得到广泛的应用。从而使得通信系统能够迅速的实现，更为重要的是，支持大量的3rd party的应用。

任何不adopt Linux／Unix的力量都是错误的。历史的将来会证明这一点。。。

应用决定一切。 Linux的强大中的强大就是无数的应用。

(8个打分， 平均：3.75 / 5)

工具箱
本文链接 | | 打印此页 | 117条用户评论 »

雁过留声

“对大宋下一代高端通信系统设计的七个展望”有117个回复

  1. Qi 于 2011-06-14 6:26 下午

    这篇很靠谱。

  2. kernelchina 于 2011-06-14 6:37 下午

    一大早看到这么经典的评述，很兴奋。

  3. Panabit 于 2011-06-14 6:38 下午

    看了这个，才知道真正的距离。

  4. ghd 于 2011-06-14 6:43 下午

    一看就知道首席是软件出身，补充一下我的一点不成熟的看法：
    1 在系统设计时，首先分析客户需要的feature和价格，知道自己的竞争对手的产品（在大规模上量的产品中，如果价格不具有竞争力，那产品估计很难有竞争力的，当然对于某些创新的产品，那是另一回事），
    2 根据feature，来进行软硬件的划分，芯片的选型，这时需要考虑各个研发团队的能力，哪些东西可以买，哪些可以自己做
    3 定义系统各个模块的功能和外部接口
    4 对于现有的模块，除非完全不能满足需求，不然不要轻易进行革命

  5. 微博网友参观团 于 2011-06-14 6:44 下午

    拜首席牛文！

  6. Multithreaded 于 2011-06-14 6:46 下午

    Echo 一下吧！

    》3。CTP（Close To Port） Rule
    Yeah, using the NIC to do load balance among multi-cores is the way to go.

    >>7。 x86＋ zero－overhead Linux
    One way to do this is to use the user-space device driver to get rid of the kernel TCP/Ip stacks. In doing so, the zero overhead Linux can be effectively used in network monitoring :-)

  7. jkdo 于 2011-06-14 6:46 下午

    “作为系统架构师，必须对时序逻辑（Temporal Logic）有所掌握。系统设计一定是漏洞十出。

    ”，有笔误？

  8. zhengjia1984 于 2011-06-14 6:51 下午

    最近在搞tilera,这篇正是需要的。

  9. tilera? 于 2011-06-14 6:53 下午

    用tilera？你哪个公司的？赶紧跳槽吧，别再浪费青春了。

  10. pike 于 2011-06-14 6:54 下午

    呵呵，首席高见！

  11. 陈怀临 于 2011-06-14 7:38 下午

    谢谢ghd的补充。我thought那几条已经是前提了。所有没有谈。

  12. 沙加 于 2011-06-14 7:45 下午

    弯曲上好久不见如此给力的文章了

  13. 玛雅茶 于 2011-06-14 8:08 下午

    硬件出身的人表示对软件了解不多，学习中。。。

    PS：首席考虑做个弯曲的MSN群或者QQ群吧，亦或邮件组，大家就技术问题可以多交流

  14. ZC 于 2011-06-14 8:24 下午

    首席发飙了。。。

    这文章信息量大啊，谁能沿着这条路走通，谁就能纳入首席范畴

  15. if 于 2011-06-14 8:28 下午

    首席好，您老把 Debug Plane加进来构成四大plane，是否可以如此理解：其，提供一个内部观察系统是否健康的通道，以便在其后的生命中周期中逐步优化促进系统茁壮成长？特别是多核场景下

  16. Panabit 于 2011-06-14 8:59 下午

    首席如果同意，我来创建一个QQ超级群！

  17. 陈怀临 于 2011-06-14 9:02 下午

    Yes, pls, 大弟子。

  18. Panabit 于 2011-06-14 9:19 下午

    已经创建好了，群号为108994604，群名为“弯曲评论-弯友群”。

  19. Panabit 于 2011-06-14 9:30 下午

    首席，你有QQ吗，如果没有，可以申请一个，这个在国内交流是很方便的。你进去后，我让创建的兄弟将你升级为管理员。

  20. 人气 于 2011-06-14 9:36 下午

    这qq群是要从弯曲抢人气啊，哈哈

  21. 清华土著 于 2011-06-14 9:42 下午

    有机会在FIT做个讲座，1～7逐个讲解吧！

  22. Panabit 于 2011-06-14 9:52 下午

    这个群也是弯曲所有，不存在抢的问题，另外讨论的内容和这个有一定的互补性。目前已经超过20人了，往大家踊跃加入！

  23. yuhao 于 2011-06-14 10:01 下午

    为什么不搞邮件组？QQ群…

  24. 陈怀临 于 2011-06-14 10:10 下午

    弯曲是天下人的弯曲。焉存在抢不抢的道理。天下为公。

  25. cracked 于 2011-06-14 10:26 下午

    我一直看成“歪曲评论”。直到有一天有个同事在我后边读 wan.我才回过神来。

  26. Panabit 于 2011-06-14 10:27 下午

    已经超过30人了，欢迎大家继续加入！

  27. 阿峰 于 2011-06-14 10:29 下午

    还是建议mail-list或者BBS，QQ group不靠谱~~~

  28. 陈怀临 于 2011-06-14 10:35 下午

    不知如何加入。我的：1722753142。panabit，add me

  29. Panabit 于 2011-06-14 10:40 下午

    我加你好友了，你接受，然后我将你加到群里。或者，你自己直接加群，我接受也可以。

  30. 理客 于 2011-06-14 10:58 下午

    首席多年深入实践体验得来的精华汇总一次发射，珍贵呀:)

  31. Panabit 于 2011-06-14 11:02 下午

    弯曲评论-弯友群：108994604，已经50人了，欢迎大家继续加入！

  32. Panabit 于 2011-06-15 12:15 上午

    已经超过60人了，看来本周过100问题不大。

  33. 谢谢32楼 于 2011-06-15 12:54 上午

    以后有啥问题就可以到群里向大师们请教啦~~~

  34. 专注 于 2011-06-15 1:01 上午

    mark

  35. happydanye 于 2011-06-15 1:29 上午

    为什么我看到这个：“［想歪了的同学请自己惩罚一下自己邪恶的心灵］”的时候才想歪呢？看来我本质还是很纯洁的

  36. 老韩 于 2011-06-15 2:02 上午

    暂时协助管理此群，请申请加入的朋友注明“弯曲评论”

  37. Sting 于 2011-06-15 5:22 上午

    Legacy Decides Future，深以为然； 现在好多大忽悠啊。。。。

  38. 陈怀临 于 2011-06-15 6:13 上午

    自己读了一下。还不错。其实就是昨天调iPhone程序休息时随手写的。当然这些想法在脑子里好几年了。

  39. 吴朱华 于 2011-06-15 6:23 上午

    看了两篇的飘过

  40. 陈怀临 于 2011-06-15 6:29 上午

    这里面我以前最吃不准的就cc－NUMA。从做芯片设计时，就开始想这个问题。也请教过YY Zhou和Xiaodong Zhang。当确实他们毕竟对通信系统接触少一下（北美的同学不要乱forward。。。）。

    我现在基本上思想成熟了。我确信cc－NUMA是个方向。

    另外，上次似乎看见大宋的首席存储科学家对cc－NUMA的概念貌似还有点糊涂。请自己补一补：－）

  41. 三千大千世界 于 2011-06-15 6:58 上午

    非常同意首席关于调试平面的看法，这个很重要。看看Cisco的debug命令就知道了，对开发、测试以及用户都是意义非同寻常啊！
    另外首席提到x86会在通信系统大行其道，不知道是指的路由交换，还是网络安全？H和C用x86的好像不多吧？
    请多指教！

  42. 理客 于 2011-06-15 8:13 上午

    调试的最高境界是四化：把系统裸体化、透明化、肢解化、DIY化

  43. asr1k 于 2011-06-15 8:53 上午

    Linux是必须， 而X86是趋势， 真的， 说实话真是的。 有些场景MIPS、ARM虽有多核， 频率还是不高，有些复杂的逻辑处理还是不够， 跟着intel混， x86性能基本上2年翻倍， 内存容量也随便乱疯涨。。。这些东西的确是通信行业非常需要

  44. asr1k 于 2011-06-15 8:56 上午

    To 42.理克

    意思就是拔了衣服做CT， CT做完照着片子做解剖， 然后DIY个充气娃娃？

  45. rinehart 于 2011-06-15 9:12 上午

    坦白的说，我不知道这篇文章在说什么

  46. 理客 于 2011-06-15 9:12 上午

    是自己脱，自带CT，自我解剖，自己DIY

  47. rinehart 于 2011-06-15 9:19 上午

    男人一多，貌似到哪儿，话题都会变味

  48. HJ 于 2011-06-15 9:46 上午

    “就是，除了上帝，你在一个时刻点Ti，是不可能知道Ti时刻系统其他信息的。你能知道的信息只能是T（i＋Delta）。这个Delta就是通信开销所带来的。”

    的确如此，不过还有一个设计思路是，一个节点不需要知道另外一个节点的状态。

  49. multithreaded 于 2011-06-15 3:17 下午

    加一点：

    8。无锁设计、无锁数据结构将在多核设计中大放异彩。

    在高性能的通讯系统中，任何加锁的操作都会对性能有很大的影响。应该少用或不用SPIN-LOCk, 改为用原子操作，无锁设计、或基于CAS的无锁数据结构。

    要懂 Memory Consistance Models; 否则程序的正确性无法保证。

    总之，CS的三大基础课程一定要学好：

    Computer Architecture
    Oerating System
    Compiler Optimizations

  50. EetyChen 于 2011-06-15 5:33 下午

    “Y从来就没有吃过新鲜的荔枝，no matter驿道上的马儿跑的有多快”，这是分布式理论CAP的大白话呀！

  51. xux 于 2011-06-15 5:36 下午

    Computer Architecture
    Oerating System
    Compiler Optimizations

    都学过，都没学好，都正在学

  52. 陈怀临 于 2011-06-15 5:50 下午

    多线虫，sorry，多线程，我感觉你老去开这几门课算了。。。理论＋实践。你老的银子。。。

  53. beiju 于 2011-06-15 8:23 下午

    被催的公司不让上QQ。。。

  54. ccNUMA? 于 2011-06-15 8:49 下午

    斗胆挑战一下首席：

    通信系统业务特性天然是分散的，适合被load balance的（按包、按流、按会话。。。）

    因此，即便是考虑到Legacy系统，也非常容易移植到多个CPU上来。举个例子，web应用天然也是适合被LBS的，因此从一台扩展到多台几乎不费什么劲；DB应用超过4台服务器性能就很难线性了

    所以，我不认为cc-NUMA对通信系统有什么价值，不管是高端还是低端。一方面硬件上看似获得了一个“单一的大CPU”，同时又要考虑Interconnection等，还不如干脆就当一个个独立单位，按LBS思路去设计来得简介。

    为什么现实中有不少应用会跑在cc-NUMA上？那是因为OS等底层支撑软件帮你考虑到那些复杂的因素，使得软件开发难度大大降低。可那是应用软件，通信系统的软件全部要自己从底层优化，就享受不到这个好处了。

  55. kernelchina 于 2011-06-15 8:57 下午

    松散的分布式，比如web；紧密的分布式，比如cluster或者multi chassis system。两者的需求不一样。首席说的这个，是对通讯产品来说的，这里要求高吞吐，低延迟。和web的要求不是一个数量级的，所以不能等同。

  56. ccNUMA? 于 2011-06-15 10:07 下午

    松散、紧密和吞吐、延迟之间，没有必然联系

    关键不是看业务本身的吞吐和延迟，而是看可切分的每个任务之间，交互的吞吐和延迟需求。这才是决定松散和紧密的关键

    就通信业务而言，我不认为每个“可切分的任务slice”之间，有很强的实时交互需求。综合所有从底层到上层来看，商业应用只有RDBMS才是最典型的紧密型，当然某些专有科学计算领域也是。

  57. aguai 于 2011-06-15 10:39 下午

    差距，这就是差距，拜读了。谢谢首席，多出手写这类文章啊。

  58. BEN 于 2011-06-15 11:56 下午

    第2要加个Service Plane吧？网络感知业务、网络加工数据流是未来智能网络的关键吧。

    我反对第3，或者说第3的思想太陈旧了吧。您的第2、第6都说明了分布式处理的重要，也就是区分不同类型的数据（快速、慢速、中快、中慢）的差异化处理，第5，第7都说明了不同技术在处理不同数据类型上的优劣。何以又蹦出来个如此绝对的第3呢？

  59. multithreaded 于 2011-06-16 1:27 上午

    >通信系统业务特性天然是分散的，适合被load balance的（按包、按流、按会话。。。）

    关键是如何使 load balancer 不会变成新的瓶颈口呢？

    比如：

    1) assume 6-cores/processor, how many cores will be used for load balancing?

    2) If one wants to TCP based load balance, he (she) needs to parse L2/L3/L4 paket headers …

    3) If one wants to do session based load balance, he (she) has to do application-level parsing …

    All these become hard issues when the linerate is 10Gbps.

  60. true 于 2011-06-16 1:44 上午

    给力！

  61. 桔片爽 于 2011-06-16 5:06 上午

    我什么都看不懂，但我绝对是最忠实的粉丝，所以我也最悲催~·

  62. coffee749 于 2011-06-16 7:13 上午

    有個困惑, 求首席賜教: “x86＋Linux的在通信系统中一定会得到广泛的应用”. 請問這是指data plane的實現, 會由x86 取代現行的NPU (network processor) 平台嗎? 比方說. L3 forwarding 分別由x86與NPU實現的話, 從架構上分析, 哪一個的效能會比較好呢? 謝謝

  63. chinaslot 于 2011-06-16 7:57 上午

    LDF Rule（Legacy Decides Future）

    这个真是看的我老/中泪纵横啊，top through这个东西其实是国内一种非常浮躁的趋势。不谈Legacy，一切的一切都是扯淡。

    国内某些技术人员的想法都太多，太浮躁。总是自以为高屋建瓴。其实那个叫空中楼阁。

    首席的这篇文章，老实说我懂得不多，毕竟很多东西不是我的专业，但是明显能感觉到首席这篇文章的诚意，唉这年头做技术能显出一个“诚”字真的不多了。

  64. bneliao 于 2011-06-16 9:40 上午

    分布式和多线程有没有什么重要原则

  65. yjz0065 于 2011-06-16 10:41 上午

    简直就是独孤九剑！

  66. 陈怀临 于 2011-06-16 11:14 上午

    ccNUMA能够很好的照顾历史系统，例如packet buffer，session table，control loggin等事情。否则系统演化很难受。不是理论上能不能拆分，而是历史的负担让你动一发而牵全身。。。

    XLP832， Tilera，Sandy Bridge基本上为ccNUMA在通信系统的应用铺平了道路。下面就看软件系统的delopyment了。关键还是要把握好memory的分布何设计。要把cache和跨interconnect的事情量化好，从而找到一个适合自己系统的pattern。

    学术上，不可能为工业界提供一个ccNUMA的算法模型。一定要自己去摸索和调优。

  67. ccNUMA? 于 2011-06-16 7:56 下午

    首席你的意思是不是说，有了ccNUMA，即使用户完全不管多核存在，程序也能跑。但如果要达到性能线性增长，就需要考虑很多东西 (我理解此时考虑的东西差不多与非cc系统类似了，cc的存在是确保用户什么都不管系统也能work)

    X86我有个基本判断请大家讨论：其开花结果的主要区域在单板1-2 die ，below 40G throuthput(基于当前最新工艺，以后可随摩尔定律上移)。超过这个区间，X86的产业链性价比优势不复存在，看看能组4P的CPU报价就知道了，这不单纯是技术成本的因素。

    Westmere和SNB都有AES-NI指令加速，能把加密解密速度提升好几倍，不知道有没有人测试过搭建VPN有没有给力？另外SNB集成GPU不知道能不能用来加解密、哈希运算等等，把一颗芯片的晶体管能力发挥到极致

  68. awei 于 2011-06-16 8:39 下午

    华为那帮人,能看懂这篇文章吗?

  69. 沙加 于 2011-06-16 8:54 下午

    68楼，你这也太xx了。首席曾经也是HW的~~~

  70. awei 于 2011-06-16 9:18 下午

    华为人不懂计算机,系统软件水平很烂的.

  71. awei 于 2011-06-16 10:00 下午

    中软的某些六级OS专家,和陈首席比起来,就是一驼大粪

  72. 阿土仔 于 2011-06-16 11:10 下午

    awei说话太不客观了

  73. multithreaded 于 2011-06-16 11:22 下午

    >另外SNB集成GPU不知道能不能用来加解密

    Please refer to SIGCOMM’10 paper on PackageShader:

    http://shader.kaist.edu/packetshader/

  74. 理客 于 2011-06-17 12:27 上午

    首席是顶级OS专家不错，但首席文章写得深入浅出，能看懂人是大把的，包括H，否则，我大宋就还在朝鲜时代

  75. 回楼上 于 2011-06-17 1:02 上午

    太小看我大宋了吧，华为里面的牛人无数滴

  76. awei 于 2011-06-17 1:21 上午

    华为还是不错的,值得尊敬的公司!
    我其实只是抱怨而已,
    我只是有些鄙视中软的那些 菜B! 早知道去wind river 玩linux去 !
    没有干部部的人发现我吧, 我可以告诉你工号的.

  77. ccNUMA? 于 2011-06-17 1:37 上午

    to multithreaded

    这个好像是通过PCIE连的，而且显卡好像很高端。SNB相比好处是与CPU更近，共享L3 cache，估计在时延上会有进步，但内置的HD2000/3000应该比N卡弱不少，不知道高丽棒子有没有计划测一把。或者期待啥时候Panabit再给力一把，树个X86做VPN的标杆

  78. Lucifer 于 2011-06-17 1:45 上午

    显卡是GTX480，平台是Nehalem-EP，SNB的好处是PCIe连接更简练，还有微架构，但是GPU能力方面可能不是很足够，共享L3这点可能是个优势，但是没有自己的显存，对主内存压力更大

    还有API的问题，有OpenCL支持的计划但目前还没有很好的实现，总的来说搞起来比较麻烦

  79. EX8200 于 2011-06-17 2:50 上午

    好文章！首席文章越来越软，越来越虚，越来越云了：P，让我们这些做底层硬件的民工感觉越来越无趣了

  80. 理客 于 2011-06-17 3:17 上午

    硬件对软件的影响不但大，而且后期修改成本巨大，一个架构师如果不能软硬通吃，一般都会在产品批量上市后遇到大trouble

  81. ccNUMA? 于 2011-06-17 5:14 上午

    确实显存和API是个问题，只能想办法把共享L3用好。看来只有等ivybridge了，据说内置1G显存。

    AMD的推土机好像CPU又太不给力，有些差

  82. 陈怀临 于 2011-06-17 3:35 下午

    华为的大多数弟兄是可爱的。华为的许多干部是脑残的。

  83. chinaslot 于 2011-06-17 6:29 下午

    大宋IT企业干部大多是脑残的。

  84. qingjiegong 于 2011-06-17 6:59 下午

    好文必顶。我一直看好vmware的虚拟技术，能够较好的解决工程化中的兼容和并行问题。
    需要注意到大部分做行业应用以及二次开发人员需要的是傻瓜机：不需要懂硬件，不需要知道操作系统和编译器就能把应用完成了。Computer Architecture、Oerating System、Compiler Optimizations对他们来说太高深了，当然我们也不能要求具备行业背景的人来了解这些事情。这就是现状。

    现在系统越来越复杂，维护成本呈几何级数的增长，我是深切体会到DEBUG plane的重要性了，了了几个简单的接口能够帮助快速的定位问题。。。。

  85. 陈怀临 于 2011-06-17 7:45 下午

    Debug Plane的提出和构建是本首席长期强调“系统必须量化才可以可控”的形而上学思想下的一个形而下的实现。

  86. nexus 于 2011-06-17 9:08 下午

    首席的归纳是对目前系统设计的看法，对高端大容量的通讯设备，我认为控制平面和转发平面的简化是5年内的方向，10年内应该向光交换发展；复杂的协议，无聊的特性，没几个人能读懂的debug输出，小于50ms的收敛要求，就像windows的目前状况，你不能确定它的最差反应，简洁设计应该在第一条，r2和r3有待评估。

  87. mips 于 2011-06-17 10:34 下午

    莫非这就是 传说中的葵花宝典

  88. 陈怀临 于 2011-06-17 11:53 下午

    我的所谓总结也没啥特殊的。我想了想。用处如下：

    ＊在公司内部PK的时候，可以拿我的观点做PK的证据之一。要好好利用之：－）

  89. 理客 于 2011-06-18 12:00 上午

    能化繁为简对目前复杂的高端设备可是葵花宝典，还没见过任何学术和工业表现

  90. mindtech 于 2011-06-18 7:43 上午

    首席精炼的总结，2~7点，切身体会。

    最近用tilera64核CPU做security tunnel forward，开始小包性能不到3Gbps，经过不断优化，偶然发现CPU和内存不再是瓶颈，只恨接口就只能20Gbps。

    优化过程就是对首席的2~7点总结的实践过程。

  91. multithreaded 于 2011-06-18 8:15 上午

    forwarding 本身达到20Gbps不是个难事。关键是测试的方法？ 比如：

    1。The routing table size? 100K vs。 1M routes?

    2. The packet trace characteritics such as how many destination IP addresses are involved?

    以上两点可以测出系统对CACHE的优化程度。

    ssh 能达到20Gbps很了不起，不知是否用了专用的硬件加速器。

  92. multithreaded 于 2011-06-18 8:26 上午

    〉好文必顶。我一直看好vmware的虚拟技术，能够较好的解决工程化中的兼容和并行问题。

    请思考一下我们为什么要并行？

    在虚拟技术下，如果10个VM才顶一个physical machine, 我宁愿不要它！

    I think VM is for resource efficiency not for achieving high-performance.

  93. 理客 于 2011-06-18 2:12 下午

    table的容量差异很大时，对技术实现的要求差异也非常大，1M的路由查表用软件实现，没听说过能有好性能的。

  94. 胡不才 于 2011-06-18 5:35 下午

    我不是学物理，问个弱弱的问题，量子力学里面有测不准，是不是上到20G，100G也测不准了？

  95. 姚零二四 于 2011-06-19 5:31 上午

    呵呵，这个不是剑法，而是贱意，抱歉剑意。一些民间的土匪们能理解的可能真不多。借问一下，华为一些系统设计土匪们多吗？

  96. 理客 于 2011-06-19 7:48 上午

    如果一个大公司的大部分设计人员连这个都不能理解，这个公司根本就不能在技术公司里立足，大公司的关键问题不单是理解，更难的是如何通过组织管理和文化，真正贯彻执行，并且固化，到达无为而治的最高境界，这是最令人头疼的问题，这也是截拳道大家都知道厉害，可还是只有李小龙练成，而基本再无人达到Bruce Li的普通水准的原因

  97. Sting 于 2011-06-19 6:40 下午

    对某司来说，懂这些并不困难，难点在于如何把这个思路贯彻下去，如何让技术的决策回归技术本身。

  98. 沙加 于 2011-06-19 7:47 下午

    胡不才果然不是学物理的，量子力学的测不准原理跟流量转发的测试是两码事。通俗点说，测不准的原因是测量本身会对量子运动矢量产生影响。

  99. zcgen 于 2011-06-25 9:53 下午

    再次拜读大作，慢慢品味

  100. kernelchina 于 2011-06-27 6:51 上午

    MapReduce如何应用到通信系统上，能再详细一点吗？还有就是MapReduce理解为MIMD，这个是不是有点太虚了？多核本身就是MIMD，感觉和MapReduce没什么关系啊。

  101. tree 于 2011-06-27 7:20 上午

    做领导的就是MapReduce

  102. hh 于 2011-06-28 7:48 上午

    华为的大多数弟兄是可爱的。华为的许多干部是脑残的。

    =====

    首席就是首席，几个月就看出问题来了
    我愣是耗了几年，终于被华为干部的代码行数主义以及一些次要的问题彻底搞崩溃，出来后干脆转行了….

  103. passer-by 于 2011-06-29 8:02 上午

    其中提到计算能力、存储能力要离数据近。为何现在计算能力和存储能力在从终端向云转移呢？终端不是离数据最近的地方？还是最远的地方？或是既是最近也是最远的地方？

    技术门外汉，倾情帮顶之余呓语一二，首席见谅！

  104. washion 于 2011-06-29 6:45 下午

    首席，请释疑。

    sandy bridge有QPI支撑cc-NUMA
    XLP832有ICI支撑cc-NUMA
    tile有什么可以支撑cc-NUMA？？靠pci-e？目前太不靠扑了。tile-GX是否给力？

  105. 陈怀临 于 2011-06-29 7:28 下午

    Peter，你在哪里？？？出来回答问题。。。。Tile目前还不支持吧yet。支持ccNUMA对功耗还是很要求的。

  106. Sting 于 2011-06-29 9:06 下午

    tilera的架构本来就类似cc-NUMA，远程节点的cache都可以慢慢路由过去，只是性能极低而已；把他们路由的功能扩展一下，支持多CPU互联其实并不困难，至于可用性，呵呵，gone with the wind

  107. washion 于 2011-06-29 9:20 下午

    Sting同学，请注意概念，cc-NUMA和Tile的dynamic distributed cache完全不靠扑嘛。

  108. Lucifer 于 2011-06-29 10:59 下午

    tilera就是cc-NUMA嘛……核与核就是直接链接的，什么总线就不好说了

  109. Sting 于 2011-06-30 12:08 上午

    如果说错了，请多提意见；

    tilera是否支持多CPU之间的高速互联我还真忘记了，也懒的查资料了，印象中是没有的；不过如果真的有，或者你定制一个，其实对tilera来说应该不算什么；重点是tilera在本处理器里支持cc也是有n种方案，有软件的，也有硬件的，好像还有独立核去做的，道理都在他们核间的那个switch上；需要支持多处理器后的cc，我感觉也就是把他们核间cc的方案扩展一下就好； 明白我意思否？

    另外，DDC好像是本地核用其他核的cache的方案吧，cc的方案好像不是这个名字，太久了，好多细节忘记了，抱歉

  110. 陈怀临 于 2011-06-30 12:12 上午

    ccNUMA通常说得是Chip2Chip，而非core2core。上次与其CEO 谈，应该还没有yet。当然不难。。。如果power budget，clock等能做得下来。。。

  111. Lucifer 于 2011-06-30 12:48 上午

    不错，通常是chip2chip。对于tilera这样的mesh结构来说，把核放多一些就行了，不需要多芯片ccNUMMA，不过cache的一致性运作也很类似就是了。tilera多芯片的话，现在除了搞的更复杂之外，还不一定有很明显的效果。当然以后难说了

  112. washion 于 2011-06-30 2:22 上午

    tile现在的CC都已经可以让某些同鞋崩溃了。如果再上个C2C互联。我还真不敢想它在片间的CC会花多少Cycles.

  113. Sting 于 2011-07-01 1:49 上午

    tilera好像从来不是很在乎这个会花多少cycles，花的多，说明你没有用好，他的东西永远都是好的，扫x86无数条街的

  114. 狐说 于 2011-07-17 11:12 下午

    数据库社区现在有对MapReduce的大讨论，批判的人不少。。。。

  115. chinomango 于 2011-08-03 11:40 上午

    我是华为的小兵，新手，我对干部们的感觉是比老美实在。我对业界产品知之甚少，只看了一个seamicro的SM10000－64，那里用了双核双线程ATOM N570, fabric是1.28Tb/s，我想了一下要是我做它该如何做，
    首席强调的硬件不错，不过到最后恐怕是软件来判决，因为这些新硬件都要新软件，软件开发周期更长。
    我的理解分布式处理是个架构，每个单元还是要强些好，不然互联会有许多级fabric会复杂到你只想仍掉它。当然还有就是软件资源。这可能是首席推荐x86的原因。要光说硬件，32核的MIPS64可能都比x86强。我觉得网络的东西用局部紧耦合是恰当的。
    ccNUMA不大懂，觉得是很自然的一个实现，不是革命性的。
    我期待下一代有革命性的改变，去掉目前多层次多转发的东西，直接一些。
    目前是clouds，还看不见曙光。

  116. chinomango 于 2011-08-03 11:56 上午

    “为何现在计算能力和存储能力在从终端向云转移呢？”因为云能忽悠。
    请问SNB是啥？比PCIe好的互联标准有吗？（网口除外）

  117. allenogz 于 2011-08-04 6:54 上午

    个人不太赞同首席的观点
    我认为 X86会进入的CT的原因是 IT化，白菜化，所谓的可获取性，包括X86系统上的一切软件

    但是ARM，MIPS等RISC架构的CPU不断地发展，正在蚕食IT上的X86的市场。从最近的xpad蚕食笔记本市场可以看到

    而且通信这边有个问题是功耗问题，随着流量的不断激增，性能的不断提高。X86架构会更早面对功耗这个问题。
    个人认为ARM based CPU会在通信领域形成领导局面。 虽然现在ARM based CPU在RAS方面还不行