Chinaunix

标题: 如何让 linux 包转发达到 40万pps,尝试中！ [打印本页]

作者: bingosek 时间: 2005-11-06 02:09
1000Kpps,好像有点难度哦,cisco 2600我记得就那么几十Kpps

作者: platinum 时间: 2005-11-06 09:10
1000MBps 线速才 148.8Wpps，你这个 100Wpps 快达到千兆线速了，X86 构架是没戏的，只能考虑 NP 构架了

作者: caibird3rd 时间: 2005-11-06 12:12

原帖由 platinum 于 2005-11-6 09:10 发表
1000MBps 线速才 148.8Wpps，你这个 100Wpps 快达到千兆线速了，X86 构架是没戏的，只能考虑 NP 构架了

148.8Wpps是怎么来的？X86的限制在哪里呢？

作者: platinum 时间: 2005-11-06 13:29
包转发线速的衡量标准是以单位时间内发送64byte的数据包（最小包）的个数作为计算基准的。对于千兆以太网来说，计算方法如下：1,000,000,000bps/8bit/（64 + 8 + 12）byte=1,488,095pps 说明：当以太网帧为64byte时，需考虑8byte的帧头和12byte的帧间隙的固定开销。故一个线速的千兆以太网端口在转发64byte包时的包转发率为1.488Mpps。快速以太网的线速端口包转发率正好为千兆以太网的十分之一，为148.8kpps。
*对于万兆以太网，一个线速端口的包转发率为14.88Mpps。
*对于千兆以太网，一个线速端口的包转发率为1.488Mpps。
*对于快速以太网，一个线速端口的包转发率为0.1488Mpps。

但是我不清楚 X86 的瓶颈在哪里

作者: guotie 时间: 2005-11-07 10:18
100Wpps是可能的。

作者: guotie 时间: 2005-11-07 10:54
你可以使用bridge，转发效率更高。

作者: cx6445 时间: 2005-11-07 17:05
x86构架不差的，我现在用的网络设备x86的工控机，修改过的freebsd4.X，专用软件。每秒http请求近1万，并发连接10多万，流量进600兆出700兆，还是做nat+负载均衡的。比很多所谓的专用构架专用芯片的网络设备强得不止一个档止。

[ 本帖最后由 cx6445 于 2005-11-7 17:29 编辑 ]

作者: platinum 时间: 2005-11-07 17:44

原帖由 cx6445 于 2005-11-7 17:05 发表
x86构架不差的，我现在用的网络设备x86的工控机，修改过的freebsd4.X，专用软件。每秒http请求近1万，并发连接10多万，流量进600兆出700兆，还是做nat+负载均衡的。比很多所谓的专用构架专用芯片的网络设备强得不 ...

这个是用来做什么的？服务器还是 NAT 设备还是什么？
是否统计过 pps 有多少？我想知道 ^_^

作者: skylove 时间: 2005-11-07 20:19

原帖由 cx6445 于 2005-11-7 17:05 发表
x86构架不差的，我现在用的网络设备x86的工控机，修改过的freebsd4.X，专用软件。每秒http请求近1万，并发连接10多万，流量进600兆出700兆，还是做nat+负载均衡的。比很多所谓的专用构架专用芯片的网络设备强得不 ...

你用的什么web server ? 能单机支持这么多连接请求...

作者: cx6445 时间: 2005-11-07 23:15
晕倒，说了是网络设备呀，做负载均衡加image cache和tcp offload。

作者: platinum 时间: 2005-11-07 23:26
pps 到了多少？硬件配置又是什么样子的？

作者: cx6445 时间: 2005-11-07 23:34
http://tech.sina.com.cn/t/2004-11-02/2337452622.shtml
就是这种产品，是我用过最爽的网络设备，web界面和性能都非常出色的。不象有些知名网络设备,官方标称和实际使用根本两回事。
目前我看到过最高的时候pps好象是20万

http://www.netscaler.ca/downloads/Datasheet-Switch.pdf

好象有做广告嫌疑，呵呵！不过新浪用得很爽的。

[ 本帖最后由 cx6445 于 2005-11-8 00:08 编辑 ]

作者: platinum 时间: 2005-11-08 00:04
这个东西成本也低不了吧

作者: cx6445 时间: 2005-11-08 00:14
当然不便宜了，我原意只是想说x86构架不差的，也不是说其它的构架不好。

作者: causky 时间: 2005-11-08 22:04
发连接10多万??太假了

作者: guotie 时间: 2005-11-09 10:22
x86架构服务器，上两个cpu，linux 应该可以轻松达到50Wpps以上的纯粹转发效率

作者: platinum 时间: 2005-11-09 10:41
“纯粹转发效率”指什么？

作者: guotie 时间: 2005-11-09 11:10
指仅仅转发数据包。

作者: platinum 时间: 2005-11-09 11:31
X86 构架很难做千兆的网络设备，PCI 总线不够大，不知道 PCI-E 的 133 出来以后，再配上 64 位处理器能否实现

作者: cx6445 时间: 2005-11-09 13:12
X86 构架是指处理器的构架吧，又没说一定要使用pci的。

[ 本帖最后由 cx6445 于 2005-11-9 13:15 编辑 ]

作者: platinum 时间: 2005-11-09 13:44

原帖由 cx6445 于 2005-11-9 13:12 发表
X86 构架是指处理器的构架吧，又没说一定要使用pci的。

愿听详解 ^_^

作者: cx6445 时间: 2005-11-09 21:25

没有什么详细的，一般厂商都不会自己开发总线系统的，成本高难度大。好象PCI－X构架用着就不错了。
事实就是：
FreeBSD 4.4-RELEASE
CPU: Pentium 4 (3065.00-MHz 686-class CPU)
real memory = 3893362688 (3802112K bytes)
pci2: <

CI bus> on pcib2
bx1: <3Com 3C996SX Gigabit Fiber-SX Server NIC>
bx1: PCIX target workaraund

[ 本帖最后由 cx6445 于 2005-11-9 21:26 编辑 ]

作者: caibird3rd 时间: 2005-11-10 08:51
据我所知，它的性能主要来自：
网络硬件采用交换架构，即使用交换机板，并且使用了专用硬件加速芯片（这个占了一大半成本）
现在要做这类高性能设备，没有硬件支持是不行的了

能更详细的介绍一下你们用的这款产品的硬件配置吗？把你在FreeBSD下看到的输出都列一下罗
我们现在用一款纯软件实现的产品，进出各能达到近500兆，好像到瓶颈了。不过你说的进出600/700兆，
好像吞吐量也不是很大嘛，不知最大能到多少？

原帖由 cx6445 于 2005-11-7 23:34 发表
http://tech.sina.com.cn/t/2004-11-02/2337452622.shtml
就是这种产品，是我用过最爽的网络设备，web界面和性能都非常出色的。不象有些知名网络设备,官方标称和实际使用根本两回事。
目前我看到过最 ...

[ 本帖最后由 caibird3rd 于 2005-11-10 09:14 编辑 ]

作者: cubzsdb 时间: 2005-11-14 16:23
标题: 不是有PCI 64 BIT吗?
不是有PCI 64 BIT吗?

作者: ahuoo 时间: 2005-11-15 00:08
兄弟是否在做防火墙之类的产品？

作者: mirnshi 时间: 2005-11-15 16:03
x86架构是指cpu的指令集是i386的，pci和cpu没有关系，好多arm指令集的嵌入式板子也采用pci总线。pci是以Intel为首的弄的，
目前工控板服务器板都是x86+pci总线的，由于包处理都是需要网卡经总线由cpu处理。目前CPU的速度是足够快了，但是pci总线却无法满足速度要求。
想开发一套自己的总线是没有问题，关键在于周边的设备，诸如网卡芯片都是PCI之类的，当然有钱还可以接着开发自己的网络处理芯片，于是变成了NP。
作千兆还是不要用FreeBSD4.x的好，内核不支持多线程。可以用6.0或者换成Linux

作者: wxxszzz 时间: 2005-11-16 22:02
主要还是现在的主板都是PCI总线结构的，
只有133速率，即每秒 133M/s
跑个百兆网络转发还差不多，

即使是跑百兆网络，在内网机器多的情况下，内网的网卡最好还是用千兆或者是双百兆网卡，及一块外网百兆网卡。否则内网网卡错误的IP包就会很多的。可通过ifconfig查看到。

因为内网有很多包并不需要到外网去，所以内网网卡的工作量比外网网卡多的多。

一般现在的815芯片到865芯片架构的主板做内外构通的话，合理，经济的方式就是

就是两块百兆内网网卡做bond绑定负载轮流接内网交换机，不需要交换机支持绑定的，用个现在通用的
DLINK1024R+即可。。
一块外网百兆网卡接ISP商。

基本可以跑到百兆速度极限。如果ISP没做流量控制的话。

换算成字节的话就是每秒 11.5m/s 左右。

你可以用FTP软件传一个大文件试试就行了。

如果是bit的话就是 11.5*8 m/s 左右。

作者: caibird3rd 时间: 2005-11-17 10:17

原帖由 wxxszzz 于 2005-11-16 22:02 发表
主要还是现在的主板都是PCI总线结构的，
只有133速率，即每秒 133M/s
跑个百兆网络转发还差不多，
...

每秒133M/s是什么东东？

作者: colddawn 时间: 2005-11-17 16:42
楼上说的正解，cpu指令集和总线架构是2回事，pci确实不行了，32bit，133Mhz，算算带宽百兆多点，稍微高点的应用就不行了，所以民用领域推出agp，服务器领域推出pci-X，但目前的趋势是统一回pci-E。
去intel的网站看看intel的网卡型号吧，824XX，825XX，总共几十个型号，都是有区别的，有pci的，有pci-X 66MHz的，有pci-X133Mhz的，还有pci-E的，甚至有dual port ，quard port的，说明一旦用上pci-X以上级别的总线，网卡绝对是能跑那么大带宽的，所以不必觉得X86不行了。

作者: caibird3rd 时间: 2005-11-17 21:37
32bit,133Mhz，我怎么算出来是500多兆字节呀？4个G bit/s啊
感觉处理大流量的瓶颈还是在CPU上，光是系统中断的处理就是不小的一块了

原帖由 colddawn 于 2005-11-17 16:42 发表
楼上说的正解，cpu指令集和总线架构是2回事，pci确实不行了，32bit，133Mhz，算算带宽百兆多点，稍微高点的应用就不行了，所以民用领域推出agp，服务器领域推出pci-X，但目前的趋势是统一回pci-E。
去intel的网站 ...

作者: q1208c 时间: 2005-11-17 22:19

原帖由 platinum 于 2005-11-9 11:31 发表
X86 构架很难做千兆的网络设备，PCI 总线不够大，不知道 PCI-E 的 133 出来以后，再配上 64 位处理器能否实现

PCI-X 是 64bit 133MHz的. 应该能够用的. 但好象一台机器也就支持一个133Mhz的然后就只能是两个 100Mhz的. 再下来就是66Mhz的了.

X86应该是没什么大问题的. CheckPoint还不是多数放在x86上跑了. 只不过要优化一下, 咱那PC可能差一点.

作者: 阿辉 时间: 2005-11-18 09:55
我想这个可能是 LINUX性能的问题，不知楼主用的是什么网卡，驱动是哪的？有时候换个驱动会快很多。现在有一个技术叫零拷贝。还有如果你是按到交换机上。也要看看交换机是否能达到那么高。有些交换机比较慢。建议用3com的。

作者: colddawn 时间: 2005-11-18 10:08
sorry ，前面提供资料有误，现在更正一下，
最初PCI总线是32bit，33Mhz，这样带宽为133Mbps。
接着因为在服务器领域传输要求Intel把总线位数提高到64，这样又出现了2种PCI总线，分别为64bit/33Mhz和64bit/66Mhz，当然带宽分别翻倍了，为266Mbps和533Mbps，这个比较通常的名称应该是pci-64，但这好像是intel自己做的，没有行业标准。
稍后一段时间，在民用领域，单独开发出了AGP，32bit，66Mhz，这样带宽为266Mbps，再加上后来AGP2.0的2X和4X标准，最高4X的带宽高达1Gbps，但是这个只是为显卡设计的。
同时服务器领域也没闲着，几家厂商联合制定了PCI-X，这个就是真正PCI下一代的工业标准了，其实也没什么新意，就是64bit，133Mhz版本的PCI，那这样带宽就为1Gbps，后来PCI-X 2.0,3.0又分别提升频率，经历过266Mhz，533Mhz，甚至1GMhz，各位自己算带宽吧，我乘法学的不好，这个带宽可以说是非常足够的了，不过这个时候PCI也面临一些问题：一方面是频率提高造成的并行信号串扰，另一方面是共享式总线造成的资源争用，总之也就是说虽然规格上去了，但实际效果可能跑不了这些指标。
然后就是我们目前的明星pci-E了，这个标准应该是和pci-X同时出现的，但是由于当时用不到这么高带宽，并且不像pci-X一样兼容老pci板卡，所以一直没什么发展，直到最近民用领域显卡带宽又不够了，服务器领域对pci-X也觉得不爽了，pci-E才真正显出优势来，目前这个标准应该会替代agp和pci-X，成为民用和服务器两大领域的统一标准。
PCI-E标准的最大特点就是串行总线，和普通pci的区别类似于ide和sata的区别，具体说起来就比较麻烦了，简单来看指标的话，频率为2.5Ghz（这个恐怖，串行的好处，同样因为串行，位宽就没意义了，但是据说是什么8bit/10bit的传输），带宽 pci-E 1X单向传输250MBps，双向也就500了，同时pci-e的倍速最高可达16X，多少就自己乘吧，要注意的是pci-e不存在共享问题，也就是说挂在总线上的任何一个设备都会达到这个速度而不是所有设备带宽的总合。下面引用一篇文章的一段，感兴趣的自己看一下：

在工作原理上，PCI Express与并行体系的PCI没有任何相似之处，它采用串行方式传输数据，而依靠高频率来获得高性能，因此PCI Express也一度被人称为“串行PCI”。由于串行传输不存在信号干扰，总线频率提升不受阻碍，PCI Express很顺利就达到2.5GHz的超高工作频率。其次，PCI Express采用全双工运作模式，最基本的PCI Express拥有4根传输线路，其中2线用于数据发送，2线用于数据接收，也就是发送数据和接收数据可以同时进行。相比之下，PCI总线和PCI-X总线在一个时钟周期内只能作单向数据传输，效率只有PCI Express的一半；加之PCI Express使用8b/10b编码的内嵌时钟技术，时钟信息被直接写入数据流中，这比PCI总线能更有效节省传输通道，提高传输效率。第三，PCI Express没有沿用传统的共享式结构，它采用点对点工作模式（Peer to Peer，也被简称为P2P），每个PCI Express设备都有自己的专用连接，这样就无需向整条总线申请带宽，避免多个设备争抢带宽的糟糕情形发生，而此种情况在共享架构的PCI系统中司空见惯。

由于工作频率高达2.5GHz，最基本的PCI Express总线可提供的单向带宽便达到250MBps（2.5Gbps×1 B/8bit×8b/10b=250MBps），再考虑全双工运作，该总线的总带宽达到500MBps—这仅仅是最基本的PCI Express ×1模式。如果使用两个通道捆绑的×2模式，PCI Express便可提供1GBps的有效数据带宽。依此类推，PCI Express ×4、×8和×16模式的有效数据传输速率分别达到2GBps、4GBps和8GBps。这与PCI总线可怜的共享式133MBps速率形成极其鲜明的对比，更何况这些都还是每个PCI Express可独自占用的带宽。

总之写这么多废话，目的就是说明就系统总线来说，承受高带宽，高pps是没问题的。
再上面有人说即使总线没限制，cpu也会成为瓶颈，这话有一定道理，其实关键在于高pps带来的恐怖中断flood，其实对于这么高的中断，i386的apic（高级中断控制）是完全处理的来，瓶颈是在操作系统的中断处理程序上了，这方面问题就由操作系统来解决了，所以不是什么不可能完成的任务，实际上目前也都有很成熟的方案了，比如BSD系统的网卡Polling，Linux也有，具体叫什么我忘记了。
还是那句话，别对i386没信心，也别对目前的PC架构计算机的能力有任何怀疑，事实证明，这样的搭配至少能满足90%的应用需要。

作者: caibird3rd 时间: 2005-11-18 15:51
目前，linux作为一种通用的操作系统，
的确跟不上超高速网络流量处理的需求了
不知在这方面有什么linux的改进项目没有？
听说通过精简优化其TCP/IP堆栈可以获得近20%的性能提升，不知有没有这回事？
觉得关键还在系统中断方面，真是成也萧何，败也萧何！

原帖由 colddawn 于 2005-11-18 10:08 发表
sorry ，前面提供资料有误，现在更正一下，
最初PCI总线是32bit，33Mhz，这样带宽为133Mbps。
接着因为在服务器领域传输要求Intel把总线位数提高到64，这样又出现了2种PCI总线，分别为64bit/33Mhz和64bit/66Mhz ...

作者: colddawn 时间: 2005-11-21 09:15

原帖由 caibird3rd 于 2005-11-18 15:51 发表
目前，linux作为一种通用的操作系统，
的确跟不上超高速网络流量处理的需求了
不知在这方面有什么linux的改进项目没有？
听说通过精简优化其TCP/IP堆栈可以获得近20%的性能提升，不知有没有这回事？
觉得关键 ...

优化协议栈的工作确实有人在搞，性能提升20%的说法只是听说，没见有实际证据，至于linux不能应付搞网络流量处理的问题，请问您是从哪里得来的？有没有实际数据？所谓高速网络高到什么程度？高流量还是高pps？

作者: wheel 时间: 2005-11-21 10:28
pci-e现在可以比pci-X达到跟快的速度了，现在ic设计里，并行的发展已经达到一个瓶颈，因为频率的提高，分布和泛生也随之更复杂，所以设计同样性能的一个PCB,使用PCI-E比X会容易的多，并且现在Synopsys和Cadence对于PCI-e的IPcore的公布，新的主板使用E代替X的会越来越多，X的线真的太多了，串扰太难搞了，最少要6层板才搞的定，E就好搞到多，几个蛇部就过去了。其实从时序分析上看不出X比E的优点在那，可能还是在产品链上把。

作者: 独孤九贱 时间: 2005-11-21 16:04

原帖由 colddawn 于 2005-11-21 09:15 发表

优化协议栈的工作确实有人在搞，性能提升20%的说法只是听说，没见有实际证据，至于linux不能应付搞网络流量处理的问题，请问您是从哪里得来的？有没有实际数据？所谓高速网络高到什么程度？高流量还是高pps？

偶见过许过权威的测试报告，测试过国内很多用linux作的防火墙、安全网关……等一大堆东东，用smartbit来测：
pIII 1G 的CPU，可以达到35%/64bytes左右。freebsd的话，稍好一点，不过也仅是“稍”；离线速差得太远了。
————————————————————
这个还只是100M，如果1000M的话，更是惨……即使是双至强的CPU。

偶某高校的朋友用四至强的服务器，达到了1000M线速……不过成本也太……

——————————
性能不佳，有硬件的原因，也有软件的原因。不过就目前Linux的这种定位、目前这种网络堆栈架构来看，短时间要提高，是不太现实的。
所以，只能希望通过硬件来提升，只是通用X86架构，同样，定位也不是专门针对此的，所以……
关于X86的这点，偶同志从CPU的角度，有一篇精典论述：
http://www.skynet.org.cn/viewthread.php?tid=11&fpage=1

听说，ixp1200以上，powerNP高频的CPU可以达到线速。也看过一些硬件厂商产品发布会现场演示，的确如此，不过本人没有亲自试过，不敢肯定……

作者: colddawn 时间: 2005-11-22 09:16

原帖由 独孤九贱 于 2005-11-21 16:04 发表

偶见过许过权威的测试报告，测试过国内很多用linux作的防火墙、安全网关……等一大堆东东，用smartbit来测：
pIII 1G 的CPU，可以达到35%/64bytes左右。freebsd的话，稍好一点，不过也仅是“稍”；离线速差得 ...

请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了linux+iptables再套个外壳实现的，要知道光netfilter架构处理占用的cpu时间就高达30%，如果再加上那个性能风传非常差的conntrack的话，这个结果不出奇，这并不能说明是总线瓶颈或者是cpu瓶颈，另一方面，即使是你说的35%的带宽利用率，你有统计过那时中断/s的数量吗？有证据证明是cpu中断处理不过来了吗？
linux的我倒真是没测试过，但是同样是p3 1G，板载pro 100，我装过freebsd，仅仅使用ipfw+bridge做透明防火墙，连内核都没有优化过，轻松达到80M，无延迟，无丢包，100%线速说不上，但90M的时候的丢包率也是基本可以忽略不计。
如果一个1000M包转发的设备都要用4路Xeon，那24口千兆三层交换或者路由器岂不是要大型机？

作者: 独孤九贱 时间: 2005-11-22 09:37

原帖由 colddawn 于 2005-11-22 09:16 发表

请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了linux+iptables再套个外壳实现的，要知道光netfilter架构处理占用的cpu时间就高达30%，如果再加上那个性能风传非常差的conntrack的话，这个结果不出 ...

不太同意你的话：

1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p3 1G的CPU，64bytes下能到80M，我现在有好几台freebsd的机器，p4的和至强的，两边用光阵列机来跑，512bytes下才能到100M，64bytes下离你说的数据差得太远，因为没有条件，没有办法拿Smartbit来做测试，不过我想误差应该不会太离谱。
3、目前intel架构的CPU网络数据处理与交换机的CPU等处理有质的差别，不能同一而论……否则大家做什么ASIC，做什么NP，拿一块p3不就完了……
4、至于性能不到，如果跑开软件不谈，光是谈硬件的话，我个人从经验来看，100M环境瓶颈主要在CPU，1000M则是一个综合的因素，目前PC架构在很多方面都无法满足1000M的大流量的处理。而如果要谈软件呢，linux和unix性能之别主要还是“其实是MBuf和skbuf的优劣，这是个老话题。……”

至于为什么我认为100M下边，硬件方面CPU是主要的瓶颈，这是因为
1、实践中，换个CPU，性能可以得到质的提升；
2、在目前的一些贴子中，我始终还是认为我同事说得有道理，把他的原话贴出来：
——————————————————————————————————————————————
目前，很多X86的防火墙厂商都宣称，64bytes小包线速转发，94%……，呵呵，让我们来看看kola关于这个的经典论述<部份地方稍有修改>：

一. 线速
线速转发是对一个网络中转设备的理想要求。但平时大多数人都关注着设备的bps（bits per second，每秒数据的位数），很少人会想到fps（frame per second，每秒数据的帧数）实际上更考验设备的转发能力。
简单的说，bps是指每秒钟有多少字节的数据经过，fps是每秒钟有多少个数据包经过。
以10Mb的网络来说，线速时bps为10M，fps最大值为14880。
那么这个14880是怎么计算出来的呢？
首先我们要知道几个规定：
1. 以太网内最小的数据包的大小为64字节，它包括4字节的CRC，2字节的以太网类型（或长度），6字节的源Mac地址，6字节的目的Mac地址以及46字节的负荷。
2. 以太网帧与帧之间至少要有96位（12字节）的帧间隙（IFP，inter frame gap）以确保区分两个数据包。
3. 每个数据帧开始之间必须要有8字节的Mac地址前导位（MAC preamble）以确保发送方接收方同步数据位。
因此，以太网内最小的数据包实际上是64+12+8=84字节=672位。
于是，10M网络环境下fps的最大值就是
10M位每秒 / 672 位每帧 = 14480 帧每秒。
同理，我们可以算出10M网络环境下fps的最大值为
10M位每秒 / ( ( 1518+12+8 ) * 8 ) 位每帧 = 812 帧每秒
而100M网络环境下这两个值分别为148809和8127。

二. 处理能力
我们已经知道了线速情况下最大的fps值，现在我们看看要达到线速所需要的处理能力。
假设市面上某防火墙的是X86架构的CII 900Mhz 的CPU，即每秒钟可以分成900M个时钟周期。
于是，在100M的网络环境下，处理一个数据帧所允许的最大时钟周期为：
900M 时钟周期每秒 / 148809 帧每秒 = 6048 时钟周期每帧
也就是说，要达到线速转发，900Mhz的CPU平均要在6048个时钟周期内完成对一个数据包的处理。
这只是理想情况，基于x86架构的系统里CPU还要负责各类中断（如系统时钟）的处理，每次中断时都要保存当前的运行状态，切换到中断处理程序，等中断处理完后，再恢复当前状态，切换回原来的处理流程。光是这个切换过程至少都要费上500个时钟周期，还不包括中断处理程序所用的时钟周期。好在这类中断还”不算“频繁，扣除系统这部分开销后，真正分摊到每个数据包的处理时间平均大约还有5500个时钟周期。
虽然Intel P3以上级的CPU如CII在设计指令集时已经将大量常用的指令（如两个寄存器相加/减）优化到可以在一个时钟周期内完成，但做为防火墙，更常用的是读/写内存数据（比如要比较源地址，计算IP的校验和等）这类多时钟周期的指令，所以5500个时钟周期内大约只能执行2000条指令。
对一个数据包的处理，从为这个数据包分配内存起，依次要检查以太网络协议（如果是RFC1042格式的数据包还要跳过LLC头找真正的以太网络协议），检查IP头、校验和（如果是TCP/UDP协议还要计算对应的校验和），DoS防御，状态检测，NAT规则，安全/统计规则，更新ARP/路由表，选择转发网卡，直到最终把这个数据包添加到发送队列中才算完成。
你认为2000条x86的指令能完成这一切吗？

三. 现实数据
2000条指令看起来很多，实际上并不多，举个例子，要完成最简单的 A = A + B 这个算式最优化的指令也要用上两条：
mov eax, [val_B]
add [val_A], eax
未优化的会用上四条：
mov eax, [val_A]
mov ebx, [val_B]
add eax, ebx
mov [val_A], eax
目前的防火墙的开发大多是在Unix/Linux上完成的，以GCC编译器为例，它的优化效果比商业的编译器如VC/BC差了大概20%，也就是说同一段C代码，用商业编译器能编译成100条指令的话，GCC最好的情况下只能编译成120条指令。
实际上，在没有任何包过滤规则或其它配置的情况下，完整的处理一个数据包需要大约14000条指令。
所以,根据上面的计算，目前许多X86架构防火墙（PIII 800）在100M网络环境下的结果是64byte的情况下达到42%的线速转发能力，即62000fps的处理能力。至于100%，95%，90%以上……

作者: colddawn 时间: 2005-11-22 11:13
1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！

理解！不过这也证明目前市面上的很多国产设备的现状以及国内这个领域的研发状况，不做评价

2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p3 1G的CPU，64bytes下能到80M，我现在有好几台freebsd的机器，p4的和至强的，两边用光阵列机来跑，512bytes下才能到100M，64bytes下离你说的数据差得太远，因为没有条件，没有办法拿Smartbit来做测试，不过我想误差应该不会太离谱。

ok，我承认，我用的是P3 1G Xeon MP，PCI-X架构的pro 100网卡，以太网口。
同时我做的是透明网桥，包在2层就bridge走了，因此效率确实是比较好的，同时ipfw这个也是简单高效的代表，因此我相信我这套搭配应改在效率方面有较大的优势。
我测试的方法是发起100Mbps的synflood，这个应该是64bytes吧，如果全速情况下，我的设备能透过84M左右到达对端，也就是能保证80M不丢包。
我认为你测试达不到的原因可能在于你的光阵列，据我所知，光电转换后frame结构会改变的，跟以太网贞又很大区别，而光传输的优势在于高带宽高时延，但pps就不是很好，如果你用这这种设备，2次转换后应该会有折损的，具体细节我不是很了解，这只是推测。另外一个原因是你的设备的网络其他部分占用了较多cpu，例如ip层转发。我的设备在最高流量下cpu占用80%左右，打开网卡polling后降至40%，负载不会超过1，属于可以承受范围

3、目前intel架构的CPU网络数据处理与交换机的CPU等处理有质的差别，不能同一而论……否则大家做什么ASIC，做什么NP，拿一块p3不就完了……

这里我同意，ASIC的架构确实更适合一些，我的意思是目前CPU的指令处理速度应该不止于如此不堪。

4、至于性能不到，如果跑开软件不谈，光是谈硬件的话，我个人从经验来看，100M环境瓶颈主要在CPU，1000M则是一个综合的因素，目前PC架构在很多方面都无法满足1000M的大流量的处理。而如果要谈软件呢，linux和unix性能之别主要还是“其实是MBuf和skbuf的优劣，这是个老话题。……”

CPU确实有很大影响，但是我感觉在做好一定优化的基础上，i386绝对能胜任的。MBuf的问题就不讨论了，讨论那就是班门弄斧了。

作者: caibird3rd 时间: 2005-11-23 09:50
现在100Mb/s以下的流量已经不是问题了
我们的目标是千兆甚至更多
现在看来，通用的linux平台的确不能满足需要（这里不谈硬件部分）

谁能告诉我，linux在这方面有什么改进项目没有？或者有什么公司可以做这个事情？

另外，没看过MBuf的资料，它比skbuf好在哪里啊？哪位能点拨一二？

原帖由 colddawn 于 2005-11-22 09:16 发表

请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了linux+iptables再套个外壳实现的，要知道光netfilter架构处理占用的cpu时间就高达30%，如果再加上那个性能风传非常差的conntrack的话，这个结果不出奇，这并不能说明是总线瓶颈或者是cpu瓶颈，另一方面，即使是你说的35%的带宽利用率，你有统计过那时中断/s的数量吗？有证据证明是cpu中断处理不过来了吗？
linux的我倒真是没测试过，但是同样是p3 1G，板载pro 100，我装过freebsd，仅仅使用ipfw+bridge做透明防火墙，连内核都没有优化过，轻松达到80M，无延迟，无丢包，100%线速说不上，但90M的时候的丢包率也是基本可以忽略不计。
如果一个1000M包转发的设备都要用4路Xeon，那24口千兆三层交换或者路由器岂不是要大型机？ ...

[ 本帖最后由 caibird3rd 于 2005-11-23 09:55 编辑 ]

作者: mirnshi 时间: 2005-11-23 21:59

原帖由 独孤九贱 于 2005-11-22 09:37 发表

不太同意你的话：

1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p3 1G的CPU，64by ...

fps鲜有所闻，大家好像一般都是说pps。桢的概念似乎是通讯上的，包似乎是网络处理上的。

先看看操作系统如何处理包：
一般对于高效处理，很少是一个包一个中断的，都是通过轮询方式，比如在freebsd下，高负载情况下，
可以设置5000次/s(intel百兆卡，一般够用，至于怎么够用，自己算吧)甚至更高，网卡会将收到的包
存放于队列中，等待cpu的主动处理。这样中断数会极大降低。一般好的网卡比如常见的intel百兆卡，
(如果没有记错的话，队列大小是32，而8139才4)，可以缓冲大量的包，这样cpu的一次中断可以处理多
个包。在纯路由模式下，即使有少量的规则，包转发的速度是非常快的，基本可以达到线速的，当然
不是100M，所有的网络节点设备都会有延时的，只是多少而已。在防火墙中，消耗cpu的是nat和复杂的
规则检测，其他的基本功能消耗cpu比较少, 速度非常快，拿过一个包，通过指针定位ip头，根据ip头
定位动态规则表（hash检索），比较一下要么丢弃，要么直接送到下层。如果对协议栈了解的话，会
知道一个包从网络进入协议栈，大部分流程都是条件判断。
arp表，路由表之类的处理也非常快的，记得是3跳命中。再说了还有高速缓冲的，在freebsd中还可以
打开fastforward。mbuf使用起来也不像应用层的内存申请使用，不用担心那么耗费指令。对于包效验
和，汇编指令编写的，一般需要几十条指令，不会超过百条。

再看看CPU:
谈论到CPU，不能仅仅考虑频率。CPU的性能不能仅看频率，不同CPU的IPC也是不同的，众所周知的PIV
刚出来的时候还不如PIII，就是因为PIV的IPC不如PIII。而且现在CPU的IPC大都大于1，流水线技术不是
个摆设。还有就是PIII不等同于i686，i686只是一个指令集，支持i686的cpu很多，但是同代CPU中，PIII
是最强的。至于Cyrix的，是走低功耗市场的，性能嘛，不说了。

做程序，讲性能，不是简简单单的加减乘除，理论不等于实际。42%，莫非增加N多复杂规则检测？

作者: mirnshi 时间: 2005-11-23 22:22
目前对于百兆, CPU的速度足够，除非增加各种稀奇古怪的功能进去--什么各种代理过滤之类的。
对于千兆，由于pps增加了，网卡的队列也增加了，考虑到时延问题和中断，以及PCI通道问题，CPU就显得不够用了。内核支持SMP的，性能会提高很多。而且千兆很多都是桥模式的，最差也是路由模式，有哪个网管愿意在出口处，放个瓶颈？桥模式都是2层上作，省去了三层协议队列，当然处理时，需要自己构建协议栈了，包转到协议栈后，再由其他线程处理，分工合作。但无论怎样，受到PCI/X限制，也只能是当个假千兆用。
曾在Freebsd上作过测试，DDOS攻击，如果直接收包丢弃，可以达到8、900M，机器是PIV2.4至强，bsd 4.11，但是发包受限，优化得非常好了不过300多。

作者: zyzf 时间: 2005-11-30 11:17
X86的瓶颈就在网卡驱动上面。
个人觉得。

作者: test_tmp 时间: 2005-12-05 08:43
标题: 请问楼主,如何达到5万PPS?
我也在做NAT,但还是新手,请楼主指点一下,如何达到5万PPS?还有如何测一台机器的PPS数
非常感谢

作者: test_tmp 时间: 2005-12-06 16:56
怎么没人理我

作者: depthblue_xsc 时间: 2005-12-15 17:17
我正在测试千兆防火墙的性能，64B双向达到线速的15%（30秒的测试时间）
如何能够再提高，系统如何再优化呢？netfilter的效率不高，linux的网络i/o分布不平衡
系统还有什么地方可以优化呢？

作者: Solaris12 时间: 2005-12-15 17:32

原帖由 mirnshi 于 2005-11-23 22:22 发表
目前对于百兆, CPU的速度足够，除非增加各种稀奇古怪的功能进去--什么各种代理过滤之类的。
对于千兆，由于pps增加了，网卡的队列也增加了，考虑到时延问题和中断，以及PCI通道问题，CPU就显得不够用了。内核支持 ...

100M/1000M现在OS一般都handle的了。

上1000个连接达到线速也是没问题的，不需要很强劲的机器。

但是10000M网卡就不一样了，这个需要特别的处理。

感兴趣的话，可以在solaris上测测万兆网卡。

因为本人不是搞防火墙的，所以不了解这方面的问题。

在100M/1000M上，CPU真的不是大问题。
而且先进的网卡都支持HW offload，很多工作不需要CPU来做。

当然这取决与你driver和OS是否充分利用了网卡的先进特性。

在intel e1000和broadcom的网卡上，都有类似的特性。

所以你的dirver和你的OS版本很重要，一定要用支持HW offload的版本

[ 本帖最后由 Solaris12 于 2005-12-15 17:39 编辑 ]

作者: caibird3rd 时间: 2005-12-15 20:54
现在的问题既不是网卡，也不是CPU
而是网络协议及其依赖的OS中断处理机制，而且网卡仅仅支持csum等简单的offload作用不大

原帖由 Solaris12 于 2005-12-15 17:32 发表

100M/1000M现在OS一般都handle的了。

上1000个连接达到线速也是没问题的，不需要很强劲的机器。

但是10000M网卡就不一样了，这个需要特别的处理。

感兴趣的话，可以在solaris上测测万兆网卡。

...

[ 本帖最后由 caibird3rd 于 2005-12-15 20:56 编辑 ]

作者: Solaris12 时间: 2005-12-16 11:22

原帖由 caibird3rd 于 2005-12-15 20:54 发表
现在的问题既不是网卡，也不是CPU
而是网络协议及其依赖的OS中断处理机制，而且网卡仅仅支持csum等简单的offload作用不大

这个问题，既是网卡，CPU，总线，还是OS，更是driver的问题，需要几部分协作：

网卡：提供HW offload机制，目的是减轻CPU的压力，比如check sum offload，LSO，MSI，interruput blanking，甚至是整个协议栈的offload

CPU：NP/SUN的CMT

总线：PCI-X对付1000M绰绰有余

OS: interruput blanking/MSI

dirver: 充分利用OS和网卡提供的这些特性。

目前，Solaris已经支持了interruput blanking，很多dirver也使用了HW offload机制.

相信linux也差不多。所以我说100M/1000M的问题已经解决，目前主要10000M的问题。

关于操作系统的网络方面，我们曾经请SUN的著名工程师eric，也是IEEE的委员，做过一次演讲，请参考下面的网址：

http://blog.csdn.net/yayong/archive/2005/10/22/513676.aspx

http://www.opensolaris.org/os/co ... g-erik_nordmark.pdf

[ 本帖最后由 Solaris12 于 2005-12-16 11:32 编辑 ]

作者: hvtony 时间: 2005-12-16 11:49
标题: linux---firewall
不清楚各位在linux下测试相关性能的时候用的是怎样的linux？是一般的标准发行版本redhat,suse什么的（猜的，不大可能吧

），还是定制的呢？
我在linux下测试的brouter，带防火墙和流量控制，100M网络环境，目前是带了15台服务器，流量跑到11Mbyte/s是轻而易举的，而且看到的负载主要集中于硬件的IRQ上。
对于iptables和conntrack的优化，目前有很多的方法啊，比如ipset和nf-hipac就是不错的选择，就算是iptables在使用的过程中也不会太占用CPU的，我的防火墙规则大概150条左右。
CPU用的是Celern 2.0G的，网卡用的是Intel 1000M，主要是看中了他的NAPI和tso。
对于100M网络，32位的66MHZ的卡肯定是可以的，32*66已经大于100了。

作者: lenn 时间: 2006-01-09 10:50
P4 2.8*2 Xeon CPU下是可以达到这个转发性能的.
我把E1000网卡修改成零拷贝,直接收包,可以达到950Mbps以上,包数可以达到120W,虽然64bit的小包线速达不到,
但是流量是可观的,单个CPU使用70%,
发包的我没有硬件做测试,假如双网卡,使用核心线程作零拷贝发包,也就是包不通过协议栈,假设性能折扣为3/4,那应该也可
以达到600到700Mbps的.如果你有兴趣,我们可以讨论下.
MSN:liangvy@bigfoot.com

作者: sbyond 时间: 2006-01-10 15:20
2006.1.10再来一点补充
上次说错了100万应该是1，000，000,即1000kpps
2.6.14 自编译内核转发峰值155Kpps ,基本能稳定在130kpps
离我希望的400kpps 还有一定差距，继续努力中

作者: guotie 时间: 2006-02-22 13:41
呵呵，不知道楼主的情况如何了。

我刚刚在linux-net的邮件列表上看到的讨论，关于linux net转发率的测试数据：

Yes PCI-X boards is sending around ~800 kpps. With some ugly patches about
300 kpps more.

Intel w. e1000 82546GB @ 133 MHz

60  748406
124  693133
252  452951
508  234982
1020  119742
1496  82242

The BCM PCI-X  *inside* the serverworks H2000 is faster.

BCM w. tg3

60  1421959
124  844572
252  452918
508  234970
1020  119735
1496  82239

Fastest and most intresing sofar is the Intel 82571 Server PCI-E dual
server adapter.

60  1488305
124  844635
252  452835
508  234973
1020  119737
1496  82240

IO latency is worse with PCI-E but the Intel 82571 can handle four
concurrent RX/TX transactions. Also PCI-E is FX this seems to well
handle the PCI-E extra latency.

Stephen I've heard some good things about the Syskonnect PCI-E adapters
any chance you could run a test similar to the tests above?

作者: wheel 时间: 2006-02-22 17:34
8bits的基带数据映射成10bits的数据,保证10bit数据中“0”/“1”信号的数量相等,的确是PCI-E的加速特性，这样不用时钟，PCI-Ex总线在8B/10B编码层之前采用扰频，和K28.0字符时钟补偿。使得高频特性跟好了。

作者: caibird3rd 时间: 2006-02-24 09:01
对于PCI、PCI-X、PCI-E等总线，是否可以认为如下结论成立：
双向同时传输数据时单个方向上的速率是否为完全单向传输速率的一半？

作者: skipjack 时间: 2006-03-01 15:11
标题: 回复 1楼 sbyond 的帖子
40万?要求也太低了吧,100M冰盾软件都能转发25万pps,1000M下至少也是160万啊?(网上你搜一下)
还有什么方正黑杀,dosnipe,神洲盾.....都是一个小黑箱就号称可防数百万pps啊,你要做一个40万的,估计要用到486CPU,这可不好找啊.

作者: lenn 时间: 2006-03-01 15:53

原帖由 skipjack 于 2006-3-1 15:11 发表
40万?要求也太低了吧,100M冰盾软件都能转发25万pps,1000M下至少也是160万啊?(网上你搜一下)
还有什么方正黑杀,dosnipe,神洲盾.....都是一个小黑箱就号称可防数百万pps啊,你要做一个40万的,估计要用到486CPU,这可 ...

软件转发,有这么牛么??

作者: skipjack 时间: 2006-03-01 16:01

原帖由 lenn 于 2006-3-1 15:53 发表

软件转发,有这么牛么??

做syn包判断比转发更耗时吧,再说判断的结果可能就是转发啊,号称是每秒13万个包时不丢包,呵呵

作者: coco520 时间: 2006-04-07 16:17
有种技术叫napi的，从中断入手解决转发效率，效果还可以。lz可以试试。

作者: obrire 时间: 2006-04-07 20:29
标题: 是可以实现的

原帖由 sbyond 于 2005-11-6 01:09 发表
以前作NAT 5万PPS 没有问题（AS4）CPU只到5%左右

现在不需要NAT，只做静态路由转发（）
(route)
echo 1 >/proc/sys/net/ipv4/ip_forward
eth0 1.1.1.1
eth1 2.2.2.1

测试拓扑： client1_----------- ...

此前公司的IP_FORWARD就达到了8,000,000
不过你内核最好修改一下.

至于说到CISCO/华为的产品, 早在冲击波时, 就趴下一大堆(一所学校, 有2K Workstation)
不过Linux还是挺起的.

首先要修改MAX CONNECTION
还有并发的SESSION.
细节参阅/proc/sys/net/ipxx下面的相关记录.

最好是SMP构架, 修改Ether卡的驱动, 大规模启用DMA.
近乎于SUN的IP BOND.也可多台, 实现应用层交换.
1000万的PPS都没问题.看看Google的流量. 一天多少?用IPVS机群, 都可以实现
包括Real Networks流媒体服务器系统.

作者: obrire 时间: 2006-04-07 20:48
标题: 纯软件是达不到QOS要求的

原帖由 skipjack 于 2006-3-1 15:11 发表
40万?要求也太低了吧,100M冰盾软件都能转发25万pps,1000M下至少也是160万啊?(网上你搜一下)
还有什么方正黑杀,dosnipe,神洲盾.....都是一个小黑箱就号称可防数百万pps啊,你要做一个40万的,估计要用到486CPU,这可 ...

纯软件始终要采用OS提供的IP协议栈, 如果仅在Windows下或未经优化的内核, 即便是达到了,
也不合格. 你可以用专业仪器测试一下.

要优化性能, 首先要从物理层开始, 充分利用物理特性(如DShow/DDraw).
如果所用晶片有限, 软件是做不出来的.

至于有人翻译的ZERO COPY, 其实最大限度就是DMA传送.

在OS的MM管理中,你看看当前我们的内存带宽有多大, 然后将各种时延算进去,
最终封包, 发出去, 才知道我们的性能怎么样.

其始在NP/MP之外, CISCO也用Intel的P系列CPU.
只是OS Kernel不一样, 其它也与你的PC一样.

至于传输Channel,以前公司生产光交换, 但也要通过光电转换.
如果光电转换及Cable Drive能力很差, 性能也是跟不上的.

顺便说一下, 目前的电缆也可以传10Gbps.我有朋友就是CISCO全球三大核心晶片(10G平台)供应商之一.
加拿大的,还有一家叫Broadcom的公司也能做, Siemens下的半导体公司也很牛的.

用10Gbps减去各种限制时延和内存封包能力, 就可以从理论上算出我们所要的pps了.

作者: obrire 时间: 2006-04-07 21:04
标题: 有点好笑(GCC)

原帖由 独孤九贱 于 2005-11-22 09:37 发表

不太同意你的话：

1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p3 1G的CPU，64by ...

知道VxWorks的C编译器吗?
其实Intel 的C编译器与GCC也有很多合作,PowerPC一般都采用的GCC, Apple就是(OS是GCC编译的,
Default Compile也是GCC),我看过公司的服务器Apple Server/Power G5 2.0 2 CPU, 性能高得很,
比2 枚AMD 64/2 枚Intel至强同等高很多.

你看过IPP的源码吗? 懂什么叫优化吗? 做过WiMMX优化吗?

如果说VC能优化, GCC不能优化, 可能你根本就没从事过这方面的工作.
NY 的交通系统,就是VxWorks在GCC下编译的.

其实VxWorks提供的ARM平台源码中, 几乎就是GCC定制的一个子集.

知道CELL用什么编译吗?IBM用的是GCC,而SONY美国也在招GNU工作师.

天知道, 怎么会发这样的 B I A 言.

如果说他们是白痴, 总还有一些从比他们更白痴!

作者: skipjack 时间: 2006-04-07 22:13
>>纯软件始终要采用OS提供的IP协议栈, 如果仅在Windows下或未经优化的内核, 即便是达到了,
>>也不合格. 你可以用专业仪器测试一下.
你指的不合格是什么?专业仪器测SMB和IXIA应该说的过去吧

>>要优化性能, 首先要从物理层开始, 充分利用物理特性(如DShow/DDraw).
>>如果所用晶片有限, 软件是做不出来的.
物理层从网线算还是从网卡模块算起?给个结论IA体系的转发极值是多少?

>>至于有人翻译的ZERO COPY, 其实最大限度就是DMA传送.
这个了解,但真正意义上的包转发线速和DMA没必然的联系,DMA主要还是为了用于解决收包时的瓶劲,但NP/MP还是靠微引擎的并行度

>>OS的MM管理中,你看看当前我们的内存带宽有多大, 然后将各种时延算进去,
>>最终封包, 发出去, 才知道我们的性能怎么样.
很迷惑了,看不出其间的联系,软硬中断都不考虑在内是吗?

>>其始在NP/MP之外, CISCO也用Intel的P系列CPU.
>>只是OS Kernel不一样, 其它也与你的PC一样.
那是因为IA构架在某种应用时优于NP/MP

>>至于传输Channel,以前公司生产光交换, 但也要通过光电转换.
>>如果光电转换及Cable Drive能力很差, 性能也是跟不上的.
就这句知道是什么意思

>>顺便说一下, 目前的电缆也可以传10Gbps.我有朋友就是CISCO全球三大核心晶片(10G平台)
>>供应商之一.加拿大的,还有一家叫Broadcom的公司也能做, Siemens下的半导体公司也很牛的.
>>用10Gbps减去各种限制时延和内存封包能力, 就可以从理论上算出我们所要的pps了.
为什么是10G而不是100G,好像10G是个极限似的?如果是,怎么算出来的?

作者: skipjack 时间: 2006-04-07 22:26
>>知道VxWorks的C编译器吗?
知道

>>其实Intel 的C编译器与GCC也有很多合作,PowerPC一般都采用的GCC, Apple就是(OS是GCC编译的,
>>Default Compile也是GCC),我看过公司的服务器Apple Server/Power G5 2.0 2 CPU, 性能高得很,
>>比2 枚AMD 64/2 枚Intel至强同等高很多.
你是说这个性能提升都是编译器的功劳?

>>你看过IPP的源码吗? 懂什么叫优化吗? 做过WiMMX优化吗?
没懂没做过

>>如果说VC能优化, GCC不能优化, 可能你根本就没从事过这方面的工作.
>>NY 的交通系统,就是VxWorks在GCC下编译的.
倒~勇气号也是VxWorks,NY的交通系统能说明GCC什么?您到底想说明什么问题?

>>其实VxWorks提供的ARM平台源码中, 几乎就是GCC定制的一个子集.
您这么一解释,我都快不知道VxWorks和xscale,那个是OS那个是CPU了

>>知道CELL用什么编译吗?IBM用的是GCC,而SONY美国也在招GNU工作师.
>>天知道, 怎么会发这样的 B I A 言.
>>如果说他们是白痴, 总还有一些从比他们更白痴!
知道CELL是IBM的多核,但这能说明GCC什么呀?看了您的贴子,我怎么感觉头有点晕啊.

作者: skipjack 时间: 2006-04-07 22:34
>>此前公司的IP_FORWARD就达到了8,000,000,不过你内核最好修改一下.
几网口,上面这个数字的单位是什么?只修改内核就可以了?不会是软件控制硬件的bypass功能吧?

>>至于说到CISCO/华为的产品, 早在冲击波时, 就趴下一大堆(一所学校, 有2K Workstation)
>>不过Linux还是挺起的.
呵呵....告诉我拓朴和环境,就像你说Google流量大,但我的机器却安然无样一样.

>>首先要修改MAX CONNECTION
>>还有并发的SESSION.
>>细节参阅/proc/sys/net/ipxx下面的相关记录.
开始胡说八道了

>>最好是SMP构架, 修改Ether卡的驱动, 大规模启用DMA.
>>近乎于SUN的IP BOND.也可多台, 实现应用层交换.
>>1000万的PPS都没问题.看看Google的流量. 一天多少?用IPVS机群, 都可以实现
>>包括Real Networks流媒体服务器系统.
春风吹~战鼓擂了

作者: obrire 时间: 2006-04-08 11:58

原帖由 skipjack 于 2006-4-7 22:13 发表
>>纯软件始终要采用OS提供的IP协议栈, 如果仅在Windows下或未经优化的内核, 即便是达到了,
>>也不合格. 你可以用专业仪器测试一下.
你指的不合格是什么?专业仪器测SMB和IXIA应该说的过去吧

> ...

至于专业的NP/MP，也就是专业的ASIC，将路由算法内置于其中．就像有些DSP一样，将算法内置．
这不新鲜．AXIS就将一个ARM 920核和4M Memory和4M Flash内置，还有一些算法．PMC以前有
些Chip,在PMC自己做的VoIP上，在泰尔测试时，时延都比较大，你不迷信ASIC.这只能HU外行．ASIC
设计也有水平高低，也有算法逻辑的优劣，不同公司出品的，以及新的技术的加入，这都会影响最终
对数据包的处理能力的．如果你的NP运算能力有限，我就用两枚P IV加优化了的软件算法，也是可以
达到的，有时还可以超出，以前有朋友帮Intel做一个NP的驱动，NP好贵．现在有一种便宜的做法是
用VS机群来取代这种方式．他最终受限于总线．就你DVR系统一样，如果IDE接口受限，你可以使用
Fiber Channel/IEEE 1394B等．NP最终还是要和其它电路接口的，各种接口也是一种限制．就像在
通信中，FREEDM的能力一样，HDLC链路成帧就是专门的ASIC，但要工作，还得接入我的计算机系统
才行呀．你写的Driver就直接影响性能吧．当时我看了IBM和DELL的两台服务器，同样的配置，但IBM
的整体性能就要好一点，只是相差不很大而已.(TPCC测试)

但在通信领域，目前在10G平台，做得最好的就是Juniper．其实我就怀疑港湾就是OEM他们的，
或者是给Juniper提供核心的公司的．CISCO还要慢一步．

至于有人谈到10/100G，光键是在MSTP上，SDH一般以10G单波为基础．至于DWDM，只是多波
复用（密集波分），所以一般以10G为一技术基准．如果全光交换及交叉，是没问题的，但我们的其它
接入系统是电接口，因此必须有光电转换．因此单通道以10G为基准．谈1T没实际意义，这只是在传
输干线才使用，肯定是国家级干线，或国际干线，都是DWDM．光纤在理论是带宽是无限宽的．

其实就是你家的有线电视线，或电气特性有些差异，在短距离是可以传10Gbps的数字信号的．也就
是说，在电接口方面，好的网线也可以达到10G数字带宽，这是很难的．3.5G->5G->10这是其技术
发展路线．我不肯定，这会用到OFDM调制．在电力线上要达到100Mbps，必使用OFDM.

我们公司原来的路由器是Intel的，但他的性能是稳定的，如果是高性能，就谈不上了．如果P2P并发太
多，肯定会死的．在CISCO 3000/4000中，你用目前的通用CPU，选好的PHY接口CHIP，不是RTL的，
最好是Broadcom的，你看看是你的快，还是CISCO的路由器好吧．只能说Linux下，IP性能上稍差于BSD
Unix，如果优化一下，或使用VxWorks提供的，那就不一样了．而华为/CISCO等，还不是基于VxWorks
做的．其实将IP Stack放入ASIC或置于计算机中，差异不是很大，要可配置，必然内存等级与你用的差不
多，访问时间也差不多．有时在通信CPU中，MIPS值可能很高的．一般可以达到5000-8000，就是DSP
也不行呀．DSP目前最快的也就1GHz．如果我的CPU也做专项运行，上Embedd OS，性能还要优于这些
专用的ASIC．如果专门来做路由及应用交换，用VS是首选，我的内存可以很大呀，专用的ASIC不可能集成
很多内存的，扩展不就与我的一样了吗？关键是ASIC各X86计算机，在MII层要好的芯片，不然性能差异较大．

好多人说100Mbps，看看你的各种网卡，测出来都什么样吧．有些高于，有些还达不到．

只能说，专门的如Juniper的T640这种设备，各个环节都是相适应的．

但这些由专业厂商做的东东，没有几M　RMB是拿不下来的．他是直接上干线，下行至你的Workstation．

所以人家才牛嘛．

[ 本帖最后由 obrire 于 2006-4-8 12:18 编辑 ]

作者: obrire 时间: 2006-04-08 12:06
标题: 当时我们公司也有80台交换机

原帖由 skipjack 于 2006-4-7 22:34 发表
>>此前公司的IP_FORWARD就达到了8,000,000,不过你内核最好修改一下.
几网口,上面这个数字的单位是什么?只修改内核就可以了?不会是软件控制硬件的bypass功能吧?

>>至于说到CISCO/华为的产品, 早在 ...

这是2003年的夏天．
不仅如此，就是联通和电信的机房，也比较忙的．因为当时的软件中没有对连接会话进行限制．

如果NAT，他限也限不了呀．我内网中IP时时变．

后来，我们设计了程序，一旦发现过多的报文来自同一MAC，就封了．并对各种状态进行过滤．
当然这会让性能下降．不过计算性能较高，P IV对小网足够了．

如果2W 用户，每人100连接，不修改，你看Linux不Crash才怪．好像IP默认最大连接不超
过10万（我在Windows下，记不起了）

内网100Mbps／外网100Mbps.如果交换机没有流控，你看看倒不倒.

作者: obrire 时间: 2006-04-08 12:16
标题: 上海电信 Web Cache

原帖由 skipjack 于 2006-4-7 22:34 发表
>>此前公司的IP_FORWARD就达到了8,000,000,不过你内核最好修改一下.
几网口,上面这个数字的单位是什么?只修改内核就可以了?不会是软件控制硬件的bypass功能吧?

>>至于说到CISCO/华为的产品, 早在 ...

这是基于Linux做的，国内还有朗新用FreeBSD做的．

如果这不能说明问题，我就无话可说了．这是IPVS发起人的弟弟布置的．在2003年可以是挺得很直哟．
当时好多CISCO倒下了．

有些人说话要有证据才行呀．英国Tunsys超级计算机公司的设计也是基于二层交换，VS做的．这在
FBI用了很多哟．

IPVS目前已经并入Linux 2.6的内核中．是章文嵩博士发起的．有什么问题，你可以向他提问．

先看看在IBM上他的算法吧．不过有人以后用这些前沿技术，记得向开发者致敬呀，别像TurboLinux，
很没道德．IBM赞助了章在世界各地讲学呀，IBM在网格计算中，应当会有这些技术的身影．

中国人呀，首先要有道德，不能乱整，没修养．

作者: skipjack 时间: 2006-04-08 15:25

原帖由 obrire 于 2006-4-8 12:16 发表

这是基于Linux做的，国内还有朗新用FreeBSD做的．

如果这不能说明问题，我就无话可说了．这是IPVS发起人的弟弟布置的．在2003年可以是挺得很直哟．
当时好多CISCO倒下了．

有些人说话要有证据才行呀．英 ...

谢谢,虽然你说的我现在不能全部理解,但至少有了个全面的了解.哈哈......你说的这些环境,我还都没有机会见到过.Juniper的性能很高,就像你说的转发时把路由算法内置了.但像内容过滤这类的应用.现在他可以内置了吗?因为netscreen在连接率上受限于ASIC芯片,也不是什么强项.只听说过Tcom之类的芯片,但应用中还没有触及过.类似的还有正则表达式匹配芯片等等,它们的瓶劲在那里?

作者: obrire 时间: 2006-04-08 17:03
标题: 回复 71楼 skipjack 的帖子
内容过滤在第四层及以上层面
也就是有人所说的七层交换, 这里已经没有传统路由的概念了.
新技术的发展, 以前的定义和说法是需要局部限定的.
以前说LAN是局部的, 如果采用IP->E1映射, LAN也可以从上海到北京.

作者: chjingsi 时间: 2008-02-14 10:38
标题: 请教，哪有IPTABLES/NF-HIPAC的算法介绍
热心的朋友们，请指点一下NF-HIPAC的算法简介，谢谢！

作者: AIXHP 时间: 2008-02-14 14:43

原帖由 sbyond 于 2005-11-6 01:09 发表
以前作NAT 5万PPS 没有问题（AS4）CPU只到5%左右

现在不需要NAT，只做静态路由转发（）
(route)
echo 1 >/proc/sys/net/ipv4/ip_forward
eth0 1.1.1.1
eth1 2.2.2.1

测试拓扑： client1_------------ ...

需要高速高效网卡如10000M, 且其驱动程序要好. 高速多CPU主机大内存,仅进行包处理,可能的化对内核进行裁减[文件系统软中断网络协议栈等处. -----------不知可否达到要求.内核版本可适当高一些,尽量减少设备和内核选项.和不必要的功能,可能的话使内核使用1GB以上内存.

[ 本帖最后由 AIXHP 于 2008-2-14 14:51 编辑 ]

作者: obrire 时间: 2008-05-19 02:42

原帖由 skipjack 于 2006-4-8 15:25 发表

谢谢,虽然你说的我现在不能全部理解,但至少有了个全面的了解.哈哈......你说的这些环境,我还都没有机会见到过.Juniper的性能很高,就像你说的转发时把路由算法内置了.但像内容过滤这类的应用.现在他可以内置 ...

好久没有时间来回这种问题, 其实在应用层交换数据是相当麻烦的事, 已经不单是下三层的简单数据处理问题了, 与ASIC相关的优化, 一方面是软件核心代码的优化; 另一方面可采用并行译码(这都是后来一位做FPGA的兄弟说的, 在多媒体数据处理时, 怎样优化速度, 将算法交由硬件译码器并行处理), 这对高速数据采集, 并实时转发很有用. 不过ASIC设计也要修正优化才行. 不过, 我对FPGA不是很在行, 如果他不讲, 我也不知道他怎么加速译码. 可能他们讲了, 原理上我就会明白了. 好像他们FPGA中也有一个软核, 可以支持ARM IP.

现在已经没有时间去关心网络方面的发展了, 重心已经移至移动终端方面. 不过想在技术方面上升一层次, 学软件的最好还是看看Intel的有关IPP算法方面的资料.

作者: iterator 时间: 2008-05-21 11:06

原帖由 colddawn 于 2005-11-22 11:13 发表
1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！

理解！不过这也证明目前市面上的很多国产设备的现状以及国内这个领域的研发状况，不做评价

2、请贴出你的freebsd能 ...

想问个弱问题,为什么在最高的流量下,CPU也达不到100%呢?这是否一定意味着CPU可以处理更高的流量?
此外,CPU负载值(就是1,5,15分钟)那个是怎么计算出来的.
这两个问题一直不太懂.

作者: zzkaska 时间: 2014-08-28 22:19
2.6的内核转发门限在300kpps,3.0以上的可以提升30%。再高X86架构必须用dpdk了。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)