以下是演讲实录：

程传胜：各位嘉宾下午好，正式开始前我先做下自我介绍，我叫程传胜，来自百度系统部，在百度负责交换机和光模块的硬件，同时在ODCC testbed项目组担任项目经理，今天我分享25G网络和测试运用。

首先我们看为什么选择25G作为百度下一代主流速率，一句话总结：25G更高效，扩展性更强，性价比更高。虽然从速率来看40G比25G更快，但我们知道目前的40G是通过4×10G实现的，比25G落后一代。假设某个交换芯片有128个设备是lan的话，25G速率下整个交换带宽和交换能力是大的，同时25G速率下连接服务器的数量和交换能力也是最优的。第二，25G可以更方便的升级到50G和100G，25G技术出现之前，100G是通过10×10G实现和应用，现在对于25G技术来讲，4×25G就能实现100G.如果使用PAM4电平，单25G Lan就能实现50Gb/s的数据传输。

第三是单Gbit的Consumption和Cost相对10G都有下降。先说Consumption功耗，我们有做过对比，交换机都插满AOC和光模块，蛇形打流满载情况下，25G交换机的功耗大约是10G交换的1.5倍。这样看25G的Consumption/Gbit是10G的0.6倍。再看Cost成本，我们拿预计今年末交换机加AOC和光模块的成本对比，25G系统的成本大约是10G系统成本的2倍。所以25G的Cost/Gibt是10G的0.8倍，我们相信随着明年25G的大量应用，这个数字还会降低。

Consump功耗，满负载情况下25G交换机的功耗大约是10G交换机功耗的1.5倍。

第二个因素是25G生态的成熟。25G交换机在数据中心的应用是实实在在的工程实践应用，所以我们需要25G生态的上下游各个环节都成熟，产品量产，2015年下半年百度决定做25G交换机的时候我们了解到25G相关的工程技术已经成熟应用或者即将成熟应用，当时有比较好的外界条件。以上两个是选择25G的外在条件，下面看用户需求这个内在条件，对百度来讲，百度为什么把现在的网络主流速率从10G升级到25G，第一和第二原因都有。去年开始线上某些Hadoop集群的数据流量都有达到万兆情况，百度云和百度AI的快速发展，对网络延时和带宽的要求越来越高，升级到25G也有为带宽做准备的意义。

基于以上原因，百度选择25G作为这一代的主流速率。ODCC对25G的研究开展始于2015年，2015年10月成立网络组，同时提出若干项目，其中一个项目是25G交换机项目，我担任项目经理。2016年9月ODCC峰会发布25G TOR交换机规格书V1.0版本。这个规格书详细给出了ODCC推荐的25G TOR交换机的硬件架构和核心设计。值得一提的是这个规格书给出两种不同的规格，供开发者参考。2017年是25G在ODCC爆发的一年，2017年4月份我们发布了25G AOC和100G开放光模块技术规范。同年5月成立25G TestBed测试项目组，8月发布25G系列测试规范。线下多次举办了沙龙沟通和工作组会议，在座的会员单位有的参加过。

百度25G TOR设计原则。首先是解决10G交换机痛点，第一个痛点是软件硬件没有归一化处理。现在百度线上万兆交换机有三个厂家，在CPU使用上，有的厂家使用MIPS架构CPU，有的使用PowerPC架构CPU，同时硬件系统驱动也没有管控。CPU架构和硬件系统不统一造成研发百度OS的时候要分别适配，出现一个现象，三款万兆交换机是用三款百度OS的image（音），这给我们的人力和软件版本的管理造成了一定的困扰。第二个是I2C问题。I2C总线在交换机系统中有广泛的应用，AOC、光模块、PSU、FAN的管理，大都是使用I2C总线。对于可插拔的模块来讲，插拔模块时，一定概率会出现I2C总线锁死，如果没有对此路I2C总线做隔离，进而会影响到整个I2C总线。导致I2C总线不可用，给运维带来一定的不便。第三个痛点是诊断手段不够丰富，问题记录上报比较少，线上的交换机如果发生死机故障，我们不能进行远程诊断，也不能进行远程恢复，我们必须通知现场的外包手动下店进行恢复，对我们人力资源也是一个浪费。交换机如果发生重启故障的话，我们对重启类型和重启原因的记录也比较少，问题的故障预警也没有实现。

针对以上痛点，我们制定25G TOR的时候采取了全程参与、深度定制的方法，首先百度会制定详细的硬件规格和核心设计方案，百度依靠我们自己的软件设计能力和硬件设计能力，给出一个详细的百度想要的交换机的规格，通过我们的设计解决和避免万兆交换机存在的痛点，也能实现我们自己的一些想法。第二，对关键器件我们统一管控，我们选定厂家和型号，必须使用我们选定的关键器件，这样做的目的一是有利于软件的归一化，二是有利于硬件质量的控制。TOR交换机在研发过程中我们全程参与，这样做的目的是了解我们研发的过程，同时确保我们的规格书能执行到