给力吧，x86（2）——12月13日测试记录

network

给力吧，x86（2）——12月13日测试记录

系列内容： 11月10日测试记录（Atom N270） 12月13日测试记录（Atom D525） 1个月前的测试让人见识了Panabit这一年来的进步，也看到了x86平台在通信领域的潜力。不过，上次的测试并不细致，1个N270平台也不能代表一切，所以我和Panabit团队达成一致，在接下来的一段时间内以细水长流的形式保持一系列测试合作。 为了让测试不那么无聊，我打算时不时地换种形式娱乐一下。比如这次的测试就是一道问答题，我提出了一个性能目标——2个千兆口64Byte裸奔线速，看看PanaOS用什么档次的平台能够达到。插一句，我从来不觉得裸奔没意义，相反认为意义重大，因为转发能力是一切的基础。并且曾经听几个国内安全厂商的朋友说过，他们做产品规划的时候都用这个小包裸奔2G的数字作为千兆低端和千兆中端的分界线。 看看Panabit团队拿了一台什么样的设备来应战：汇尔（HOLL）科技IEC-516P，Atom D525/1G RAM/i82574L x 6，一台看起来很实用的1U Box。从PCB上看，应该可以有两组硬件Bypass，还有3个SATA和一个PCIe 1x接口。Atom，难道这次又用它来挑战IT人的传统认识？不费脑子了，先测了再说。 测试项·配置帧长度 2个GE做1组桥（100%=2Gbps） 6个GE做3组桥（100%=6Gbps） 吞吐 平均延迟 吞吐 平均延迟 64 Byte 42.87% 19 us 34.96% 65 us 128 Byte 53.25% 18 us 43.76% 1440 us 256 Byte 67.65% 20 us 53.91% 1807 us 512 Byte 82.36% 37 us 59.76% 3514 us 1024 Byte 93.23% 73 us 59.23% 585 us 1280 Byte 96.00% 60 us 59.71% 112 us 1518 Byte 100% 64 us 61.18% 197 us 测试结果里隐藏了太多的玄机，比如2个GE做一组桥的时候，D525平台下的性能怎会和上次的N270基本一样？比如6个GE做3组桥的时候，平均延迟作何解释？再比如，多路桥的大包测试结果和N270基本一致，瓶颈又出在哪？ 不过，和整机64Byte吞吐量2.1Gbps（3.12Mpps）的结果相比，一切都是浮云了。一个在x86工控机中价格优势最明显的BOX，裸奔出这样的性能，还真是头回得见。立志进入嵌入式领域的英特尔应该注意了，在Wind River Network Acceleration Platform还没有成功案例之前，PanaOS也许是x86平台上性价比最高的选择，是不是考虑给Panabit提供些特别支持呢？ 从我们的角度看，Panabit自诞生以来一直保持着技术和模式上的双重创新，得到市场认可并成功地活了下来，对整个行业都有着重大的意义。说颠覆还太早，但它确实已经成为国内通信安全圈中不容忽视的新兴力量，有着相当不错的发展前景。基于此，我们团队一致决定授予Panabit 计算机世界2010年年度创新奖。

(7个打分， 平均：3.86 / 5) [td]

工具箱
本文链接 | 邮给朋友 | 打印此页 | 47条用户评论 »



雁过留声

“给力吧，x86（2）——12月13日测试记录”有47个回复

• 给力吧，x86（1）——11月10日Panabit测试记录 : 弯曲评论 于 2010-12-20 7:28 上午
  [...] 2 12月13日Panabit测试记录（Atom D525） [...]
• Panabit 于 2010-12-20 8:17 下午
  我们后续将会以细水长流的方式：
  1）对现有不同芯片组的IPC平台做一个综合评估，比如芯片组整体网络IO吞吐能力，单槽吞吐能力以及和CPU Core的扩展关系；
  2）对现有不同型号的网卡的吞吐量和小包transaction速率做评估，比如82573/82574, 82571, 82575, 82576, 82580, 82598, 82599等。
  我做这个事情的目的不是为了宣传什么（不相信的人可以略过），主要就是为了展现一下最贴近X86硬件性能的一面，在这个过程中，我们也希望自己能不断的进步。也希望这些测试和评估能给其它的兄弟厂商提供一些参考。
• Panabit 于 2010-12-20 8:23 下午
  希望各个IPC厂家来给我们提供支持，呵呵。
• 路上 于 2010-12-20 9:51 下午
  毛工的技术水准 有提高了一大步了
  慢慢来 毛公
  特此过来围观 纯支持下
• Paul Huang 于 2010-12-20 11:22 下午
  毛生加油！
• 大脸猫 于 2010-12-20 11:28 下午
  自娱自乐
• Panabit 于 2010-12-20 11:40 下午
  呵呵，先自我乐，然后再让大家乐，不亦乐乎？
• Panabit 于 2010-12-20 11:40 下午
  多谢Paul!
• Will Chie 于 2010-12-20 11:54 下午
  很强大的说，首席弟子实力不容小觑
• 老韩 于 2010-12-21 12:18 上午
  要的就是自娱自乐，自己都没乐，怎么能指望大家同乐呢
• 加菲猫 于 2010-12-21 4:10 上午
  2）对现有不同型号的网卡的吞吐量和小包transaction速率做评估，比如82573/82574, 82571, 82575, 82576, 82580, 82598, 82599等。
  期待ing. 特别是后面两个:82598/9~
• Panabit 于 2010-12-21 4:27 上午
  请静待一下，呵呵，春节前我们先将一些软件山的准备工作做好。
• liang 于 2010-12-21 6:26 上午
  裸奔!!!,no freebsd?
• Panabit 于 2010-12-21 6:29 上午
  裸奔的含义就是不跑Panabit业务引擎，相当于一个纯桥。
• Will Chie 于 2010-12-21 6:52 上午
  to Panabit，
  求教，什么是软件山？
• Panabit 于 2010-12-21 6:53 上午
  Sorry, 那个是笔误，应该是“软件上”，
• liang 于 2010-12-21 7:46 上午
  跑到线速的瓶颈在那里?主频?内存访问延迟?
  毛公赐教
• 加菲猫 于 2010-12-21 5:00 下午
  — 跑到线速的瓶颈在那里?主频?内存访问延迟?
  个人感觉在网卡收发的工作机制上, pcie带宽是充裕的, 如果是裸奔, 数据包基本上是在高速缓存上被转发的, 故内存带宽也不存在问题.
  不知这样考虑对不对?
• Panabit 于 2010-12-21 5:51 下午
  从带宽角度而言，内存并不存在瓶颈，主要还是和网卡有关。
• liang 于 2010-12-21 5:54 下午
  panabit:裸奔的含义就是不跑Panabit业务引擎，相当于一个纯桥。
  如果问题在网卡收发的工作机制上,是驱动的问题,还是协议栈?
  提高主频,或降低主频会有多少影响
• Panabit 于 2010-12-21 6:32 下午
  是整个系统架构的问题，CPU在任何时候，都不应该是瓶颈，所以和主频关系不大。
• 阿土仔 于 2010-12-21 6:46 下午
  如果裸奔，和panaos有什么关系呢？
• 老韩 于 2010-12-21 7:08 下午
  驱动和协议栈都在PanaOS进程里，只不过数据流不再走DPI了。
• 阿土仔 于 2010-12-21 11:15 下午
  裸奔都走了什么流程呢？查流表吗？报文解析吗？等等。。
• gaohl 于 2010-12-22 4:07 上午
  D525千兆小包跑到43%，请问是多核跑起来了呗？
• Panabit 于 2010-12-22 4:19 上午
  物理上还是只用了一个Core。
• 理客 于 2010-12-22 5:00 上午
  此类性能优化，一般先裸奔，就是什么都不做，收到就发出去，从而得到系统最大的performance，以此为基准，增加业务，一步一步优化，就比较容易知道瓶颈在哪，应该在哪下功夫。为了更容易监控和发现性能瓶颈，我想PANAOS应该有一套内嵌的监控系统，在增加新的业务功能时，通过此系统检测性能瓶颈，以免每次都要手动的做很多重复工作
• Panabit 于 2010-12-22 5:09 上午
  理客，你一说就到点子上了，呵呵。我们是这样想的，先解决裸奔时候的性能问题（这个不光可以解决性能问题，还可以用来评估硬件），然后通过一步一步增加功能，来评估由于额外访问内存对性能的影响。性能评估和优化的前提就是要有一个基准系统对比，裸奔时候的结果可以从某种程度上看着基准性能。
• Panabit 于 2010-12-22 6:23 上午
  狗日的百度，在我们决绝他们的推广要求后，又屏蔽我们了。
• MIPS 于 2010-12-22 6:50 上午
  INTEL又何尝不是这样呢，这就是垄断的力量，Panabit在不断推广INTEL的时候其实，也在利用他们的垄断力量。
• roccen 于 2010-12-22 8:16 上午
  请教Panabit/老韩二个问题:
  1、双接口吞吐达到42.87%极限的时候，CPU占用率达到多少？单接口进再环回出去的吞吐量，或者A接口进B接口出的单向流量可否达到100%？
  在下最近恰也正在研究Linux下用户态直接收发包效率的改进问题，发现用类似本文裸奔的方式来测试整机性能时，Linux NAPI polling+中断的调度机制可以让多队列并发收包效率提到足够高，但始终无法让单队列的收包速率达到(1.5Mpps)线速。不知FreeBSD下的纯polling能否做到这一点？
  2、裸奔测试的话，在内存带宽没有瓶颈的情况下（1-2个Gbps应该没有什么内存瓶颈吧）,NIC ring buffer的填充速率是性能的最重要因素，即吞吐率和pps接近正比，那么，为什么64B时都可以做到43%，而128B时才仅仅增加了10%？ 是否整个裸奔处理路径上存在内存拷贝或者全报文范围内的随机内存访问？
• Panabit 于 2010-12-22 8:41 上午
  回楼上：
  1）不可能100%，这是由网卡决定的，82574的吞吐率（或者说TRANSACTION速率）没法做到64bytes线速，目前做到线速，只有82571,82575,82576,82580可以做到；
  2）64B和128B不成比例增加的问题，在所有的X86平台上都存在，我也没搞明白是什么原因，真希望找个Intel的大拿问问。
• liang 于 2010-12-22 5:53 下午
  linux什么都不优化，默认情况下裸奔也只有20%不到
• 天外有天 于 2010-12-22 6:12 下午
  软件在内核态还是用户态？
  没有使用linux的协议栈吧，
  直接从网卡收发包，自己跑的协议栈？
• 陈怀临 于 2010-12-23 6:07 下午
  这些所谓的Zero-Overhead Linux的东东，估计现在都差不多。
  我现在也不知道大弟子是如何做的了。但我认为做多核系统最后的秒杀就在与：Cache的最佳利用。
  目前我就没看见不糊涂的。。。
  我算一个比较明白的，说良心话。
  在有L3的CPU上，如果能把cache充分利用好。大事就成了。
  许多读者对我大弟子的性能，sorry，我大弟子做的系统的性能，非常跌眼镜，然后天天被自己的老板抽。或者被强迫对着任选，sorry，毛选，宣誓。其实都不好使。。。
  其实要好好想想cache的事情。。。
  当然，最好的办法是：有事找首席。。。
• Panabit 于 2010-12-23 6:36 下午
  诚如首席所述，一切的关键都是CACHE，TLB等等呢个，这些在实际流量中的表现更是如此。多核中要尽量避免CACHE POLLUTION、CACHE乒乓、伪共享这几个CACHE杀手。
• 陈怀临 于 2010-12-23 6:41 下午
  大弟子，你就点到为止了。。。希望明白的人能明白。
  我这几天写一个Page Coloring的文章吧。也算暗示和帮助我大宋一些公司吧。。。
• xiaosuo 于 2010-12-23 7:12 下午
  这个paper详细：http://lwn.net/Articles/259710/
• 打酱油的 于 2010-12-23 7:55 下午
  intel Q6600，82576，64bit，10Mpps，给力吧。
  只用了一个core
• Panabit 于 2010-12-23 8:32 下午
  回楼上，挺给力的！！！回38楼，那个PDF真好，拜谢了！
• Panabit 于 2010-12-23 8:53 下午
  39楼：加入我们的“给力，X86“系列吧，人多力量才大。
• 打酱油的 于 2010-12-23 9:01 下午
  一直就坚持抱粗腿的理念，紧跟x86阵营
• 打酱油的 于 2010-12-23 9:03 下午
  更正：64byte
• Panabit 于 2010-12-23 9:12 下午
  哈哈
• roccen 于 2010-12-23 9:33 下午
  39楼，是几个82576并行出10Mpps的？ 一个82576上用了几个队列？ 单流单队列的最大吞吐能做到多少？
• Panabit 于 2010-12-23 10:37 下午
  我估计他应该是4个82576 PORT，这个最主要的是芯片组，如果是一个Core的结果，多队列，，单队列关系不大。
• Panabit 于 2010-12-24 9:02 下午
  Sorry,应该是4个82576 CHIP。