给力吧，x86（1）——11月10日测试记录

作者老韩 | 2010-11-25 23:28 | 类型互联网, 网络安全, 通讯产品 | 101条用户评论 »

分享到：新浪微博腾讯微信开心人人 Live Digg FB Twitter

系列内容：

11月10日测试记录（Atom N270）
12月13日测试记录（Atom D525）

测试环境

DUT：DIY的Panabit，其中

硬件：Lanner FW-7530，Atom N270/1G RAM/4xi82574+2xi82541。这小盒子很不错，我喜欢。Fanless的，顶盖就是散热片，连续测试下来温度也不会超过55度，精品，精品。就是太贵，国内还基本买不着。
软件：Panabit 10.10专业版。10000个IP监控/1000000并发连接的License。利用Atom的HT，一个vcpu跑管理，一个vcpu跑IO+业务。

测试仪：Spirent Avalanche 2900 / IXIA 1600T

测试结果

功能全开，无流控策略

测试项·配置帧长度	2个GE做1组桥（100%=2Gbps）		4个GE做2组桥（100%=4Gbps）
测试项·配置帧长度	吞吐	平均延迟	吞吐	平均延迟
64 Byte	41.19%	24 us	22.28%	34 us
128 Byte	54.42%	24 us	37.37%	38 us
256 Byte	67.65%	24 us	48.08%	42 us
512 Byte	82.10%	37 us	52.35%	42 us
1024 Byte	92.02%	76 us	53.38%	54 us
1280 Byte	95.58%	64 us	55.37%	58 us
1518 Byte	100%	68 us	56.92%	68 us

功能全关，裸奔

测试项·配置帧长度	2个GE做1组桥（100%=2Gbps）		4个GE做2组桥（100%=4Gbps）
测试项·配置帧长度	吞吐	平均延迟	吞吐	平均延迟
64 Byte	44.22%	28 us	37.50%	28 us
128 Byte	53.63%	21 us	43.54%	37 us
256 Byte	67.65%	25 us	48.43%	30 us
512 Byte	82.10%	40us	52.36%	40 us
1024 Byte	92.07%	70 us	53.77%	53 us
1280 Byte	95.59%	56 us	55.04%	69 us
1518 Byte	100%	94 us	56.49%	75 us

功能全开，无流控策略：每秒HTTP最大新建连接数 90014TPS

Avalanche2900只有4个电口，自环后直接接在DUT的4个口上，配置不变直接打，得到100000的结果，验证为测试仪性能瓶颈。DUT的CLI下把拆链接Timeout时间置为0，测的90000左右稳定值，测试仪取样峰值90014。

瞎想

Why除了64和128，DPI引擎开和关时测得性能基本一致？
2口和4口吞吐能力基本一致，Why一些国内厂商的产品吞吐能力会随接口数增加而降低？
2口和4口的吞吐量结果没有明显的倍数关系，why？
4口时吞吐量没有像2口那样逐渐递增到100%，而是从512开始基本稳定，why？
跑流控都这性能了，跑标准的状态检测防火墙呢？？
和原来在ce600、ce900+915的平台相比，貌似只要优化的好，没有cache miss之类的，顺序执行、高主频的Atom性能更高？
N270带4个GE电口的盒子，国内工控厂出货也就RMB 1K吧。Panabit跑出这性能来，要断很多人活路了。给力！

Atom做安全到底行不行，行到什么程度，Panabit以及很多厂商都给出答案了。前不久Intel又发布了带FPGA的Atom，貌似也认可了这一点。只不知新的Atom会不会又是一个80579呢？

摘抄一句新闻稿：英特尔公司推出的六款英特尔® 凌动™ E600系列系统芯片（研发代号“Tunnel Creek”），能帮助客户轻松设计差异化定制产品，加快产品上市速度。今天，英特尔公司进一步发布了可配置的英特尔凌动处理器 E600C 系列，它将英特尔凌动E600 处理器和 Altera* 现场可编程逻辑门阵列（FPGA）融入了一个封装内。

关于这个E600C，以及传说中Intel倡导下，风河6Wind推出的基于x86的高性能网络软件基础架构，欢迎大家发表见解。

补充：猛击此处下载所有测试结果（PDF）：4口带业务，4口不带业务，2口带业务，2口不带业务，新建

(1个打分，平均：5.00 / 5)

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

雁过留声

“给力吧，x86（1）——11月10日测试记录”有101个回复

droplet 于 2010-11-25 11:43 下午

检查一下结果，有没有写反了。裸奔和全开，结果很诡异，还是我理解的裸奔有问题？TPS要看处理的难度了，没有syn-check, sequence check, tcp state machine，等等，很多因素影响这个。
Lucifer 于 2010-11-25 11:54 下午

x86还有潜力可挖那，就靠做软件的人了
yfydz 于 2010-11-26 12:21 上午

支持路由么？查路由对TPS影响不小，如果只是定死的一进一出的桥的确省事很多
走过路过 于 2010-11-26 12:30 上午

我想问一句：测试用的panabit是仍建构在freebsd系统上还是到linux系统上边了？
老韩于 2010-11-26 12:43 上午

回1楼，我整理数据时也挺奇怪的，但是IxLoad的测试结果就是这样的。

我个人觉得瓶颈可能在82574，或者945GMS+ICH7上。具体的，还得请Panabit兄亲自解释了。
ABCD 于 2010-11-26 1:10 上午

带宽问题，应该出在ICH7和945之间的DMI带宽上。82574芯片本身不存在问题。82574大包是基本上可以做到线速的。
Panabit 于 2010-11-26 1:12 上午

让楼上的兄弟抢先了！多谢！
老韩于 2010-11-26 1:14 上午

瞎想的那些请Panabit兄指点下
Panabit 于 2010-11-26 1:39 上午

1.Why除了64和128，DPI引擎开和关时测得性能基本一致？

——> 我觉得这个应该是总线带宽到极限了；

2. 2口和4口吞吐能力基本一致，Why一些国内厂商的产品吞吐能力会随接口数增加而降低？

——> 这个不好比，可能和软件架构有关系，也和软件实现的功能有关系。流控就是一个桥，在很多方面都可以省掉，只要DPI引擎做得好就OK了。

3. 2口和4口的吞吐量结果没有明显的倍数关系，why？

——> 系统整体性能是这样的，就是说系统硬件小包的IO TRANSACTION能力是够了，但是软件还是跟不上；裸奔的话，肯定就不是这个结果。

4。 4口时吞吐量没有像2口那样逐渐递增到100%，而是从512开始基本稳定，why？跑流控都这性能了，跑标准的状态检测防火墙呢？？

——> 这个是总线带宽到极限了。如果仅仅是简单的状态检测防火墙，估计压力不大，但是如果将TCP PROXY等加上，因为要计算CHECKSUM，所以会增加一次CACHE LINE 的WRITE操作，应该对性能会有一些影响（我估计在5%左右）。查路由操作时再FIRST PACKET就能完成的，其实关系不大。
老韩于 2010-11-26 1:44 上午

那么在下一代Atom上应该能解决总线带宽的问题了？记得D系列Atom平台没有独立北桥了吧
Panabit 于 2010-11-26 1:56 上午

我这里有一个D525的，我待会儿看看。
清华土著 于 2010-11-26 2:37 上午

感觉是在测防火墙，没体现panabit的识别性能。

APP-ID是关键的关键！
Paul Huang 于 2010-11-26 2:44 上午

Panabit：能联系一下我吗？我的QQ：1123514826
MSN:congxinzailai1982@hotmail.com
Panabit 于 2010-11-26 3:05 上午

回4楼：Panabit运行在自己的Panaos里，而这个Panaos运行在FreeBSD上，从FreeBSD kernel角度看，它是FreeBSD的一个process.
网路游侠 于 2010-11-26 5:40 上午

Panabit基于FreeBSD的东东，这样测试的话，貌似就像是测试防火墙了，这东西对于协议识别等，窃以为更重要一些。
老韩于 2010-11-26 5:51 上午

游侠兄，协议识别是以前测试过的东西，我不会每次都测的。就像上次别人质疑山石的防火墙测试，经过几次以后我就不会再测海量策略和单条策略的性能区别了。
以前我也不太愿意用UDP测的，但是Panabit介绍说UDP包在它的DPI引擎里走的基本是最长路径，并且每个包都要检测，所以就一直用2544跑了。
liang 于 2010-11-26 6:17 上午

panaos 是real time fressbsd?
Panabit 于 2010-11-26 6:24 上午

会楼上：不是的，Panaos和FreeBSD一点关系没有，就是一个在FreeBSD上跑的Process。
playmud 于 2010-11-26 7:16 上午

x86的性能远不止这么低
Panabit 于 2010-11-26 7:31 上午

是的，X86性能还需要发掘。我们现在正在开发第三代Panaos，完成后，应该可以将X86的网络方面性能充分挖掘出来。
liang 于 2010-11-26 7:54 上午

Panaos是跑在KERNEL层的PROCESS?
panabit的软件跑到其他cpu上否?是否与atom的
cache较大和intel ht有关系?
试想如果arm11 1.6Ghz,512K CACHE,AMBA TO PCIE结构会怎样?
liang 于 2010-11-26 8:01 上午

从硬件结构上,是否这种测试结果反映pcie dma能力,如果主频降到1Ghz,64k是否同样结果?希望回答，谢谢！
Panabit 于 2010-11-26 8:04 上午

liang兄弟，Panaos不是跑在KERNEL里，是跑在User Space，跑在KERNEL里没什么意思，开发起来也是胆战心惊的。Panabit目前就能跑在X86上，其它平台还不行的，我现在没时间，有时间弄到龙芯上玩玩。另外，你说的有道理，裸奔其实就是反映硬件DMA的能力的，但是毫无疑问，和CPU主频和内存也是有关系的。
陈怀临 于 2010-11-26 8:41 上午

我与小韩昨天晚上快12点发出的。一觉醒来，几十个评论了。。。牛呀。

弯曲评论的精华不是文章本身；而是评论。
老韩于 2010-11-26 9:19 上午

为啥全都抱着Kernel不放呢？特别的不理解。这就是所谓的历史包袱吧
删吧于 2010-11-26 12:25 下午

首席，优秀评论也该发股票那。
liang 于 2010-11-26 4:41 下午

panabit ?您的软件优化是系统结构针对应用的改进,还是语法的优化,甚至用汇编,用sse指令?
我是硬件工程师,对软件细节不了解,但64小包,2个GE做1组桥情况,减少os开销,是否有线速可能?
阿土仔 于 2010-11-26 5:37 下午

吞吐量测试发的是一条流吗？都经过了什么处理？单发一条流是否处理都被cache住了？如果发很多条流，不全部cache住的性能是如何？
Panabit 于 2010-11-26 7:21 下午

会楼上，我也想知道这个结果。如果是大容量的流，那么主要和下面因素有关系：
1）TLB MISS概率，这个非常非常关键；
2）HASH冲突率，将HASH表设计好，可以尽量避免；
老韩于 2010-11-26 10:52 下午

To 27：啥硬件平台跑啥业务？x86裸奔的化，太可能了。
To 28：您说的是，下次我会一定多加些流。这次应该是4条流测的。
阿土仔 于 2010-11-26 11:17 下午

对于CPU做为主处理器的系统都存在这个问题，单测试几条流甚至很多条流都能够被其cache系统cache住，这样测试数据和实际数据（很多很多很多流）的时候会有差别。特别是对于查表次数较多的处理。对于高性能的处理器，外部缓存的带宽是很重要的瓶颈，由于DDR有TRC的时间，因此操作次数是有限制的，这也是为什么很多NP都外挂QDR或RLDRAM的原因。不知目前高端的处理器采用了哪些技术能够优化。
droplet 于 2010-11-27 4:29 上午

HASH怎么优化，空间换时间？
Panabit 于 2010-11-27 5:37 上午

拿CPU CYCLE换内存延迟。
liang 于 2010-11-27 6:01 上午

rtos会好些?
virtex7 于 2010-11-27 7:15 上午

fpga开发人员，os爱好者问几个问题，请大家指点一二：

“利用Atom的HT，一个vcpu跑管理，一个vcpu跑IO+业务。” panabit说了，panaos只是一个user process，那我觉得这样做的话，可能就是开了ht，用了cpuset的方法，亲和性，但bsd的调度算法虽然对ht有感知，但不一定开了ht性能就好，不知道ht对协议识别有没有好处，对网络性能影响几何？（不熟悉atom的微架构）

“为啥全都抱着Kernel不放呢？特别的不理解。这就是所谓的历史包袱吧” 上下文开销有时候也需要考虑的，panabit也说了，panaos只是一个user process，所以大家才有些疑问，从中断来了包，到包到application，如果不优化path，还是有那么几次拷贝的，如果要减小这些，内核必然得配合user space来改，当然在20G吞吐量内，靠cpu把包拉走也可以，intel的chip本身也很强悍的。要做的很好的话，涉及硬，软中断平衡等等，类似google的两个linux patch， bsd机制还不相同，尤其协议栈靠近下面两层。

liang，一般不用rtos，panabit还涉及一些用户交互配置，防止意外还是gpos好一些，panabit的io要求应该没那么苛刻。
Panabit 于 2010-11-27 7:45 下午

Panaos既然成为一个OS,那么它肯定自己可以管理网卡，CPU资源，所以，不存在楼上说的开销。如果真如楼上所说，这个测试性能数据至少要降80%。
陈怀临 于 2010-11-27 8:17 下午

我认为，PanaOS能够成为Application Aware OS的典范。一旦整理并Open Source，可以在OS领域，不管是工程或者学术上，都有重大意义。而且是世界级的水平。到时写一个OSDI2012的文章。。。
virtex7 于 2010-11-27 8:37 下午

多谢panabit，明白。
Panabit 于 2010-11-27 8:58 下午

首席，容我想想，我看是否要开源，并且开源成BSD LICENSE。
to Panabit 于 2010-11-28 1:26 上午

别要随便被陈sir忽悠，你坚持自己的理想。陈sir鬼坏鬼坏的
to Panabit 于 2010-11-28 3:29 上午

互联网带宽在不断增强，流控产品的前景市场发展前景和广度不容乐观啊
to Panabit 于 2010-11-28 5:13 上午

不知道和这家公司的产品比何如？www.qosmos.com. QOSMOS可以提供多平台，多种软件包。
bigrong 于 2010-11-28 5:58 上午

不懂了，已经超出我知识范畴了。
不过顶小韩！
可惜不做网关设备，否则……
dcoder 于 2010-11-28 5:03 下午

请教楼主，测试时是否勾选了：”bi-direction” 的选项？
十分八卦 于 2010-11-28 5:53 下午

无限发散一下思维就当发梦 :p
发散一：对比Panabit与国内主流安全厂商，大家都还停留在Linux+netfilter上为主，虽然自己都宣称有XXXos，其实质我想大家都心知肚明。如果大家能摒弃价格竞争和死拼政府关系，一起来funding一个安全os，则……，则比空谈什么民族大义，自主研发的鲁迅型战斗檄文要现实的多。
发散二：国内目前有一堆的评测机构，可是评测的客观和真实性，老韩应该比谁都清楚。而这个直接导致了所有的评测选型，都朝着什么“多接口”“多核就是好来就是好”之类莫名其妙的标准去发展，长久下去会葬送掉大家。我们的厂商不能天天躺在政府和自己评测机构的襁褓里，不受风吹雨打。作为负责任的媒体，老韩有没有想法，引导一个真正不受厂商影响的中立测评机构。
发散三：那个鬼坏的陈sir都立此存照，要出我们国人的os了，能不能先给大家说说具体想法，好让我们兴奋下，起码有个努力方向。或许，像Panabit一样出一个通信专用os开始？能帮帮龙芯吗？比如用龙芯奔一个line speed的L7 QoS拿到RSA去show一把。
发散四：无比惭愧的想–行业内的老同志们，下次唾沫横飞的谈民族大义之前，我觉得先摸摸胸口？
十分八卦 于 2010-11-28 6:03 下午

回44，我替老韩说，一定选了。
droplet 于 2010-11-28 6:09 下午

CPU cycle换内存延迟？是用prefetch？prefectch对代码的侵害太大了，用的效果如何？
Panabit 于 2010-11-28 7:03 下午

老ZHU同志，不是用prefetch，我使用prefetch的结果是：用了不如不用。这里关键是HASH表结构设计。
sanbao 于 2010-11-28 7:40 下午

>带宽问题，应该出在ICH7和945之间的>DMI带宽上。82574芯片本身不存在问题。82574大包是基本上可以做到线速的。

ICH7和945之间的带宽是多少，从wikipedia http://en.wikipedia.org/wiki/Direct_Media_Interface
和intel手册309219.pdf看，

945GSE + ICH7R应该是DMI x2, 10Gbps,
上面测试结果才2Gbps，？

Some mobile northbridge chips (915GMS & 945GMS/GSE/GU) and mobile processors (Atom N450) use PCI-E x2, which results in half data rate (5Gb/s).
老韩于 2010-11-28 10:25 下午

To十分八卦：
别扣帽子，帽子会戴死人的。行业的游戏规则决定了一切，根本就不是媒体、评测能影响的。
要学习陈老师，在体制内卧薪尝胆，徐徐而图。
十分八卦 于 2010-11-28 10:53 下午

老韩同志，我说了发梦而已…莫怕莫怕 :p
老韩于 2010-11-29 1:51 上午

应很多朋友要求，补充了所有测试数据，都是测试仪控制台直接生成的PDF。
Panabit 于 2010-11-29 2:05 上午

回49楼：双向2Gbps，这个数据需要从DMI走两圈，所以总共应该消耗掉4G带宽。另外，根据我的了解，ICH7的DMI一般是2GB/s，这个是远远够的，所以这个DMI接口肯定存在水分了。另外，用ICH8，就基本上可以4G跑满的。
sanbao 于 2010-11-29 3:17 上午

多谢Panabit的回复，再请问一下, 双向2Gbps的意思应该是所有网卡TX方向和RX方向同时传数据，TX加起来一共是2Gbps，RX方向上加起来也是2Gbps，是这样吧？
Panabit 于 2010-11-29 3:24 上午

回楼上：双向2Gbps是指两个方向总和为2G，相当于一条线路，上行1G，下行1G。不管是多少，流量在总线上都要过两次。
sanbao 于 2010-11-29 4:53 上午

to Panabit:
网卡0 –> pcie –> memory –>pcie –>网卡1 1Gbps

网卡1 –> pcie –> memory –>pcie –>
网卡0 1Gbps

这样算起来pcie消耗4Gbps，假设pcie是pcie x4，那pcie的总带宽是算作20Gbps，
而不是算作10Gbps, 是这样吧？

上面这种情况，我把pcie消耗带宽算作
2Gbps, pcie x4的总带宽算作10Gbps，
这个我之前没搞清楚。
sanbao 于 2010-11-29 5:05 上午

也就是说这里ICH7 pcie x4的效率是4Gbps / 20Gbps == 2Gbps / 10Gbps, 对吗？
Panabit 于 2010-11-29 5:20 上午

我不太清楚DMI是不是用PCIE，我记得SPEC上说，ICH的DMI一般为2GBps，折算成16Gbps，这是两个方向共享的。我估计这个小盒子的ICH7版本有所限制，不是真正能到16Gbps。这个应该不是效率问题，而是实实在在的有限制。
Panabit 于 2010-11-29 5:22 上午

PCIE 1.0的是以2.5GT为基准，因为是8/10编码，所以最后有效带宽应该是2.0Gbps，最后*4算的结果倒和2GBps倒是相符的。
cai 于 2010-11-29 6:11 下午

To Panabit:
请教下
1 在百万会话的情况下测试，是否依然能达到这性能?如果只用少数几个流测试，会话跟踪的cache miss是体现不出来的
2 从性能参数测试看，>=256 BYTE字节大小的包，关闭策略与开启策略，其性能是一致的.
所以据此分析，DPI引擎并没扫描>=256字节之后的内容。是否关闭了部分规则，或规则进行了优化？
DO 于 2010-11-29 6:11 下午

了不起
Panabit 于 2010-11-29 6:44 下午

回60楼：1M会话情况下，我觉得肯定达不到这个性能。具体差多少，我也很想知道。DPI引擎没有关闭任何协议特征规则。Panabit的特征库都是通过PSDL编译器优化过的，而且引擎局部也会动态调整。
sanbao 于 2010-11-29 6:46 下午

FYI

http://download.intel.com/design/processor/datashts/309219.pdf

section2.4 DMI的signal type是写的pcie.
Lucifer 于 2010-11-29 10:43 下午

DMI就是一个重新包装的PCIE，版本是1.0还是1.1就不清楚了（到了SandyBridge阶段就升级为PCIE 2.0了），也就是2.5GT/s每信道，250MB/s，通常使用的4个信道就是1GB/s，双向就是2GB/s；某些移动版上可能用的是x2的配置，也就是单向500GB/s，双向1GB/s，这确实是一个瓶颈，在服务器上，IO设备通常都是挂在北桥上，而不是挂在需要经过DMI的南桥上
dcoder 于 2010-11-30 10:42 下午

to Panabit: 想要学习X86性能优化方面的知识请问有没有书籍可以推荐？
李信于 2010-12-01 8:48 下午

性能值很牛B啊
Lucifer 于 2010-12-01 10:40 下午

panabit的性能优化都是自己摸索的吧
西贝流士 于 2010-12-13 1:00 上午

看到垫的那本当砖的书，是邹恒明老师的《操作系统心智》，哈哈，也正在拜读。
邹不是我的老师，但是人家现在在复旦当教授，也是EMC symmterix enginity OS的参与者之一，敬佩这种从辽国海归回来的人士，如果我的数据结构是邹老师教的。。。。（因为邹老师也写了《算法之道》这本书）
哈哈。。岂不快哉！！
Lucifer 于 2010-12-13 1:51 上午

喔……垫的那本书是我的……写的还不错
怪叔叔 于 2010-12-13 6:39 下午

to Panabit:

pos勾起了一帮人的好奇心啊, 特别是在陈首席忽悠之后.~

可否猜猜它的大概设计思路?
1. 将硬件io的地址范围映射到特定的内存地址空间, 应用层直接访问.
2. 修改进程调度算法, 将pos的进程优先级调高.
3. pos进程以类似死循环的逻辑完成数据转发业务.

目前想到的大概这样了, 抛砖引玉, 满足下技术粉丝们的好奇心~
Panabit 于 2010-12-13 7:22 下午

上面3条都对！
Will Chie 于 2010-12-13 11:53 下午

另外还有应用层驱动，基本就是把PCI(E)移到用户层，当然还有网卡驱动。
陈怀临 于 2010-12-14 6:31 下午

我可没有特意为Panabit和POS做广告。当然，我还是很proud of 我的大弟子的。他是我见过对OS最有慧根的和发自内心热爱的人之一（我自己算一个）。

我感觉，如果Panabit能把GPU无缝的利用起来，POS基本上能杀遍美国无敌手。
Panabit 于 2010-12-14 6:59 下午

首席，惭愧得很，要追上你，还有很长的路要走！！！
阿土仔 于 2010-12-14 7:36 下午

浑身都起了鸡皮疙瘩
陈怀临 于 2010-12-14 7:43 下午

Heeee. 阿土仔好像有段时间没来了：-）。
Panabit 于 2010-12-14 7:57 下午
XantoWang 于 2011-01-05 11:23 下午

刚刚看了TCP新建的测试结果，到达90000T/S的时间只有20几秒，个人感觉持续的时间太短了，CPU和MEM都没有用到极限，像这种带会话的测试应该在保持稳定的情况下持续至少十几分钟以上，这个也要看系统消耗内存的情况。希望大家能提出不同意见。
XantoWang 于 2011-01-05 11:37 下午

从吞吐量的测试来看，测试时间只有10秒，个人觉得时间太短了，RFC2544里建议至少60秒。本人以前测试时遇到过，使用10秒测试可以达到线速，当把时间变长后，就达不到线速了。具体原因有待研究。
老韩于 2011-01-06 12:11 上午

我测过12小时和24小时的，很平稳。报告找不到了，也许当时没有留下来。第3篇里我再跑一次。
wangwei 于 2011-07-04 8:04 下午

看到这个结果，首先是没有打开”bi-direction” 的选项，只是一个简单的一个网口收一个网口发，用来测试系统的转发功能，对于开两个桥，除了在os方面的优化，还要考虑到cpu的处理能力，N270的性能本身就不好，对中断响应能力确实不行
楼上于 2011-07-05 1:57 上午

4个GE做2组桥

（100%=4Gbps）

不选bi-direction怎么跑出两组4G？
Panabit 于 2011-07-05 8:47 上午

上面N270的性能其实还可以继续提升。
gaohl 于 2011-07-05 5:51 下午

to XantoWang：10秒压力还是小的，虽说包量是一样的，我之前测试一般都100秒查找一轮，有变态的要测试180秒，更严格。

to Panabit：以后有机会可以帮你验证一下1M会话下的结果：）
Panabit 于 2011-07-05 6:24 下午

10s主要是考虑测试时间，无论是10s，还是30s，其实结果都一样的，100s结果应该也是一样。1M会话下，结果应该是有不少差别，特别是对于ATOM而言，因为CACHE比较小，而且乱序不好。gaohl，你在弯曲的那个群里吗？
Panabit 于 2011-07-05 6:26 下午

我们主要目的还是想先让大家看看X86本身的转发能力，所以比较关注裸奔的能力。现在大家普遍在X86上性能做不上去，很大部分原因就是裸奔做不上去。至于软件方面，各家和各种业务都不太一样，所以DPI并不具备代表性。
gaohl 于 2011-07-05 6:52 下午

其实无论10秒还是100秒，无非关注的是转发稳定性，如果有问题也许是这个期间某些进程占用CPU导致的丢包（比如crond的定期执行任务）或者中间设备问题（比如网线丢包或者仪表、交换机不稳定等）

to Panabit：不在啊，什么群？
Panabit 于 2011-07-05 6:54 下午

弯曲评论QQ群：108994604，进来吧，呵呵。
阿土仔 于 2011-07-05 6:56 下午

我也关注会话数比较多（至少几十万），打开功能多一些下的测试结果，毕竟简单的测试和真正现网的应用是差别很大的。
gaohl 于 2011-07-05 7:05 下午

谢谢Panabit已经申请了，待批复。
gaohl 于 2011-07-05 7:57 下午

有个问题请教各位，

防火墙（或者其他安全产品）的会话表满了后，再有新的会话过FW的处理方式：
1. 阻断
2. 通过算法或者直接删除一条最老的会话，给新会话提供资源
3. 提供开关实现1、2切换配置

小弟不才，没有接触过比较多的产品，不知道FW系列都是咋实现的？那位大牛给个指点，非常感谢。
wangwei 于 2011-07-05 8:41 下午

82574的性能，在x86平台上，裸奔的时候的测试结果，当搭配XEON CPU的时候，双向的吞吐量64K小包的时候最大能到80% 左右，搭配G41 +Q9650平台时能够到45%左右，而搭配N270时候能到17–18%,在国内以及台湾的主板来说已经是很好的性能了
wangwei 于 2011-07-05 8:49 下午

使用的测试设备 smartbits6000c,软件 smartapplication 3.41,难道会有这么大的差别？
Ma Ling 于 2011-07-13 7:25 上午

如果你愿意，我们可以进一步挖掘 atom 的性能，我做了 intel atom, nhm, snb上面的 32/64 bit glibc 函数，分别进入 linux kernel, glibc, opensolaris, 包括 memcpy, memset,memcmp, strlen, strcpy, stcmp…
其中memcpy, memcmp,memset 达到了cpu 理论值， 16byte/cycle.
wheel 于 2011-08-23 10:48 下午

PacketShader路由器，用GPU的路由器，在处理诸如认证或将数据包加密成数据流的过程中，GPU速度尤其快。当GPU着手这些任务时，它给了中央处理器（CPU）喘息的空间，去处理按照自然顺序的其它任务，这样依次处理几个数据包可以发现异常闯入网络的企图。
julang3 于 2011-08-28 8:07 上午

最近在分析PF_RING的DNA网卡驱动；从其测试性能来看，单核收，发均能做到10G线速；看来X86的IO能力也不差了；个人觉得，差别其实是在软件上；
看起来PF_RING DNA的实现思路似乎和intel DPDK;Panabit相近；都是将网卡收发包逻辑移到用户态；避免了内核态网卡驱动的所有开销：内存COPY,上下文切换，缓冲区的分配与释放等；
老韩于 2011-08-28 10:47 上午

主要看转发平面如何与业务平面很好地结合起来吧，其实用户态不用户态真不是特别重要。
julang3 于 2011-08-28 7:17 下午

认同老韩的看法，这里强调用户态主要是考虑到开发，调试，优化的难度；相比内核态程序；用户态的应用要方便很多
《给力吧，x86》专题连载三：x86平台网络应用效能实测 : 弯曲评论 于 2011-12-08 7:21 上午

[...] 作者老韩 | 2011-12-07 08:15 | 类型研发动态, 科技普及, 网络安全, 行业动感, 通讯产品 | 没有用户评论 » 分享到：新浪微博 QQ空间开心人人 Live Digg FB Twitter 弯曲评论现在的影响力很大，甚至能吸引到一些行业用户的关注（潜水居多）。本文就是《给力吧，x86（1）——11月10日测试记录》一文刊登后，用户直接与我们沟通进行的一次测试合作的副产品。这是一个良好的开端，后续还有与其他用户联合进行的更大、更深入、更给力的测试，敬请关注。 [...]
sa 于 2013-03-19 12:01 上午

pf_ring dna网卡是不是直接把网卡数据写到user space 上，连nic-kernel拷贝都省了
linkk 于 2013-04-23 2:47 上午

是的，而且使用hugepage，减少了tlb的刷新频率。

最新用户评论

最新文章

分类

给力吧，x86（1）——11月10日测试记录

雁过留声