以前作NAT5万PPS没有问题（AS4）CPU只到5左右
现在不需要NAT，只做静态路由转发（）
(route)
echo1>/proc/sys/net/ipv4/ip_forward
eth01.1.1.1
eth12.2.2.1
测试拓扑：client1_------------------linuxroute---------------------client2
1.1.1.22.2.2.2
希望能够达到至少100万pps
用linux好还是用freebsd好（我不迷信freebsd，未经实测没有根据的建议谢谢大家不用提了），如果用linux的话用那个linux比较好
希望大家给一下建议。
按我的理解应最大程度的减少linux转发ip包的处理过程（那位大侠给个ip包通过linuxforward的流程？我找到了一个不太详细的
网卡---被驱动程序接收进入）
内核中有什么地方优化可以提高包转发能力（包括配置上的和内核代码上的）
恭候指点！
#2006.1.10再来一点补充
上次说错了100万应该是1，000，000,即1000kpps
2.6.14自编译内核转发峰值155Kpps,基本能稳定在130kpps
离我希望的400kpps还有一定差距，继续努力中
[本帖最后由sbyond于2006-1-1015:13编辑]
--------------------------------------------------------------------------------
bingosek回复于：2005-11-0602:09:48
1000Kpps,好像有点难度哦,cisco2600我记得就那么几十Kpps
--------------------------------------------------------------------------------
platinum回复于：2005-11-0609:10:51
1000MBps线速才148.8Wpps，你这个100Wpps快达到千兆线速了，X86构架是没戏的，只能考虑NP构架了
--------------------------------------------------------------------------------
caibird3rd回复于：2005-11-0612:12:14
引用：原帖由platinum于2005-11-609:10发表
1000MBps线速才148.8Wpps，你这个100Wpps快达到千兆线速了，X86构架是没戏的，只能考虑NP构架了
148.8Wpps是怎么来的？X86的限制在哪里呢？
--------------------------------------------------------------------------------
platinum回复于：2005-11-0613:29:35
包转发线速的衡量标准是以单位时间内发送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-0710:18:59
100Wpps是可能的。
--------------------------------------------------------------------------------
guotie回复于：2005-11-0710:54:52
你可以使用bridge，转发效率更高。
--------------------------------------------------------------------------------
cx6445回复于：2005-11-0717:05:19
x86构架不差的，我现在用的网络设备x86的工控机，修改过的freebsd4.X，专用软件。每秒http请求近1万，并发连接10多万，流量进600兆出700兆，还是做nat 负载均衡的。比很多所谓的专用构架专用芯片的网络设备强得不止一个档止。
[本帖最后由cx6445于2005-11-717:29编辑]
--------------------------------------------------------------------------------
platinum回复于：2005-11-0717:44:03
引用：原帖由cx6445于2005-11-717:05发表
x86构架不差的，我现在用的网络设备x86的工控机，修改过的freebsd4.X，专用软件。每秒http请求近1万，并发连接10多万，流量进600兆出700兆，还是做nat 负载均衡的。比很多所谓的专用构架专用芯片的网络设备强得不...
这个是用来做什么的？服务器还是NAT设备还是什么？
是否统计过pps有多少？我想知道^_^
--------------------------------------------------------------------------------
skylove回复于：2005-11-0720:19:12
引用：原帖由cx6445于2005-11-717:05发表
x86构架不差的，我现在用的网络设备x86的工控机，修改过的freebsd4.X，专用软件。每秒http请求近1万，并发连接10多万，流量进600兆出700兆，还是做nat 负载均衡的。比很多所谓的专用构架专用芯片的网络设备强得不...
你用的什么webserver?能单机支持这么多连接请求...
--------------------------------------------------------------------------------
cx6445回复于：2005-11-0723:15:12
晕倒，说了是网络设备呀，做负载均衡加imagecache和tcpoffload。
--------------------------------------------------------------------------------
platinum回复于：2005-11-0723:26:11
pps到了多少？硬件配置又是什么样子的？
--------------------------------------------------------------------------------
cx6445回复于：2005-11-0723:34:21
就是这种产品，是我用过最爽的网络设备，web界面和性能都非常出色的。不象有些知名网络设备,官方标称和实际使用根本两回事。
目前我看到过最高的时候pps好象是20万
好象有做广告嫌疑，呵呵！不过新浪用得很爽的。
[本帖最后由cx6445于2005-11-800:08编辑]
--------------------------------------------------------------------------------
platinum回复于：2005-11-0800:04:37
这个东西成本也低不了吧:shock:
--------------------------------------------------------------------------------
cx6445回复于：2005-11-0800:14:54
当然不便宜了，我原意只是想说x86构架不差的，也不是说其它的构架不好。
--------------------------------------------------------------------------------
causky回复于：2005-11-0822:04:08
发连接10多万??太假了
--------------------------------------------------------------------------------
guotie回复于：2005-11-0910:22:17
x86架构服务器，上两个cpu，linux应该可以轻松达到50Wpps以上的纯粹转发效率
--------------------------------------------------------------------------------
platinum回复于：2005-11-0910:41:48
“纯粹转发效率”指什么？
--------------------------------------------------------------------------------
guotie回复于：2005-11-0911:10:24
指仅仅转发数据包。
--------------------------------------------------------------------------------
platinum回复于：2005-11-0911:31:24
X86构架很难做千兆的网络设备，PCI总线不够大，不知道PCI-E的133出来以后，再配上64位处理器能否实现
--------------------------------------------------------------------------------
cx6445回复于：2005-11-0913:12:17
X86构架是指处理器的构架吧，又没说一定要使用pci的。
[本帖最后由cx6445于2005-11-913:15编辑]
--------------------------------------------------------------------------------
platinum回复于：2005-11-0913:44:50
引用：原帖由cx6445于2005-11-913:12发表
X86构架是指处理器的构架吧，又没说一定要使用pci的。
愿听详解^_^
--------------------------------------------------------------------------------
cx6445回复于：2005-11-0921:25:05
:oops::oops:
没有什么详细的，一般厂商都不会自己开发总线系统的，成本高难度大。好象PCI－X构架用着就不错了。
事实就是：
FreeBSD4.4-RELEASE
CPU:Pentium4(3065.00-MHz686-classCPU)
realmemory=3893362688(3802112Kbytes)
pci2:
onpcib2
bx1:<3Com3C996SXGigabitFiber-SXServerNIC>
bx1:PCIXtargetworkaraund[本帖最后由cx6445于2005-11-921:26编辑]
--------------------------------------------------------------------------------
caibird3rd回复于：2005-11-1008:51:50
据我所知，它的性能主要来自：
网络硬件采用交换架构，即使用交换机板，并且使用了专用硬件加速芯片（这个占了一大半成本）
现在要做这类高性能设备，没有硬件支持是不行的了
能更详细的介绍一下你们用的这款产品的硬件配置吗？把你在FreeBSD下看到的输出都列一下罗
我们现在用一款纯软件实现的产品，进出各能达到近500兆，好像到瓶颈了。不过你说的进出600/700兆，
好像吞吐量也不是很大嘛，不知最大能到多少？
引用：原帖由cx6445于2005-11-723:34发表
就是这种产品，是我用过最爽的网络设备，web界面和性能都非常出色的。不象有些知名网络设备,官方标称和实际使用根本两回事。
目前我看到过最...
[本帖最后由caibird3rd于2005-11-1009:14编辑]
--------------------------------------------------------------------------------
cubzsdb回复于：2005-11-1416:23:02
不是有PCI64BIT吗?
--------------------------------------------------------------------------------
ahuoo回复于：2005-11-1500:08:58
兄弟是否在做防火墙之类的产品？
--------------------------------------------------------------------------------
mirnshi回复于：2005-11-1516:03:04
x86架构是指cpu的指令集是i386的，pci和cpu没有关系，好多arm指令集的嵌入式板子也采用pci总线。pci是以Intel为首的弄的，
目前工控板服务器板都是x86 pci总线的，由于包处理都是需要网卡经总线由cpu处理。目前CPU的速度是足够快了，但是pci总线却无法满足速度要求。
想开发一套自己的总线是没有问题，关键在于周边的设备，诸如网卡芯片都是PCI之类的，当然有钱还可以接着开发自己的网络处理芯片，于是变成了NP。
作千兆还是不要用FreeBSD4.x的好，内核不支持多线程。可以用6.0或者换成Linux
--------------------------------------------------------------------------------
wxxszzz回复于：2005-11-1622:02:58
主要还是现在的主板都是PCI总线结构的，
只有133速率，即每秒133M/s
跑个百兆网络转发还差不多，
即使是跑百兆网络，在内网机器多的情况下，内网的网卡最好还是用千兆或者是双百兆网卡，及一块外网百兆网卡。否则内网网卡错误的IP包就会很多的。可通过ifconfig查看到。
因为内网有很多包并不需要到外网去，所以内网网卡的工作量比外网网卡多的多。
一般现在的815芯片到865芯片架构的主板做内外构通的话，合理，经济的方式就是
就是两块百兆内网网卡做bond绑定负载轮流接内网交换机，不需要交换机支持绑定的，用个现在通用的
DLINK1024R 即可。。
一块外网百兆网卡接ISP商。
基本可以跑到百兆速度极限。如果ISP没做流量控制的话。
换算成字节的话就是每秒11.5m/s左右。
你可以用FTP软件传一个大文件试试就行了。
如果是bit的话就是11.5*8m/s左右。
--------------------------------------------------------------------------------
caibird3rd回复于：2005-11-1710:17:59
引用：原帖由wxxszzz于2005-11-1622:02发表
主要还是现在的主板都是PCI总线结构的，
只有133速率，即每秒133M/s
跑个百兆网络转发还差不多，
...
每秒133M/s是什么东东？
--------------------------------------------------------------------------------
colddawn回复于：2005-11-1716:42:08
楼上说的正解，cpu指令集和总线架构是2回事，pci确实不行了，32bit，133Mhz，算算带宽百兆多点，稍微高点的应用就不行了，所以民用领域推出agp，服务器领域推出pci-X，但目前的趋势是统一回pci-E。
去intel的网站看看intel的网卡型号吧，824XX，825XX，总共几十个型号，都是有区别的，有pci的，有pci-X66MHz的，有pci-X133Mhz的，还有pci-E的，甚至有dualport，quardport的，说明一旦用上pci-X以上级别的总线，网卡绝对是能跑那么大带宽的，所以不必觉得X86不行了。
--------------------------------------------------------------------------------
caibird3rd回复于：2005-11-1721:37:03
32bit,133Mhz，我怎么算出来是500多兆字节呀？4个Gbit/s啊
感觉处理大流量的瓶颈还是在CPU上，光是系统中断的处理就是不小的一块了
引用：原帖由colddawn于2005-11-1716:42发表
楼上说的正解，cpu指令集和总线架构是2回事，pci确实不行了，32bit，133Mhz，算算带宽百兆多点，稍微高点的应用就不行了，所以民用领域推出agp，服务器领域推出pci-X，但目前的趋势是统一回pci-E。
去intel的网站...
--------------------------------------------------------------------------------
q1208c回复于：2005-11-1722:19:11
引用：原帖由platinum于2005-11-911:31发表
X86构架很难做千兆的网络设备，PCI总线不够大，不知道PCI-E的133出来以后，再配上64位处理器能否实现
PCI-X是64bit133MHz的.应该能够用的.但好象一台机器也就支持一个133Mhz的然后就只能是两个100Mhz的.再下来就是66Mhz的了.
X86应该是没什么大问题的.CheckPoint还不是多数放在x86上跑了.只不过要优化一下,咱那PC可能差一点.
--------------------------------------------------------------------------------
阿辉回复于：2005-11-1809:55:27
我想这个可能是LINUX性能的问题，不知楼主用的是什么网卡，驱动是哪的？有时候换个驱动会快很多。现在有一个技术叫零拷贝。还有如果你是按到交换机上。也要看看交换机是否能达到那么高。有些交换机比较慢。建议用3com的。
--------------------------------------------------------------------------------
colddawn回复于：2005-11-1810:08:05
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-X2.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-E1X单向传输250MBps，双向也就500了，同时pci-e的倍速最高可达16X，多少就自己乘吧，要注意的是pci-e不存在共享问题，也就是说挂在总线上的任何一个设备都会达到这个速度而不是所有设备带宽的总合。下面引用一篇文章的一段，感兴趣的自己看一下：
在工作原理上，PCIExpress与并行体系的PCI没有任何相似之处，它采用串行方式传输数据，而依靠高频率来获得高性能，因此PCIExpress也一度被人称为“串行PCI”。由于串行传输不存在信号干扰，总线频率提升不受阻碍，PCIExpress很顺利就达到2.5GHz的超高工作频率。其次，PCIExpress采用全双工运作模式，最基本的PCIExpress拥有4根传输线路，其中2线用于数据发送，2线用于数据接收，也就是发送数据和接收数据可以同时进行。相比之下，PCI总线和PCI-X总线在一个时钟周期内只能作单向数据传输，效率只有PCIExpress的一半；加之PCIExpress使用8b/10b编码的内嵌时钟技术，时钟信息被直接写入数据流中，这比PCI总线能更有效节省传输通道，提高传输效率。第三，PCIExpress没有沿用传统的共享式结构，它采用点对点工作模式（PeertoPeer，也被简称为P2P），每个PCIExpress设备都有自己的专用连接，这样就无需向整条总线申请带宽，避免多个设备争抢带宽的糟糕情形发生，而此种情况在共享架构的PCI系统中司空见惯。
由于工作频率高达2.5GHz，最基本的PCIExpress总线可提供的单向带宽便达到250MBps（2.5Gbps×1B/8bit×8b/10b=250MBps），再考虑全双工运作，该总线的总带宽达到500MBps—这仅仅是最基本的PCIExpress×1模式。如果使用两个通道捆绑的×2模式，PCIExpress便可提供1GBps的有效数据带宽。依此类推，PCIExpress×4、×8和×16模式的有效数据传输速率分别达到2GBps、4GBps和8GBps。这与PCI总线可怜的共享式133MBps速率形成极其鲜明的对比，更何况这些都还是每个PCIExpress可独自占用的带宽。
总之写这么多废话，目的就是说明就系统总线来说，承受高带宽，高pps是没问题的。
再上面有人说即使总线没限制，cpu也会成为瓶颈，这话有一定道理，其实关键在于高pps带来的恐怖中断flood，其实对于这么高的中断，i386的apic（高级中断控制）是完全处理的来，瓶颈是在操作系统的中断处理程序上了，这方面问题就由操作系统来解决了，所以不是什么不可能完成的任务，实际上目前也都有很成熟的方案了，比如BSD系统的网卡Polling，Linux也有，具体叫什么我忘记了。
还是那句话，别对i386没信心，也别对目前的PC架构计算机的能力有任何怀疑，事实证明，这样的搭配至少能满足90的应用需要。
--------------------------------------------------------------------------------
caibird3rd回复于：2005-11-1815:51:04
目前，linux作为一种通用的操作系统，
的确跟不上超高速网络流量处理的需求了
不知在这方面有什么linux的改进项目没有？
听说通过精简优化其TCP/IP堆栈可以获得近20的性能提升，不知有没有这回事？
觉得关键还在系统中断方面，真是成也萧何，败也萧何！
引用：原帖由colddawn于2005-11-1810:08发表
sorry，前面提供资料有误，现在更正一下，
最初PCI总线是32bit，33Mhz，这样带宽为133Mbps。
接着因为在服务器领域传输要求Intel把总线位数提高到64，这样又出现了2种PCI总线，分别为64bit/33Mhz和64bit/66Mhz...
--------------------------------------------------------------------------------
colddawn回复于：2005-11-2109:15:21
引用：原帖由caibird3rd于2005-11-1815:51发表
目前，linux作为一种通用的操作系统，
的确跟不上超高速网络流量处理的需求了
不知在这方面有什么linux的改进项目没有？
听说通过精简优化其TCP/IP堆栈可以获得近20的性能提升，不知有没有这回事？
觉得关键...
优化协议栈的工作确实有人在搞，性能提升20的说法只是听说，没见有实际证据，至于linux不能应付搞网络流量处理的问题，请问您是从哪里得来的？有没有实际数据？所谓高速网络高到什么程度？高流量还是高pps？
--------------------------------------------------------------------------------
wheel回复于：2005-11-2110:28:11
pci-e现在可以比pci-X达到跟快的速度了，现在ic设计里，并行的发展已经达到一个瓶颈，因为频率的提高，分布和泛生也随之更复杂，所以设计同样性能的一个PCB,使用PCI-E比X会容易的多，并且现在Synopsys和Cadence对于PCI-e的IPcore的公布，新的主板使用E代替X的会越来越多，X的线真的太多了，串扰太难搞了，最少要6层板才搞的定，E就好搞到多，几个蛇部就过去了。其实从时序分析上看不出X比E的优点在那，可能还是在产品链上把。
--------------------------------------------------------------------------------
独孤九贱回复于：2005-11-2116:04:46
引用：原帖由colddawn于2005-11-2109:15发表
优化协议栈的工作确实有人在搞，性能提升20的说法只是听说，没见有实际证据，至于linux不能应付搞网络流量处理的问题，请问您是从哪里得来的？有没有实际数据？所谓高速网络高到什么程度？高流量还是高pps？
偶见过许过权威的测试报告，测试过国内很多用linux作的防火墙、安全网关……等一大堆东东，用smartbit来测：
pIII1G的CPU，可以达到35/64bytes左右。freebsd的话，稍好一点，不过也仅是“稍”；离线速差得太远了。
————————————————————
这个还只是100M，如果1000M的话，更是惨……即使是双至强的CPU。
偶某高校的朋友用四至强的服务器，达到了1000M线速……不过成本也太……
——————————
性能不佳，有硬件的原因，也有软件的原因。不过就目前Linux的这种定位、目前这种网络堆栈架构来看，短时间要提高，是不太现实的。
所以，只能希望通过硬件来提升，只是通用X86架构，同样，定位也不是专门针对此的，所以……
关于X86的这点，偶同志从CPU的角度，有一篇精典论述：
听说，ixp1200以上，powerNP高频的CPU可以达到线速。也看过一些硬件厂商产品发布会现场演示，的确如此，不过本人没有亲自试过，不敢肯定……
--------------------------------------------------------------------------------
colddawn回复于：2005-11-2209:16:42
引用：原帖由独孤九贱于2005-11-2116:04发表
偶见过许过权威的测试报告，测试过国内很多用linux作的防火墙、安全网关……等一大堆东东，用smartbit来测：
pIII1G的CPU，可以达到35/64bytes左右。freebsd的话，稍好一点，不过也仅是“稍”；离线速差得...
请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了linux iptables再套个外壳实现的，要知道光netfilter架构处理占用的cpu时间就高达30，如果再加上那个性能风传非常差的conntrack的话，这个结果不出奇，这并不能说明是总线瓶颈或者是cpu瓶颈，另一方面，即使是你说的35的带宽利用率，你有统计过那时中断/s的数量吗？有证据证明是cpu中断处理不过来了吗？
linux的我倒真是没测试过，但是同样是p31G，板载pro100，我装过freebsd，仅仅使用ipfw bridge做透明防火墙，连内核都没有优化过，轻松达到80M，无延迟，无丢包，100线速说不上，但90M的时候的丢包率也是基本可以忽略不计。
如果一个1000M包转发的设备都要用4路Xeon，那24口千兆三层交换或者路由器岂不是要大型机？
--------------------------------------------------------------------------------
独孤九贱回复于：2005-11-2209:37:09
引用：原帖由colddawn于2005-11-2209:16发表
请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了linux iptables再套个外壳实现的，要知道光netfilter架构处理占用的cpu时间就高达30，如果再加上那个性能风传非常差的conntrack的话，这个结果不出...
不太同意你的话：
1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p31G的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关于这个的经典论述<部份地方稍有修改>：
[color=Red]一.线速[/color]
线速转发是对一个网络中转设备的理想要求。但平时大多数人都关注着设备的bps（bitspersecond，每秒数据的位数），很少人会想到fps（framepersecond，每秒数据的帧数）实际上更考验设备的转发能力。
简单的说，bps是指每秒钟有多少字节的数据经过，fps是每秒钟有多少个数据包经过。
以10Mb的网络来说，线速时bps为10M，fps最大值为14880。
那么这个14880是怎么计算出来的呢？
首先我们要知道几个规定：
1.以太网内最小的数据包的大小为64字节，它包括4字节的CRC，2字节的以太网类型（或长度），6字节的源Mac地址，6字节的目的Mac地址以及46字节的负荷。
2.以太网帧与帧之间至少要有96位（12字节）的帧间隙（IFP，interframegap）以确保区分两个数据包。
3.每个数据帧开始之间必须要有8字节的Mac地址前导位（MACpreamble）以确保发送方接收方同步数据位。
因此，以太网内最小的数据包实际上是64 12 8=84字节=672位。
于是，10M网络环境下fps的最大值就是
10M位每秒/672位每帧=14480帧每秒。
同理，我们可以算出10M网络环境下fps的最大值为
10M位每秒/((1518 12 8)*8)位每帧=812帧每秒
而100M网络环境下这两个值分别为148809和8127。
[color=Red]二.处理能力[/color]
我们已经知道了线速情况下最大的fps值，现在我们看看要达到线速所需要的处理能力。
假设市面上某防火墙的是X86架构的CII900Mhz的CPU，即每秒钟可以分成900M个时钟周期。
于是，在100M的网络环境下，处理一个数据帧所允许的最大时钟周期为：
900M时钟周期每秒/148809帧每秒=6048时钟周期每帧
也就是说，要达到线速转发，900Mhz的CPU平均要在6048个时钟周期内完成对一个数据包的处理。
这只是理想情况，基于x86架构的系统里CPU还要负责各类中断（如系统时钟）的处理，每次中断时都要保存当前的运行状态，切换到中断处理程序，等中断处理完后，再恢复当前状态，切换回原来的处理流程。光是这个切换过程至少都要费上500个时钟周期，还不包括中断处理程序所用的时钟周期。好在这类中断还”不算“频繁，扣除系统这部分开销后，真正分摊到每个数据包的处理时间平均大约还有5500个时钟周期。
虽然IntelP3以上级的CPU如CII在设计指令集时已经将大量常用的指令（如两个寄存器相加/减）优化到可以在一个时钟周期内完成，但做为防火墙，更常用的是读/写内存数据（比如要比较源地址，计算IP的校验和等）这类多时钟周期的指令，所以5500个时钟周期内大约只能执行2000条指令。
对一个数据包的处理，从为这个数据包分配内存起，依次要检查以太网络协议（如果是RFC1042格式的数据包还要跳过LLC头找真正的以太网络协议），检查IP头、校验和（如果是TCP/UDP协议还要计算对应的校验和），DoS防御，状态检测，NAT规则，安全/统计规则，更新ARP/路由表，选择转发网卡，直到最终把这个数据包添加到发送队列中才算完成。
你认为2000条x86的指令能完成这一切吗？
[color=Red]三.现实数据[/color]
2000条指令看起来很多，实际上并不多，举个例子，要完成最简单的A=A B这个算式最优化的指令也要用上两条：
moveax,[val_B]
add[val_A],eax
未优化的会用上四条：
moveax,[val_A]
movebx,[val_B]
addeax,ebx
mov[val_A],eax
目前的防火墙的开发大多是在Unix/Linux上完成的，以GCC编译器为例，它的优化效果比商业的编译器如VC/BC差了大概20，也就是说同一段C代码，用商业编译器能编译成100条指令的话，GCC最好的情况下只能编译成120条指令。
实际上，在没有任何包过滤规则或其它配置的情况下，完整的处理一个数据包需要大约14000条指令。
所以,根据上面的计算，目前许多X86架构防火墙（PIII800）在100M网络环境下的结果是64byte的情况下达到42的线速转发能力，即62000fps的处理能力。至于100，95，90以上……
--------------------------------------------------------------------------------
colddawn回复于：2005-11-2211:13:29
1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
理解！不过这也证明目前市面上的很多国产设备的现状以及国内这个领域的研发状况，不做评价
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p31G的CPU，64bytes下能到80M，我现在有好几台freebsd的机器，p4的和至强的，两边用光阵列机来跑，512bytes下才能到100M，64bytes下离你说的数据差得太远，因为没有条件，没有办法拿Smartbit来做测试，不过我想误差应该不会太离谱。
ok，我承认，我用的是P31GXeonMP，PCI-X架构的pro100网卡，以太网口。
同时我做的是透明网桥，包在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-2309:50:49
现在100Mb/s以下的流量已经不是问题了
我们的目标是千兆甚至更多
现在看来，通用的linux平台的确不能满足需要（这里不谈硬件部分）
谁能告诉我，linux在这方面有什么改进项目没有？或者有什么公司可以做这个事情？
另外，没看过MBuf的资料，它比skbuf好在哪里啊？哪位能点拨一二？
引用：原帖由colddawn于2005-11-2209:16发表
请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了linux iptables再套个外壳实现的，要知道光netfilter架构处理占用的cpu时间就高达30，如果再加上那个性能风传非常差的conntrack的话，这个结果不出奇，这并不能说明是总线瓶颈或者是cpu瓶颈，另一方面，即使是你说的35的带宽利用率，你有统计过那时中断/s的数量吗？有证据证明是cpu中断处理不过来了吗？
linux的我倒真是没测试过，但是同样是p31G，板载pro100，我装过freebsd，仅仅使用ipfw bridge做透明防火墙，连内核都没有优化过，轻松达到80M，无延迟，无丢包，100线速说不上，但90M的时候的丢包率也是基本可以忽略不计。
如果一个1000M包转发的设备都要用4路Xeon，那24口千兆三层交换或者路由器岂不是要大型机？...
[本帖最后由caibird3rd于2005-11-2309:55编辑]
--------------------------------------------------------------------------------
mirnshi回复于：2005-11-2321:59:20
引用：原帖由独孤九贱于2005-11-2209:37发表
不太同意你的话：
1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p31G的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-2322:22:23
目前对于百兆,CPU的速度足够，除非增加各种稀奇古怪的功能进去--什么各种代理过滤之类的。
对于千兆，由于pps增加了，网卡的队列也增加了，考虑到时延问题和中断，以及PCI通道问题，CPU就显得不够用了。内核支持SMP的，性能会提高很多。而且千兆很多都是桥模式的，最差也是路由模式，有哪个网管愿意在出口处，放个瓶颈？桥模式都是2层上作，省去了三层协议队列，当然处理时，需要自己构建协议栈了，包转到协议栈后，再由其他线程处理，分工合作。但无论怎样，受到PCI/X限制，也只能是当个假千兆用。
曾在Freebsd上作过测试，DDOS攻击，如果直接收包丢弃，可以达到8、900M，机器是PIV2.4至强，bsd4.11，但是发包受限，优化得非常好了不过300多。
--------------------------------------------------------------------------------
zyzf回复于：2005-11-3011:17:30
X86的瓶颈就在网卡驱动上面。
个人觉得。
--------------------------------------------------------------------------------
test_tmp回复于：2005-12-0508:43:43
我也在做NAT,但还是新手,请楼主指点一下,如何达到5万PPS?还有如何测一台机器的PPS数
非常感谢
--------------------------------------------------------------------------------
test_tmp回复于：2005-12-0616:56:48
怎么没人理我
--------------------------------------------------------------------------------
depthblue_xsc回复于：2005-12-1517:17:28
我正在测试千兆防火墙的性能，64B双向达到线速的15（30秒的测试时间）
如何能够再提高，系统如何再优化呢？netfilter的效率不高，linux的网络i/o分布不平衡
系统还有什么地方可以优化呢？
--------------------------------------------------------------------------------
Solaris12回复于：2005-12-1517:32:28
引用：原帖由mirnshi于2005-11-2322:22发表
目前对于百兆,CPU的速度足够，除非增加各种稀奇古怪的功能进去--什么各种代理过滤之类的。
对于千兆，由于pps增加了，网卡的队列也增加了，考虑到时延问题和中断，以及PCI通道问题，CPU就显得不够用了。内核支持...
100M/1000M现在OS一般都handle的了。
上1000个连接达到线速也是没问题的，不需要很强劲的机器。
但是10000M网卡就不一样了，这个需要特别的处理。
感兴趣的话，可以在solaris上测测万兆网卡。
因为本人不是搞防火墙的，所以不了解这方面的问题。
在100M/1000M上，CPU真的不是大问题。
而且先进的网卡都支持HWoffload，很多工作不需要CPU来做。
当然这取决与你driver和OS是否充分利用了网卡的先进特性。
在intele1000和broadcom的网卡上，都有类似的特性。
所以你的dirver和你的OS版本很重要，一定要用支持HWoffload的版本
[本帖最后由Solaris12于2005-12-1517:39编辑]
--------------------------------------------------------------------------------
caibird3rd回复于：2005-12-1520:54:32
现在的问题既不是网卡，也不是CPU
而是网络协议及其依赖的OS中断处理机制，而且网卡仅仅支持csum等简单的offload作用不大
引用：原帖由Solaris12于2005-12-1517:32发表
100M/1000M现在OS一般都handle的了。
上1000个连接达到线速也是没问题的，不需要很强劲的机器。
但是10000M网卡就不一样了，这个需要特别的处理。
感兴趣的话，可以在solaris上测测万兆网卡。
...
[本帖最后由caibird3rd于2005-12-1520:56编辑]
--------------------------------------------------------------------------------
Solaris12回复于：2005-12-1611:22:14
引用：原帖由caibird3rd于2005-12-1520:54发表
现在的问题既不是网卡，也不是CPU
而是网络协议及其依赖的OS中断处理机制，而且网卡仅仅支持csum等简单的offload作用不大
这个问题，既是网卡，CPU，总线，还是OS，更是driver的问题，需要几部分协作：
网卡：提供HWoffload机制，目的是减轻CPU的压力，比如checksumoffload，LSO，MSI，interruputblanking，甚至是整个协议栈的offload
CPU：NP/SUN的CMT
总线：PCI-X对付1000M绰绰有余
OS:interruputblanking/MSI
dirver:充分利用OS和网卡提供的这些特性。
目前，Solaris已经支持了interruputblanking，很多dirver也使用了HWoffload机制.
相信linux也差不多。所以我说100M/1000M的问题已经解决，目前主要10000M的问题。
关于操作系统的网络方面，我们曾经请SUN的著名工程师eric，也是IEEE的委员，做过一次演讲，请参考下面的网址：
[本帖最后由Solaris12于2005-12-1611:32编辑]
--------------------------------------------------------------------------------
hvtony回复于：2005-12-1611:49:53
不清楚各位在linux下测试相关性能的时候用的是怎样的linux？是一般的标准发行版本redhat,suse什么的（猜的，不大可能吧:em02:），还是定制的呢？
我在linux下测试的brouter，带防火墙和流量控制，100M网络环境，目前是带了15台服务器，流量跑到11Mbyte/s是轻而易举的，而且看到的负载主要集中于硬件的IRQ上。
对于iptables和conntrack的优化，目前有很多的方法啊，比如ipset和nf-hipac就是不错的选择，就算是iptables在使用的过程中也不会太占用CPU的，我的防火墙规则大概150条左右。
CPU用的是Celern2.0G的，网卡用的是Intel1000M，主要是看中了他的NAPI和tso。
对于100M网络，32位的66MHZ的卡肯定是可以的，32*66已经大于100了。
--------------------------------------------------------------------------------
lenn回复于：2006-01-0910:50:04
P42.8*2XeonCPU下是可以达到这个转发性能的.
我把E1000网卡修改成零拷贝,直接收包,可以达到950Mbps以上,包数可以达到120W,虽然64bit的小包线速达不到,
但是流量是可观的,单个CPU使用70,
发包的我没有硬件做测试,假如双网卡,使用核心线程作零拷贝发包,也就是包不通过协议栈,假设性能折扣为3/4,那应该也可
以达到600到700Mbps的.如果你有兴趣,我们可以讨论下.
MSN:liangvy@bigfoot.com
--------------------------------------------------------------------------------
sbyond回复于：2006-01-1015:20:30
2006.1.10再来一点补充
上次说错了100万应该是1，000，000,即1000kpps
2.6.14自编译内核转发峰值155Kpps,基本能稳定在130kpps
离我希望的400kpps还有一定差距，继续努力中
--------------------------------------------------------------------------------
guotie回复于：2006-02-2213:41:22
呵呵，不知道楼主的情况如何了。
我刚刚在linux-net的邮件列表上看到的讨论，关于linuxnet转发率的测试数据：
YesPCI-Xboardsissendingaround~800kpps.Withsomeuglypatchesabout
300kppsmore.
60748406
124693133
252452951
508234982
1020119742
149682242
TheBCMPCI-X*inside*theserverworksH2000isfaster.
BCMw.tg3
601421959
124844572
252452918
508234970
1020119735
149682239
FastestandmostintresingsofaristheIntel82571ServerPCI-Edual
serveradapter.
601488305
124844635
252452835
508234973
1020119737
149682240
IOlatencyisworsewithPCI-EbuttheIntel82571canhandlefour
concurrentRX/TXtransactions.AlsoPCI-EisFXthisseemstowell
handlethePCI-Eextralatency.
StephenI'veheardsomegoodthingsabouttheSyskonnectPCI-Eadapters
anychanceyoucouldrunatestsimilartothetestsabove?
--------------------------------------------------------------------------------
wheel回复于：2006-02-2217:34:33
8bits的基带数据映射成10bits的数据,保证10bit数据中“0”/“1”信号的数量相等,的确是PCI-E的加速特性，这样不用时钟，PCI-Ex总线在8B/10B编码层之前采用扰频，和K28.0字符时钟补偿。使得高频特性跟好了。
--------------------------------------------------------------------------------
caibird3rd回复于：2006-02-2409:01:46
对于PCI、PCI-X、PCI-E等总线，是否可以认为如下结论成立：
双向同时传输数据时单个方向上的速率是否为完全单向传输速率的一半？
--------------------------------------------------------------------------------
skipjack回复于：2006-03-0115:11:58
40万?要求也太低了吧,100M冰盾软件都能转发25万pps,1000M下至少也是160万啊?(网上你搜一下)
还有什么方正黑杀,dosnipe,神洲盾.....都是一个小黑箱就号称可防数百万pps啊,你要做一个40万的,估计要用到486CPU,这可不好找啊.
--------------------------------------------------------------------------------
lenn回复于：2006-03-0115:53:40
引用：原帖由skipjack于2006-3-115:11发表
40万?要求也太低了吧,100M冰盾软件都能转发25万pps,1000M下至少也是160万啊?(网上你搜一下)
还有什么方正黑杀,dosnipe,神洲盾.....都是一个小黑箱就号称可防数百万pps啊,你要做一个40万的,估计要用到486CPU,这可...
软件转发,有这么牛么??
--------------------------------------------------------------------------------
skipjack回复于：2006-03-0116:01:40
引用：原帖由lenn于2006-3-115:53发表
软件转发,有这么牛么??
做syn包判断比转发更耗时吧,再说判断的结果可能就是转发啊,号称是每秒13万个包时不丢包,呵呵
--------------------------------------------------------------------------------
coco520回复于：2006-04-0716:17:35
有种技术叫napi的，从中断入手解决转发效率，效果还可以。lz可以试试。
--------------------------------------------------------------------------------
obrire回复于：2006-04-0720:29:58
引用：原帖由sbyond于2005-11-601:09发表
以前作NAT5万PPS没有问题（AS4）CPU只到5左右
现在不需要NAT，只做静态路由转发（）
(route)
echo1>/proc/sys/net/ipv4/ip_forward
eth01.1.1.1
eth12.2.2.1
测试拓扑：client1_-----------...
此前公司的IP_FORWARD就达到了8,000,000
不过你内核最好修改一下.
至于说到CISCO/华为的产品,早在冲击波时,就趴下一大堆(一所学校,有2KWorkstation)
不过Linux还是挺起的.
首先要修改MAXCONNECTION
还有并发的SESSION.
细节参阅/proc/sys/net/ipxx下面的相关记录.
最好是SMP构架,修改Ether卡的驱动,大规模启用DMA.
近乎于SUN的IPBOND.也可多台,实现应用层交换.
1000万的PPS都没问题.看看Google的流量.一天多少?用IPVS机群,都可以实现
包括RealNetworks流媒体服务器系统.
--------------------------------------------------------------------------------
obrire回复于：2006-04-0720:48:42
引用：原帖由skipjack于2006-3-115:11发表
40万?要求也太低了吧,100M冰盾软件都能转发25万pps,1000M下至少也是160万啊?(网上你搜一下)
还有什么方正黑杀,dosnipe,神洲盾.....都是一个小黑箱就号称可防数百万pps啊,你要做一个40万的,估计要用到486CPU,这可...
纯软件始终要采用OS提供的IP协议栈,如果仅在Windows下或未经优化的内核,即便是达到了,
也不合格.你可以用专业仪器测试一下.
要优化性能,首先要从物理层开始,充分利用物理特性(如DShow/DDraw).
如果所用晶片有限,软件是做不出来的.
至于有人翻译的ZEROCOPY,其实最大限度就是DMA传送.
在OS的MM管理中,你看看当前我们的内存带宽有多大,然后将各种时延算进去,
最终封包,发出去,才知道我们的性能怎么样.
其始在NP/MP之外,CISCO也用Intel的P系列CPU.
只是OSKernel不一样,其它也与你的PC一样.
至于传输Channel,以前公司生产光交换,但也要通过光电转换.
如果光电转换及CableDrive能力很差,性能也是跟不上的.
顺便说一下,目前的电缆也可以传10Gbps.我有朋友就是CISCO全球三大核心晶片(10G平台)供应商之一.
加拿大的,还有一家叫Broadcom的公司也能做,Siemens下的半导体公司也很牛的.
用10Gbps减去各种限制时延和内存封包能力,就可以从理论上算出我们所要的pps了.
--------------------------------------------------------------------------------
obrire回复于：2006-04-0721:04:25
引用：原帖由独孤九贱于2005-11-2209:37发表
不太同意你的话：
1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p31G的CPU，64by...
知道VxWorks的C编译器吗?
其实Intel的C编译器与GCC也有很多合作,PowerPC一般都采用的GCC,Apple就是(OS是GCC编译的,
DefaultCompile也是GCC),我看过公司的服务器AppleServer/PowerG52.02CPU,性能高得很,
比2枚AMD64/2枚Intel至强同等高很多.
你看过IPP的源码吗?懂什么叫优化吗?做过WiMMX优化吗?
如果说VC能优化,GCC不能优化,可能你根本就没从事过这方面的工作.
NY的交通系统,就是VxWorks在GCC下编译的.
其实VxWorks提供的ARM平台源码中,几乎就是GCC定制的一个子集.
知道CELL用什么编译吗?IBM用的是GCC,而SONY美国也在招GNU工作师.
天知道,怎么会发这样的BIA言.
如果说他们是白痴,总还有一些从比他们更白痴!
--------------------------------------------------------------------------------
skipjack回复于：2006-04-0722:13:48
>>纯软件始终要采用OS提供的IP协议栈,如果仅在Windows下或未经优化的内核,即便是达到了,
>>也不合格.你可以用专业仪器测试一下.
你指的不合格是什么?专业仪器测SMB和IXIA应该说的过去吧
>>要优化性能,首先要从物理层开始,充分利用物理特性(如DShow/DDraw).
>>如果所用晶片有限,软件是做不出来的.
物理层从网线算还是从网卡模块算起?给个结论IA体系的转发极值是多少?
>>至于有人翻译的ZEROCOPY,其实最大限度就是DMA传送.
这个了解,但真正意义上的包转发线速和DMA没必然的联系,DMA主要还是为了用于解决收包时的瓶劲,但NP/MP还是靠微引擎的并行度
>>OS的MM管理中,你看看当前我们的内存带宽有多大,然后将各种时延算进去,
>>最终封包,发出去,才知道我们的性能怎么样.
很迷惑了,看不出其间的联系,软硬中断都不考虑在内是吗?
>>其始在NP/MP之外,CISCO也用Intel的P系列CPU.
>>只是OSKernel不一样,其它也与你的PC一样.
那是因为IA构架在某种应用时优于NP/MP
>>至于传输Channel,以前公司生产光交换,但也要通过光电转换.
>>如果光电转换及CableDrive能力很差,性能也是跟不上的.
就这句知道是什么意思
>>顺便说一下,目前的电缆也可以传10Gbps.我有朋友就是CISCO全球三大核心晶片(10G平台)
>>供应商之一.加拿大的,还有一家叫Broadcom的公司也能做,Siemens下的半导体公司也很牛的.
>>用10Gbps减去各种限制时延和内存封包能力,就可以从理论上算出我们所要的pps了.
为什么是10G而不是100G,好像10G是个极限似的?如果是,怎么算出来的?
--------------------------------------------------------------------------------
skipjack回复于：2006-04-0722:26:08
>>知道VxWorks的C编译器吗?
知道
>>其实Intel的C编译器与GCC也有很多合作,PowerPC一般都采用的GCC,Apple就是(OS是GCC编译的,
>>DefaultCompile也是GCC),我看过公司的服务器AppleServer/PowerG52.02CPU,性能高得很,
>>比2枚AMD64/2枚Intel至强同等高很多.
你是说这个性能提升都是编译器的功劳?
>>你看过IPP的源码吗?懂什么叫优化吗?做过WiMMX优化吗?
没懂没做过
>>如果说VC能优化,GCC不能优化,可能你根本就没从事过这方面的工作.
>>NY的交通系统,就是VxWorks在GCC下编译的.
倒~勇气号也是VxWorks,NY的交通系统能说明GCC什么?您到底想说明什么问题?
>>其实VxWorks提供的ARM平台源码中,几乎就是GCC定制的一个子集.
您这么一解释,我都快不知道VxWorks和xscale,那个是OS那个是CPU了
>>知道CELL用什么编译吗?IBM用的是GCC,而SONY美国也在招GNU工作师.
>>天知道,怎么会发这样的BIA言.
>>如果说他们是白痴,总还有一些从比他们更白痴!
知道CELL是IBM的多核,但这能说明GCC什么呀?看了您的贴子,我怎么感觉头有点晕啊.
--------------------------------------------------------------------------------
skipjack回复于：2006-04-0722:34:03
>>此前公司的IP_FORWARD就达到了8,000,000,不过你内核最好修改一下.
几网口,上面这个数字的单位是什么?只修改内核就可以了?不会是软件控制硬件的bypass功能吧?
>>至于说到CISCO/华为的产品,早在冲击波时,就趴下一大堆(一所学校,有2KWorkstation)
>>不过Linux还是挺起的.
呵呵....告诉我拓朴和环境,就像你说Google流量大,但我的机器却安然无样一样.
>>首先要修改MAXCONNECTION
>>还有并发的SESSION.
>>细节参阅/proc/sys/net/ipxx下面的相关记录.
开始胡说八道了
>>最好是SMP构架,修改Ether卡的驱动,大规模启用DMA.
>>近乎于SUN的IPBOND.也可多台,实现应用层交换.
>>1000万的PPS都没问题.看看Google的流量.一天多少?用IPVS机群,都可以实现
>>包括RealNetworks流媒体服务器系统.
春风吹~战鼓擂了
--------------------------------------------------------------------------------
obrire回复于：2006-04-0811:58:37
引用：原帖由skipjack于2006-4-722:13发表
>>纯软件始终要采用OS提供的IP协议栈,如果仅在Windows下或未经优化的内核,即便是达到了,
>>也不合格.你可以用专业仪器测试一下.
你指的不合格是什么?专业仪器测SMB和IXIA应该说的过去吧
>...
至于专业的NP/MP，也就是专业的ASIC，将路由算法内置于其中．就像有些DSP一样，将算法内置．
这不新鲜．AXIS就将一个ARM920核和4MMemory和4MFlash内置，还有一些算法．PMC以前有
些Chip,在PMC自己做的VoIP上，在泰尔测试时，时延都比较大，你不迷信ASIC.这只能HU外行．ASIC
设计也有水平高低，也有算法逻辑的优劣，不同公司出品的，以及新的技术的加入，这都会影响最终
对数据包的处理能力的．如果你的NP运算能力有限，我就用两枚PIV加优化了的软件算法，也是可以
达到的，有时还可以超出，以前有朋友帮Intel做一个NP的驱动，NP好贵．现在有一种便宜的做法是
用VS机群来取代这种方式．他最终受限于总线．就你DVR系统一样，如果IDE接口受限，你可以使用
FiberChannel/IEEE1394B等．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并发太
多，肯定会死的．在CISCO3000/4000中，你用目前的通用CPU，选好的PHY接口CHIP，不是RTL的，
最好是Broadcom的，你看看是你的快，还是CISCO的路由器好吧．只能说Linux下，IP性能上稍差于BSD
Unix，如果优化一下，或使用VxWorks提供的，那就不一样了．而华为/CISCO等，还不是基于VxWorks
做的．其实将IPStack放入ASIC或置于计算机中，差异不是很大，要可配置，必然内存等级与你用的差不
多，访问时间也差不多．有时在通信CPU中，MIPS值可能很高的．一般可以达到5000-8000，就是DSP
也不行呀．DSP目前最快的也就1GHz．如果我的CPU也做专项运行，上EmbeddOS，性能还要优于这些
专用的ASIC．如果专门来做路由及应用交换，用VS是首选，我的内存可以很大呀，专用的ASIC不可能集成
很多内存的，扩展不就与我的一样了吗？关键是ASIC各X86计算机，在MII层要好的芯片，不然性能差异较大．
好多人说100Mbps，看看你的各种网卡，测出来都什么样吧．有些高于，有些还达不到．
只能说，专门的如Juniper的T640这种设备，各个环节都是相适应的．
但这些由专业厂商做的东东，没有几M RMB是拿不下来的．他是直接上干线，下行至你的Workstation．
所以人家才牛嘛．
[本帖最后由obrire于2006-4-812:18编辑]
--------------------------------------------------------------------------------
obrire回复于：2006-04-0812:06:30
引用：原帖由skipjack于2006-4-722:34发表
>>此前公司的IP_FORWARD就达到了8,000,000,不过你内核最好修改一下.
几网口,上面这个数字的单位是什么?只修改内核就可以了?不会是软件控制硬件的bypass功能吧?
>>至于说到CISCO/华为的产品,早在...
这是2003年的夏天．
不仅如此，就是联通和电信的机房，也比较忙的．因为当时的软件中没有对连接会话进行限制．
如果NAT，他限也限不了呀．我内网中IP时时变．
后来，我们设计了程序，一旦发现过多的报文来自同一MAC，就封了．并对各种状态进行过滤．
当然这会让性能下降．不过计算性能较高，PIV对小网足够了．
如果2W用户，每人100连接，不修改，你看Linux不Crash才怪．好像IP默认最大连接不超
过10万（我在Windows下，记不起了）
内网100Mbps／外网100Mbps.如果交换机没有流控，你看看倒不倒.
--------------------------------------------------------------------------------
obrire回复于：2006-04-0812:16:29
引用：原帖由skipjack于2006-4-722:34发表
>>此前公司的IP_FORWARD就达到了8,000,000,不过你内核最好修改一下.
几网口,上面这个数字的单位是什么?只修改内核就可以了?不会是软件控制硬件的bypass功能吧?
>>至于说到CISCO/华为的产品,早在...
这是基于Linux做的，国内还有朗新用FreeBSD做的．
如果这不能说明问题，我就无话可说了．这是IPVS发起人的弟弟布置的．在2003年可以是挺得很直哟．
当时好多CISCO倒下了．
有些人说话要有证据才行呀．英国Tunsys超级计算机公司的设计也是基于二层交换，VS做的．这在
FBI用了很多哟．
IPVS目前已经并入Linux2.6的内核中．是章文嵩博士发起的．有什么问题，你可以向他提问．
先看看在IBM上他的算法吧．不过有人以后用这些前沿技术，记得向开发者致敬呀，别像TurboLinux，
很没道德．IBM赞助了章在世界各地讲学呀，IBM在网格计算中，应当会有这些技术的身影．
中国人呀，首先要有道德，不能乱整，没修养．
--------------------------------------------------------------------------------
skipjack回复于：2006-04-0815:25:57
引用：原帖由obrire于2006-4-812:16发表
这是基于Linux做的，国内还有朗新用FreeBSD做的．
如果这不能说明问题，我就无话可说了．这是IPVS发起人的弟弟布置的．在2003年可以是挺得很直哟．
当时好多CISCO倒下了．
有些人说话要有证据才行呀．英...
谢谢,虽然你说的我现在不能全部理解,但至少有了个全面的了解.哈哈......你说的这些环境,我还都没有机会见到过.Juniper的性能很高,就像你说的转发时把路由算法内置了.但像内容过滤这类的应用.现在他可以内置了吗?因为netscreen在连接率上受限于ASIC芯片,也不是什么强项.只听说过Tcom之类的芯片,但应用中还没有触及过.类似的还有正则表达式匹配芯片等等,它们的瓶劲在那里?
--------------------------------------------------------------------------------
obrire回复于：2006-04-0817:03:48
内容过滤在第四层及以上层面
也就是有人所说的七层交换,这里已经没有传统路由的概念了.
新技术的发展,以前的定义和说法是需要局部限定的.
以前说LAN是局部的,如果采用IP->E1映射,LAN也可以从上海到北京.
