电音轰炸机 长期更新~~ - 歌单 - 网易云音乐
电音轰炸机 长期更新~~
电子舞曲(Electronic Dance Music、即常见缩写EDM)是各种电子音乐的合称，简称电音、电子乐。广义而言，只要是使用电子音色所创造的音乐，都可属之。它们的用途往往是在舞厅、派对里用来作跳舞的背景音乐，...
电子舞曲(Electronic Dance Music、即常见缩写EDM)是各种电子音乐的合称，简称电音、电子乐。广义而言，只要是使用电子音色所创造的音乐，都可属之。它们的用途往往是在舞厅、派对里用来作跳舞的背景音乐，多是DJ们制作。 电子舞曲流派分为 House, Techno ,Trance,Big Beat,Drum `N` Bass,Break Beat 和Big Beat,Reggae/Ska,Old school/Miami beat,R`N`B,Tribal,Mambo,Cha Cha,Hip House。国内经常会把电子舞曲说成是DJ音乐，实际上所谓的DJ是这些音乐的制作者。DJ只是职业不是音乐曲风。电子音乐和电子舞曲约等于是一个意思，国内说电音会比较多，而西方都是说电子舞曲。
播放：2472次
喜欢这个歌单的人
网易云音乐多端下载
同步歌单，随时畅听320k好音乐
网易公司版权所有(C)杭州乐读科技有限公司运营：酷勤网 C 程序员的那点事！
浏览次数：次
作者:xfsoul
我测试FreeBSD无丢包网络转发性能。我现在测试用的硬件配置：CPU：奔四2.8G内存：1G&DDR333双通道网卡：双Intel千兆网卡用来做网桥，还有一个百兆的用来访问还有千兆网线和smartbit千兆口[color=Red]我开了polling以后，无论怎么设置,转发性能都上不去，64字节下双向到达18万pps以后，就开始丢包，但CPU占用率一直不到1%[/color][color=Red]我尝试过设置内核配置文件的值HZ=1000改为2000也不行，我还设置过如下参数，都没有能很好的提升性能：kern.polling.user_frackern.polling.each_burstkern.polling.burst_max[/color][&本帖最后由&xfsoul&于&&18:32&编辑&]
&xfsoul 回复于： 18:45:41
而且我在网上看到很多人碰到和我一样的问题：在FreeBSD6系列中开了polling性能会很差：http://www.monkey.org/freebsd/archive/freebsd-performance/200501/msg00060.htmlhttp://www.freebsdchina.org/forum/viewtopic.php?p=120928&sid=e0a636fadcfede6fedee03我这里开了polling性能比linux差很多。[&本帖最后由&xfsoul&于&&18:51&编辑&]
&雨丝风片 回复于： 18:55:19
这封邮件你看了没有？http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2006-03/msg00142.html
&xfsoul 回复于： 19:05:37
没有看到。现在怎么办呢。在第一个硬件平台上测试。FreeBSD网络转发性能貌似不如linux
&xfsoul 回复于： 19:08:01
我重新编译内核，彻底去掉polling看看，性能能否比得上linux。
&xie_minix 回复于： 23:24:51
1.2.1&&全局变量从第106行开始,都是POLLING相关的全局变量.首先是建立一SYSCTL树的节点.下图中的SYSCTL_NODE宏代表在父节点_kern下建立一个_kern_polling节点.SYSCTL_NODE(_kern,&OID_AUTO,&polling,&CTLFLAG_RW,&0, "Device&polling¶meters");&&&&&&&&&& 下图中的变量全部可用sysctl来查看,大部分都可以调整设置.这些全局变量都是使用宏SYSCTL_UINT把他们加入到_kern_polling节点下,成为该节点的叶子.之所以这样,是因为可以通过用户区来调整这些参数.-----------------------------------------------------------------------------------------------------static&u_int32_t&poll_burst&=&5;&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&------&kern_poll.cstatic&u_int32_t&poll_each_burst&=&5;static&u_int32_t&poll_burst_max&=&150;static&u_int32_t&poll_in_idle_loop=0;u_int32_t&poll_in_static&u_int32_t&user_frac&=&50;static&u_int32_t®_frac&=&20&;static&u_int32_t&short_static&u_int32_t&lost_static&u_int32_t&pending_static&int&residual_burst&=&0;static&u_int32_t&poll_static&int&polling&=&0;static&u_int32_t&static&u_int32_t&static&u_int32_t&static&u_int32_t&idlepoll_&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&------&kern_poll.c----------------------------图1-2-2&----------------------------在图1-2-2中.这些变量按功能分可分为&&3&&大类.A. 开关型:polling:&初始为0,即默认为不打开轮询功能.要打开轮询功能,必须用:#sysctl&kern.polling=1poll_in_idle_loop:该参数用于poll_idle函数,用来确定是否进入一低优先权的循环轮询中.即CPU空闲时是否来执行轮询.poll_in_trap:此参数不但是在陷入时是否执行轮询的开关,而且其值也是在陷入(trap)时执行多少次轮询B. 算法参数poll_each_burst:一个基本的轮询次数,很多其他变量都来和他进行比较(主要是空闲时执行轮询或陷入时执行轮询).该值系统默认是5,poll_burst:一个动态的轮询次数,主要用于根据核心(轮询)占用的时间片调整轮询次数,在核心(轮询)时间片小于预定的时间片时,该值加1,当核心(轮询)时间片过长,导致丢失一个或更多的时钟嘀嗒时,该值将减去该值的8分之1.这种算法是FreeBSD中轮询技术的主要算法.当然有一定的局限性.当网络分组快速增加时,此算法只是加1来增加次数再来调用软件中断,从而形成软中断暴增的做法并不好.而且在占用时间片过长时的减8分之1的做法也缺少理论依据.poll_burst_max:轮训的最大值,该值是用来限制poll_burst在累加过程中的最大量.当然该值可以调整.他的调整范围在后面讲的两个宏之内.user_frac:用户区占用的CPU时间片的百分比.该值用来确定核心(轮询)所占时间片是否有剩余,如果有的话就调整动态值poll_burst,使其加1.residual_burst:在正常的轮询次数中,都是以poll_each_burst为标准的,而当动态的poll_burst&poll_each_burst时候,就会产生剩余没轮询的次数,该次数就是residual_burst,当然其结果就是继续轮询完residual_burst.idlepoll_sleeping:该值的使用前提是poll_in_idle_loop变量开关已经打开,即在CPU空闲时支持轮询.系统置该值为0,可以直接进入到CPU空闲时的轮询代码中;如果poll_in_idle_loop变量开关还没开放,系统会给该值置1,也就是说.该值其实是一个CPU空闲时是否进入轮询代码的状态,reg_frac:在整个循环代码执行了该值的次数之后,就进行检查网卡的状态寄存器.看看网卡是否有什么问题.pending_polls:在进入轮询前(我们有个时钟嘀嗒钩子函数),此参数加1,再轮询后会对其减1,再次进入时钟嘀嗒后半部分会判断是否平衡,如果由于轮询时间过长,此次嘀嗒便会错过.C. 调试与参考short_ticks:每次时钟嘀嗒钩子函数所花的时间如果小于5毫秒.那这种间隔时间太短了.这是以HZ=100来计算的.源代码作者认为.在100M卡时,HZ数调整到1000比较合适,那么我们的时钟嘀嗒钩子函数所花时间在小于0.5毫秒是合适的.lost_polls:&由于pending_polls的不平衡.记录一次嘀嗒时间错过,该值会不停的累加,给系统管理员提示可以调整poll_burst_max值小一些.或根据情况把user_frac(用户占用CPU时间片的百分比)的值调的更小些.poll_handlers:有多少个网络设备支持并注册了轮询.phase:指示轮询进行到了哪个阶段.轮询代码共分为6个阶段.
0阶段代表是初始阶段或上次轮询的结束.
1阶段时钟嘀嗒钩子函数在设置网络软中断(轮询中断)前
2阶段时钟嘀嗒钩子函数在设置网络软中断(轮询中断)后.
3阶段是进入软中断netisr_poll前.
4阶段是从软中断netisr_poll中出来.
5阶段是进入软中断netisr_pollmore前
6阶段是从软中断netisr_pollmore中出来.suspect:由于最后的软中断netisr_pollmore在处理时会再完成时把阶段标志phase置为0(即一次POLLING的完成,),或出现其他未完成情况时进入阶段5和6.那么就是说.我们的时钟嘀嗒钩子在最初时小于2阶段的话,一定是在0阶段.如果出现1或2阶段的话就意味着时钟硬件中断发生了嵌套.此值在出现这种问题时进行记录.stalled:由于pending_polls太大(大于100),也就是说由于每次轮询时间过长,以至于轮询丢失了太多嘀嗒,当到达100次时,该值加1.(源代码的作者认为不会发生此类事情,除了在网卡激活时)以上是一些参数说明,你可以参照下.(不过是基于5.3的)另外,请开空闲HOOK.
&xie_minix 回复于： 23:51:23
我想知道调度器的情况.以下是对/sys/kern/kern_poll.c中在第106行左右的SYSCTL_NODE(_kern,&OID_AUTO,&polling,&CTLFLAG_RW,&0, "Device&polling¶meters");的后面加入以下:(拷贝粘帖就可以了)SYSCTL_NODE(_kern_polling,&OID_AUTO,&dbg,&CTLFLAG_RW,&0, "Device&polling&node&kernel&debug");static&uint32_t&poll_SYSCTL_UINT(_kern_polling_dbg,&OID_AUTO,&poll_coun,&CTLFLAG_RD,
&poll_coun,0,"netisr_poll&and&netisr_pollmore&count");static&uint32_t&pollmore_SYSCTL_UINT(_kern_polling_dbg,&OID_AUTO,&pollmore_coun,&CTLFLAG_RD,
&pollmore_coun,0,"netisr_pollmore&count");static&struct&timeval&pollstart_t;static&uint32_t&poll_static&uint32_t&poll_SYSCTL_UINT(_kern_polling_dbg,&OID_AUTO,&poll_suspect,&CTLFLAG_RD,
&poll_suspect,0,"poll_suspect&count");static&uint32_t&poll_SYSCTL_UINT(_kern_polling_dbg,&OID_AUTO,&poll_invoke,&CTLFLAG_RD,
&poll_invoke,0,"poll_invoke");static&int32_t&net_SYSCTL_INT(_kern_polling_dbg,&OID_AUTO,&net_load,&CTLFLAG_RD,
&net_load,0,"net_load");static&int32_t&on_cpu1;SYSCTL_INT(_kern_polling_dbg,&OID_AUTO,&on_cpu1,&CTLFLAG_RD,&on_cpu1,0,"run&on&cpu1");static&int32_t&on_cpu2;SYSCTL_INT(_kern_polling_dbg,&OID_AUTO,&on_cpu2,&CTLFLAG_RD,&on_cpu2,0,"run&on&cpu2");/*end*/然后到netisr_pollmore()函数中的第6,7行左右if&(residual_burst&&&0)&{语句后加入:pollmore_coun++;
if&(pollmore_coun&0xfffffffe)&
pollmore_coun=0;到netisr_poll()函数中第一行的大括号后面加上: struct&timeval&netisr_t;到6,7行phase&=&3;这句后面加入: poll_coun++; if&(poll_coun&0xfffffffe)
poll_coun=0; if&(poll_start==0)
poll_suspect++; microuptime(&netisr_t); poll_invoke=(poll_invoke+((netisr_t.tv_usec&-&pollstart_t.tv_usec)+(netisr_t.tv_sec&-&pollstart_t.tv_sec)*1000000))/2;其他的你还暂时用不上.重新编译核心.重启动开POLLING后.执行:sysctl&kern.polling.大概每秒执行下看看,把数据发上来.[&本帖最后由&xie_minix&于&&23:58&编辑&]
&xie_minix 回复于： 00:08:45
目前本人正在做POLLING的NetBSD移植.对于POLLING的效率问题听过很多网友反映,我没有条件测试,移植的目的主要是想解决SMP上效率问题,还有参数的动态调整,希望大家能帮忙一起解决.NetBSD的POLLING原代码我争取在这几天发到这.关于POLLING的原代码详解也将快发到CNFUG的期刊上(整整写了一年了,效率和没调优的POLLING一样).到时希望大家指正.[&本帖最后由&xie_minix&于&&00:10&编辑&]
&bz169 回复于： 06:31:05
在FBSD下打开Polling的效果并不明显尤其是桥+polling
&雨丝风片 回复于： 08:37:19
多谢xfsoul的测试和xie_minix的分析！我找到了一篇含有polling性能测试的文章，并把FreeBSD的net、performance和hackers邮件列表上从2003年到现在的关于polling的讨论话题整理了一下，希望大家能够一起把这个问题弄明白。^_^Improving&Passive&Packet&Capture:&Beyond&Device&Polling&&&&http://luca.ntop.org/Ring.pdfFreeBSD-netif_bridge&+&polling&get&lower&througphts&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2006-03/msg00142.htmlPolling&for&ath&driver&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2006-02/msg00054.htmldummynet,&em&driver,&device&polling&issues&:-((&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/9.html[REVIEW/TEST]&polling(4)&changes&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/9.htmlAbout&guideline&of¶meters&tuning&while&in&polling&mode.&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/7.htmlpolling&in&4.11&vs&5.4&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/3.htmlpolling&and&twa&coexistence&problems&under&5.4-PRE&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/7.htmlRe:&Giant-free&polling&[PATCH]&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/1.htmlxl(4)&&&polling&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/0.htmlfreebsd&router&project.&Problems&with&polling?&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/9.htmlpolling(4)&rocks!&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/4.htmlsf(4)&device&polling&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/7.htmldevice&polling&takes&more&CPU&hits??&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/8.html[PATCH]&vr(4)&locking&(and&DEVICE_POLLING)&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/9.html[PATCH]&rl(4)&locking&and&DEVICE_POLLING&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/8.htmlPer-interface&polling(4)&status&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/4.htmlpolling(4)&and&rl(4)&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/5.htmlRe:&Testers&wanted:&polling(4)&support&for&vr(4)&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/4.htmlDevice&polling,&kern.polling.burst_max&and&gig-e&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/0.htmlDEVICE_POLLING&with&SMP&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/9.htmlPaper&on&device&polling&and&packet&capture&performance&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/0.htmlRe:&Polling&CPU&usage&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/7.htmlPolling&CPU&usage&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/9.htmlDEVICE_POLLING&together&with&link0&interrupt&offloading?&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/6.htmlDevice&polling&support&for&em&and&bge&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/8.htmlFreeBSD-performanceRe:&[fbsd]&Re:&Device&polling&heavy&traffic&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/2006-01/msg00006.htmlDevice&polling&heavy&traffic&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/2005-12/msg00069.htmlpolling&in&4.11&vs&5.4&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/7.htmlfreebsd&router&project.&Problems&with&polling?&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/1.htmlFreeBSD-hackersem0,&polling&performance,&P4&2.8ghz&FSB&800mhz&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/9.htmlDevice&polling,&with&SMP?&&&&http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/9.html[&本帖最后由&雨丝风片&于&&09:24&编辑&]
&xfsoul 回复于： 09:08:24
谢谢楼上几位达人热心相助，尤其是版主兄，真是非常敬业。我们还有几个硬件平台没有测试。在现有的平台上，我先更新驱动程序测试，更换4.11版本FreeBSD进行测试，同时再查阅polling的相关资料。希望各位能继续关注和帮助我。
&雨丝风片 回复于： 09:23:20
引用：原帖由&xfsoul&于&&09:08&发表谢谢楼上几位达人热心相助，尤其是版主兄，真是非常敬业。我们还有几个硬件平台没有测试。在现有的平台上，我先更新驱动程序测试，更换4.11版本FreeBSD进行测试，同时再查阅polling的相关资料。希望各位能继续关注&...&我原来没有研究过这个题目，也是从xie_minix的文章中才了解了大概，所以目前只能帮你做点打杂的工作。&:D&关键还是要靠你的辛苦测试、xie_minix的理论分析、还有大家的讨论。希望通过大家的努力，能够把这里面的问题分析清楚。:D
&xfsoul 回复于： 09:54:56
透露一下，同一台工控机，在linux&2.6.9内核下网桥转发不丢包测试数据如下（双向各是这么多，后面为CPU占用率）：64字节：17.8万pps/100%&128字节：12.8万pp/94%&&&256字节:7.7万pps/62%&&&1518：3万pps/46%。在FreeBSD下，如果不开polling（编译内核时没有加入polling选项），性能就比linux差：
&colddawn 回复于： 10:15:21
到现在没看明白lz的环境，既然是做网桥，怎么又测试的是转发性能？难道是词语的意思我没理解？到底是纯桥接性能的测试还是牵扯到了三层转发？如果是后者，估计要提高性能不太容易，前者的话最好说明下你用的哪个网桥，FB5.3以后有bridge和if_bridge两种，后者是新近从netbsd引进的，性能貌似还不是很稳定，前者的代码已经最少有3年没更新了，不过性能还是不错的。另外就是是否加载了包过滤机制等，内核配置文件等。最好详细说下，有时一些小地方很容易对性能产生比较大的影响。
&雨丝风片 回复于： 10:23:52
引用：原帖由&colddawn&于&&10:15&发表到现在没看明白lz的环境，既然是做网桥，怎么又测试的是转发性能？难道是词语的意思我没理解？到底是纯桥接性能的测试还是牵扯到了三层转发？如果是后者，估计要提高性能不太容易，前者的话最好说明下你用的哪个网&...&嗯，楼主不妨把自己的试验环境和配置情况做个比较详细的说明，有图更好！:mrgreen:
&xfsoul 回复于： 10:38:53
网桥就是工作在二层的啊。if_bridge不就是用来透明转发的么？当然测试双向转发性能了。
&colddawn 回复于： 11:10:10
哦，说透明转发就能理解是二层转发了，否则我会默认你所谓转发为三层ip转发的，这里很容易误解的。如果是if_bridge，那从6.0-6.1甚至几个patch之间似乎都有不小变动的，并且就我个人使用来看性能目前远不如bridge，你可以先用bridge试试看。
&xfsoul 回复于： 11:29:51
楼上的兄弟，if_bridge和bridge有什么差别？？我是安装如下方法加网桥功能的：在内核配置文件中加入如下三项重新编译内核：options&BRIDGEoptions&DEVICE_POLLINGoptions&HZ=1000
&xfsoul 回复于： 11:30:47
怎么使用bridge呢？
&LnBSD 回复于： 11:36:53
引用：原帖由&xfsoul&于&&11:30&发表怎么使用bridge呢？&你现在用的就是bridge千兆网卡可以调大一点options&HZ=4000－－6000等待你的测试结果[&本帖最后由&LnBSD&于&&11:38&编辑&]
&xfsoul 回复于： 11:47:26
我现在用bridge性能也这么差。看来我换if_bridge看看能不能好点。
&xfsoul 回复于： 11:49:32
引用：原帖由&LnBSD&于&&11:36&发表你现在用的就是bridge千兆网卡可以调大一点options&HZ=4000－－6000等待你的测试结果&这个数字我尝试过600、、，结果性能都没有是1000的时候好。
&xfsoul 回复于： 13:13:40
我换成if_bridge以后，发现性能果然更差了。
&LnBSD 回复于： 13:15:37
引用：原帖由&xfsoul&于&&13:13&发表我换成if_bridge以后，发现性能果然更差了。&tryfb4.11
&xfsoul 回复于： 14:27:57
呆会我将我测试到的最好的结果发上来。options&&&&&&&&SCHED_ULE我打开了这一项，为什么编译内核就会出错？提示kern_switch.c中有宏没有定义。
&colddawn 回复于： 15:04:04
SCHED_ULE&和SCHED_4BSD不能同时存在，你是不是忘记注释掉另外一个了？另外在测试的时候记录几次这几个命令的输出结果：sysctl&-a|grep&pollingsysctl&-a|grep&bridge[&本帖最后由&colddawn&于&&15:05&编辑&]
&xfsoul 回复于： 18:49:02
硬件平台：Intel&P4&2.8B&533外频网卡&&双Intel千兆PCI-X网卡&工作在64bit&100MHz，组成bridge双千兆网线Smartbit千兆口两个软件平台：Smartwindow&9.0Redhat&Enterprise&Linux&4U1FreeBSD&6.1包长包含了以太网桢头部和尾部带宽指带宽利用率，利用了千兆的百分之几.包速率是pps，每秒发送的数据包的速度。用smartbit双向以相同的速率发包，统计的是没有丢包时的峰值性能，包速率和带宽的记录值是单向的值。所以总速率应该在此基础上乘以二。FreeBSD6.1系统开了polling，下面的测试记录是在多次尝试调整polling参数得出的最佳结果。包长&&&&linux(带宽/包速率/CPU使用率)&&&&&&&&&&FreeBSD&6.164&&&&&&&&12%&&&&&.6%&&&&&&&&&&&&&&12.88%&&%128&&&&&&15.2%&&&.4%&&&&&&&&&&&&&&15.28%&&.4%256&&&&&&17.1%&&&77447&&&&62%&&&&&&&&&&&&&&&&17.5%&&&&78125&&&0.4%512&&&&&&25.2%&&&59231&&&&60%&&&&&&&&&&&&&&&&19.99%&&&46624&&&0%1024&&&&32.4%&&&38795&&&&49%&&&&&&&&&&&&&&&&&21%&&&&&&&25045&&&0%1500&&&&36.4&&&&&&29585&&&&46.5%&&&&&&&&&&&&&&21%&&&&&&&17222&&&0%[&本帖最后由&xfsoul&于&&19:03&编辑&]
&xie_minix 回复于： 02:47:49
测试的数据非常有意思,大家看到没有,在包大于256字节的时候,FB就不行了,估计和MBUF有关.大家知道,FB的MBUF大小是256字节.如果包大于256字节,m_devget函数执行起来就麻烦多了.xfsoul你可以把#define&MSIZE
/*&size&of&an&mbuf&*/改成#define&MSIZE
PAGE_SIZE /*&size&of&an&mbuf&*/如果情况可以,再调到2进行测试
&xfsoul 回复于： 08:41:27
楼上的大哥，您太强了！不过有三个MSIZE的定义，而且值还不一样，到底要怎么改呢？-bash-2.05b#&cd&/usr/src/sys-bash-2.05b#&grep&-r&"#define&MSIZE"&*compile/NTD/machine/param.h:#define&MSIZE&&&&&&&&&&&&&&&256&&&&&&&&&&&&&/*&size&of&an&mbuf&*/i386/boot/dosboot/param.h:#define&MSIZE&&&&&&&&&128&&&&&&&&&&&&&/*&size&of&an&mbuf&*/i386/include/param.h:#define&MSIZE&&&&&&&&&&&&&&256&&&&&&&&&&&&&/*&size&of&an&mbuf&*/-bash-2.05b#
&xfsoul 回复于： 08:44:35
我觉得是不是polling太吃内存了？所以CPU利用率很低，性能也不行，因为内存不够快了？把MSIZE改那么大，有负面影响吗？我改为2048就可以了吧？而且把MSIZE改大了，小包性能有无下降，还要进行测试。
&雨丝风片 回复于： 08:53:37
引用：原帖由&xfsoul&于&&08:41&发表楼上的大哥，您太强了！不过有三个MSIZE的定义，而且值还不一样，到底要怎么改呢？-bash-2.05b#&cd&/usr/src/sys-bash-2.05b#&grep&-r&"#define&MSIZE"&*compile/NTD/machine/param.h:#define&&...&改这个里面的：/usr/src/sys/sys/param.h
&antijp 回复于： 08:54:39
Before&you&modify&the&value,&use&sysctl&-a&|grep&mbuf&to&check&the&mbuf&utilization.&According&to&TCP/IP&Illustrated&Vol.2,&bigger&packets&uses¬&only&mbuf,&but&also&mbufclusters.
&antijp 回复于： 08:56:58
引用：原帖由&雨丝风片&于&&08:53&发表改这个里面的：/usr/src/sys/sys/param.h&I&think&modify&the&source&file&is&finding&trouble.Simply&recompile&the&kernel&with&thisoptions&MSIZE=512in&your&kernel&configuration&file.
&xfsoul 回复于： 09:05:43
#&sysctl&-a&|&grep&mbuf&&&&&mbuf_tag&&&&&0&&&&&0K&&&&&&&-&&&&&&&&2&&32mbuf_jumbo_1:&&16384,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_jumbo_9:&&&9216,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_jumbo_p:&&&4096,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_cluster:&&&2048,&&&&16960,&&&2176,&&&&&&6,&&&&&2176mbuf:&&&&&&&&&&&&256,&&&&&&&&0,&&&2178,&&&&132,&&&&&6933mbuf_packet:&&&&&256,&&&&&&&&0,&&&1024,&&&214
&雨丝风片 回复于： 09:08:04
引用：原帖由&antijp&于&&08:54&发表Before&you&modify&the&value,&use&sysctl&-a&|grep&mbuf&to&check&the&mbuf&utilization.&According&to&TCP/IP&Illustrated&Vol.2,&bigger&packets&uses¬&only&mbuf,&but&also&mbufclusters.&楼主测试的数据包大小是确定的，改这个值就是想尽量避免使用cluster，看看从对纯mbuf的处理和对cluster的处理流程上是否能找到一些线索。但我感觉应该不只是处理流程的区别，很可能和内存的分配、缓存、复用也有关系。多试无妨。:D
&xie_minix 回复于： 09:14:54
xfsoul:等你的消息,我想看看到底是不是m_devget的问题另:antijp的方法很好.我对使用FB不太熟悉[&本帖最后由&xie_minix&于&&09:16&编辑&]
&antijp 回复于： 09:36:10
引用：原帖由&雨丝风片&于&&09:08&发表楼主测试的数据包大小是确定的，改这个值就是想尽量避免使用cluster，看看从对纯mbuf的处理和对cluster的处理流程上是否能找到一些线索。但我感觉应该不只是处理流程的区别，很可能和内存的分配、缓存、复用也&...&According&to&the&statistics&posted&out,&the&mbufclusters&must&have&been&used.&But&I&doubt&that&this&statistics&was¬&gathered&when&running&the&benchmark,&so&perhaps&it's¬&very&useful.[&本帖最后由&antijp&于&&09:46&编辑&]
&雨丝风片 回复于： 09:47:13
引用：原帖由&antijp&于&&09:36&发表According&to&the&statistics&posted&out,&the&mbufclusters&must&have&been&used.&But&I&doubt&that&this&statistics&was¬&gathered&when&running&the&benchmark,&so&perhaps&it't¬&very&useful.&从楼主的数据长度即可判断出测试的时候肯定会使用cluster了：引用：If&the&amount&of&data&is&greater&than&or&equal&to&208&(MINCLBYTES),&one&or&more&clusters&are&used.当然，由于mbuf头结构的修改，目前的门限数值比208还要小。现在就是想先看看它不用cluster的时候的测试性能如何。:D
&xfsoul 回复于： 09:50:36
我编译内核加了：options&&&&&&&&&MSIZE=1024&&options&&&&&&&&&BRIDGEoptions&&&&&&&&&DEVICE_POLLINGoptions&&&&&&&&&HZ=4000编译好后，测试包长为512字节，&发现性能没有丝毫提升。下面是smartbit发包的时候，读出来的系统数据：#&sysctl&kern.pollingkern.polling.idlepoll_sleeping:&1kern.polling.stalled:&66kern.polling.suspect:&6042kern.polling.phase:&0kern.polling.enable:&1kern.polling.handlers:&4kern.polling.residual_burst:&0kern.polling.pending_polls:&0kern.polling.lost_polls:&6762kern.polling.short_ticks:&1178kern.polling.reg_frac:&20kern.polling.user_frac:&30kern.polling.idle_poll:&0kern.polling.each_burst:&100kern.polling.burst_max:&300kern.polling.burst:&300#&sysctl&-a&|&grep&mbuf&&&&&mbuf_tag&&&&&0&&&&&0K&&&&&&&-&&&&&&&&2&&32mbuf_jumbo_1:&&16384,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_jumbo_9:&&&9216,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_jumbo_p:&&&4096,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_cluster:&&&2048,&&&&16960,&&&1920,&&&&&&6,&&&&&1920mbuf:&&&&&&&&&&&1024,&&&&&&&&0,&&&1922,&&&&126,&&&&&1245mbuf_packet:&&&&1024,&&&&&&&&0,&&&1990,&&&&&58,&[&本帖最后由&xfsoul&于&&09:52&编辑&]
&colddawn 回复于： 09:54:52
kern.polling.burst_max:&300kern.polling.burst:&300这两个值一样，似乎burst不够用了，继续调大些试试看？？
&colddawn 回复于： 09:59:18
另外注意到你测试的数据FB的CPU占用率方面比较奇怪，尤其是小包的第一个50%，是不是开启了HTT？关闭掉试试看。还有这个参数kern.polling.user_frac:&Desired&user&fraction&of&cpu&time把user占用的cpu时间片尽量压缩，这样内核CPU利用率会比较高，毕竟linux下都高过90%了，FB这么少说明是有问题的。
&xfsoul 回复于： 10:00:19
引用：原帖由&colddawn&于&&09:54&发表kern.polling.burst_max:&300kern.polling.burst:&300这两个值一样，似乎burst不够用了，继续调大些试试看？？&HZ=4000burst=300理论可以发120万pps呢。ps:我调成500性能也无变化
&xfsoul 回复于： 10:02:16
引用：原帖由&colddawn&于&&09:59&发表另外注意到你测试的数据FB的CPU占用率方面比较奇怪，尤其是小包的第一个50%，是不是开启了HTT？关闭掉试试看。还有这个参数kern.polling.user_frac:&Desired&user&fraction&of&cpu&time把user占用的cpu时间片&...&那个参数调整到更小也没有意义，我从5开始每10一个档都调节过了。CPU利用率很低&我也很奇怪，为什么这么多资源FB不去使用。但是如果不开polling，CPU占用就上去了，也是90%多。
&colddawn 回复于： 10:03:42
kern.polling.burst:&Current&polling&burst&sizefw2#&sysctl&-d&kern.polling.burst_maxkern.polling.burst_max:&Max&Polling&burst&size应该是要调整max，lz是说错了还是调错了？
&xfsoul 回复于： 10:05:49
引用：原帖由&colddawn&于&&10:03&发表kern.polling.burst:&Current&polling&burst&sizefw2#&sysctl&-d&kern.polling.burst_maxkern.polling.burst_max:&Max&Polling&burst&size应该是要调整max，lz是说错了还是调错了？&我就是调整的maxsysctl&kern.polling.burst_max=150sysctl&kern.polling.burst_max=200sysctl&kern.polling.burst_max=300sysctl&kern.polling.burst_max=400sysctl&kern.polling.burst_max=500sysctl&kern.polling.burst_max=1000都试过了。我测试的数据是我微调内核参数得到的最好数据。
&xie_minix 回复于： 10:24:03
我还是希望能看到大概每秒执行软中断的次数(POLLING),这样可以确定调度器及系统的基本情况.我在我家里的机器上(SMP&PII&450&&256M&&if_vr&*&1)3.&一些测试值:&&&kern.polling.dbg.poll_coun:&5404323&&软中断实现的总次数,默认设置每秒大概在30000左右次调用kern.polling.dbg.pollmore_coun:&4952549kern.polling.dbg.poll_suspect:&0kern.polling.dbg.poll_invoke:&24&从硬件时钟中断到netisr_poll的毫秒kern.polling.dbg.net_load:&30&从NETISR_POLL到NETISR_POLLMORE的毫秒kern.polling.burst:&150kern.polling.burst_max:&150kern.polling.each_burst:&20kern.polling.idle_poll:&0kern.polling.user_frac:&50kern.polling.reg_frac:&20kern.polling.short_ticks:&258kern.polling.lost_polls:&4kern.polling.pending_polls:&0kern.polling.residual_burst:&0kern.polling.handlers:&1kern.polling.enable:&1kern.polling.phase:&0kern.polling.suspect:&2kern.polling.stalled:&0kern.polling.idlepoll_sleeping:&1[&本帖最后由&xie_minix&于&&10:26&编辑&]
&antijp 回复于： 10:24:28
引用：原帖由&雨丝风片&于&&09:47&发表从楼主的数据长度即可判断出测试的时候肯定会使用cluster了：当然，由于mbuf头结构的修改，目前的门限数值比208还要小。现在就是想先看看它不用cluster的时候的测试性能如何。:D&Less&than&208?&I've&traced&the&code.&sizeof(m_hdr)&==&24,&sizeof(pkthdr)&==&24,&without&m_ext,&the&maximum&size&of&the&data&can&be&stored&is&208.&These&number&is&when&you&are&running&on&i386.I'm&running&amd64,&so&the&calculation&may&be&incorrect,&and&under&amd64&sizeof(m_hdr)==sizeof(pkthdr)==40,&it's&so&depressing...:em12:
&xfsoul 回复于： 10:31:28
我把msize改为4096性能也无提升，看来不是MSIZE的问题：下面是发包的时候抓下来的系统参数：[color=Red]现在CPU占用率倒是上去了，发512字节的包的时候，到达了平均27%。我又测试了64字节的性能，也没有提升！[/color][color=Blue]在64字节下，双向各以18万pps速率发包的时候，CPU占用率也大幅提高，到达81%！可恨的是性能并无丝毫提升！[/color]#&sysctl&-a&|&grep&mbuf&&&&&mbuf_tag&&&&&0&&&&&0K&&&&&&&-&&&&&&&&2&&32mbuf_jumbo_1:&&16384,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_jumbo_9:&&&9216,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_jumbo_p:&&&4096,&&&&&&&&0,&&&&&&0,&&&&&&0,&&&&&&&&0mbuf_cluster:&&&2048,&&&&16960,&&&2048,&&&&&&6,&&&&&2048mbuf:&&&&&&&&&&&4096,&&&&&&&&0,&&&2050,&&&&126,&&&&&&746mbuf_packet:&&&&4096,&&&&&&&&0,&&&1983,&&&&193,&&3819588#&sysctl&-a&|&grep&kern.pollingkern.polling.idlepoll_sleeping:&1kern.polling.stalled:&66kern.polling.suspect:&6078kern.polling.phase:&0kern.polling.enable:&1kern.polling.handlers:&4kern.polling.residual_burst:&0kern.polling.pending_polls:&0kern.polling.lost_polls:&8083kern.polling.short_ticks:&1400kern.polling.reg_frac:&200kern.polling.user_frac:&20kern.polling.idle_poll:&0kern.polling.each_burst:&300kern.polling.burst_max:&500kern.polling.burst:&500强烈怀疑是内存操作速度太慢所致。可是怎么验证呢。[&本帖最后由&xfsoul&于&&10:35&编辑&]
&雨丝风片 回复于： 11:06:48
引用：原帖由&antijp&于&&10:24&发表Less&than&208?&I've&traced&the&code.&sizeof(m_hdr)&==&24,&sizeof(pkthdr)&==&24,&without&m_ext,&the&maximum&size&of&the&data&can&be&stored&is&208.&These&number&is&when&you&are&running&on&i386.I'&...&呵呵，是我没注意。Stevens写书的时候用的MSIZE是128，那个时候决定MINCLSIZE的方法就是两个mbuf的数据区大小，一个带packet头，一个不带。因此，Stevens所举的4.4BSD中的MINCLSIZE就是128-20+128-20-8&=&208，也就是说只要用两个mbuf无法存储的数据，就需要使用cluster。（使用这个算法，如果MSIZE是256，则MINCLSIZE为464）后来，mbuf的头结构确实是扩展了，但MINCLSIZE的计算方法也改了。假设MSIZE为256，则MINCLSIZE为256-24-24+1&=&209，凡大于等于这个数值的数据就需要使用cluster。相对于4.4BSD中MSIZE同样等于256的情况（MINCLSIZE&=464），这个门限降低了一半。
&antijp 回复于： 12:16:11
Now&I'm&building&6.1&on&another&i386&machine,&I'll&check&the&size&later.
&antijp 回复于： 12:41:53
I've&checked&the&two&sizes,&sizeof(pkthdr)&==&sizeof(m_hdr)&==&24,&and&sizeof(m_ext)&also&equals&to&24.MINCLSIZE&is&209.&This&design&removes&a&indirect&pointer&and&would&make&performance&better.
&colddawn 回复于： 14:15:39
个人感觉这个测试结果大包性能提升不太像mbuf大小问题。
&mirnshi 回复于： 15:00:29
帖子好长呀，看了半天。如果是桥模式，从网卡中断开始，一直到这个包不在2层，都是在一个中断里，所以桥转发的效率很关键，专做桥设备就需要增加队列之类的，提高包响应速度了，否则仅仅要响应中断，系统就受不了了。polling模式在某些情况下是可以提高效率的，polling模式主要原理就是网卡将数据包放到队列中，cpu通过轮训的方式获取数据包，属于主动方式，而中断相当于被动接收。如果cpu在轮训间隔内可以有效地处理队列中的包，就可以提高效率，否则就会降低效率。查看系统效率，尤其是网卡的，不仅仅要看vmstat，netstat可是必须要看的，可以看到包流量，错误数等等。在有足够cpu处理的情况下，如果流量上不去，那就要看看网卡了，看看错误数是不是很高。这些数据都是互相影响的，但也不能作为唯一判定值。所以一定要通过判断vmstat，netstat的监测数据，在去调整相应参数。将mbuf的尺寸增大，并不会带来特别显著的提高，系统会根据包的大小，自动分拆的，大家可以看看协议栈的实现。
&caibird3rd 回复于： 15:13:44
注意别把注意力全放在操作系统上，测试机本身（所用总线规格等）、网络连接、smartbit的设置&等等都应该检查一遍
&xie_minix 回复于： 16:07:54
其实楼主的要求很简单,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.我们是来给他想办法,同时也提高我们自己.去寻找具体原因.你可以怀疑某个地方出问题,即使是比较幼稚的想法.但必须去实现.用代码或调试各种参数去测试.另外说句:&楼上的caibird3rd明显没进入状态.哈哈已经有很多人都在反映该问题.我知道的许多非常专业的放火墙开发人员(DDOS方向)也遇到此问题.到目前还没有解决.以至于他们转向了LINUX.对于现在的FB,锁的粗细粒度使用的还是有问题.比如大家看看POLLING的5.3.使用GAINT太多,还有些代码重复,不多评论了.继续检查
&www_ftp 回复于： 16:54:39
在Free&BSD&6.0以后,polling的确不起什么作用,就是调的参数再好,最多只能达到不开polling的程度.在linux下也测试过打不打开polling性能也没有什么变化.听过4.11打开与不打开polling差别很大.
&xfsoul 回复于： 17:21:23
我现在已经不指望通过调节FreeBSD参数来提高性能了。我暂停这个测试，下周继续在另外一个平台上测试性能。我已经配置好了FreeBSD&4.11和FreeBSD6.1双系统。对于该平台，linux的性能已经测试过了，由于该平台性能比较强，linux表现还过得去。硬件平台：CPU：双路Opteron&2.4G内存：1G&DDR400&双通道开启，ECC关闭网卡：Intel双光纤口网卡、Intel双口网卡。这四个网卡都是连接在北桥上，PCI-X&64bit，&133MHz。大约下周二开始测试。大家有空不妨帮我想想办法呵，我先谢过了。
&caibird3rd 回复于： 17:29:35
引用：原帖由&xie_minix&于&&16:07&发表其实楼主的要求很简单,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.我们是来给他想办法,同时也提高我们自己.去寻找具体原因.你可以怀疑某个地方出问题,即使是比较幼稚的想法.但必须去实现.用代码或调试各种参数去测试.另外说句:&楼上的caibird3rd明显没进入状态.哈哈已经有很多人都在反映该问题.我知道的许多非常专业的放火墙开发人员(DDOS方向)也遇到此问题.到目前还没有解决.以至于他们转向了LINUX.对于现在的FB,锁的粗细粒度使用的还是有问题.比如大家看看POLLING的5.3.使用GAINT太多,还有些代码重复,不多评论了.继续检查&...哈哈，对FB我倒是不熟，只是略有耳闻FB的性能如何稳定和有效率，真的比Linux差很多吗？说老实话，对于比较成熟的一个发行版来说，其运行时的各种缺省参数一般都是仔细调优了的，充分权衡了各个子系统的影响、考虑到了各类常见应用环境。怀疑仅仅通过调整参数，能够获得多大的性能提升。我的经验，这种情况，要么是系统代码内在结构决定，要么就是硬件平台甚至测试环境的影响。不是我瞧不起各位老大的能力，前者的分析很难啊。在这里给各位加油，希望有一天FB里面也有大量国人的补丁，呵呵
&mirnshi 回复于： 17:49:48
引用：原帖由&caibird3rd&于&&17:29&发表哈哈，对FB我倒是不熟，只是略有耳闻FB的性能如何稳定和有效率，真的比Linux差很多吗？说老实话，对于比较成熟的一个发行版来说，其运行时的各种缺省参数一般都是仔细调优了的，充分权衡了各个子系统的影&...&无论OS，还是DB，它的发行版都是为了适合绝大多数情况的，要想在某种应用和场合发挥最大的性能，各项参数是必须调整的。所以不要这么讲，否则各类系统的管理员就要失业了。
&xie_minix 回复于： 18:11:25
mirnshi:我猜想,开发POLLING的团队有问题.他们对MUTEX的了解不够,最起码在5.3版本时.这是最要命的事情.其次,写代码时没经过思考(请原谅我这么说,他们也不容易),比如你看:5.3版本poll_idle(void)中mtx_lock(&Giant);&&---------ether_poll(poll_each_burst);mtx_unlock(&Giant);在看ether_poll()ether_poll(int&count){int&i;mtx_lock(&Giant);&&&&&---------他是不是怕没锁住啊,哈哈
&xfsoul 回复于： 18:23:16
引用：原帖由&xie_minix&于&&18:11&发表mirnshi:我猜想,开发POLLING的团队有问题.他们对MUTEX的了解不够,最起码在5.3版本时.这是最要命的事情.其次,写代码时没经过思考(请原谅我这么说,他们也不容易),比如你看:5.3版本poll_idle(void)中mtx&...&实在晕倒，BSD内核中也有这样质量的代码？
&caibird3rd 回复于： 19:05:58
引用：原帖由&xie_minix&于&&18:11&发表mirnshi:我猜想,开发POLLING的团队有问题.他们对MUTEX的了解不够,最起码在5.3版本时.这是最要命的事情.其次,写代码时没经过思考(请原谅我这么说,他们也不容易),比如你看:5.3版本poll_idle(void)中mtx&...&不晓得是不是跟linux的大内核锁一样，可以重复进入的？ether_poll（）说不定在别的地方还有调用到，所以要加锁大内核锁在linux里已经很少用到了。看来linux更注重性能的说法有一定道理另外，不晓得FB有没有针对Opteron的优化？楼主用的Opteron应该很牛啦[&本帖最后由&caibird3rd&于&&19:08&编辑&]
&xfsoul 回复于： 19:36:07
还有更牛的，双路Opteron&270，就是四个2.0G的Opteron处理器。另外还有双路双核XEON，每个CPU都支持HT。系统应该会认出八个CPU。不过在双路Opteron&250上也无法改善FreeBSD性能的话。就只有用linux了。
&mirnshi 回复于： 22:07:54
引用：原帖由&xie_minix&于&&18:11&发表mirnshi:我猜想,开发POLLING的团队有问题.他们对MUTEX的了解不够,最起码在5.3版本时.这是最要命的事情.其次,写代码时没经过思考(请原谅我这么说,他们也不容易),比如你看:5.3版本poll_idle(void)中mtx&...&6.x中的代码，不同呀。主版本3、5都不是很好，命短。/*&*ðer_poll&is&called&from&the&idle&loop.&*/voidether_poll(int&count){ int&i; NET_LOCK_GIANT(); mtx_lock(&poll_mtx); if&(count&&&poll_each_burst)
count&=&poll_each_ for&(i&=&0&;&i&&&poll_handlers&;&i++)
pr.handler(pr.ifp,&POLL_ONLY,&count); mtx_unlock(&poll_mtx); NET_UNLOCK_GIANT();}static&voidpoll_idle(void){ struct&thread&*td&=& struct&rtprio& rtp.prio&=&RTP_PRIO_MAX; /*&lowest&priority&*/ rtp.type&=&RTP_PRIO_IDLE; mtx_lock_spin(&sched_lock); rtp_to_pri(&rtp,&td-&td_ksegrp); mtx_unlock_spin(&sched_lock); for&(;;)&{
if&(poll_in_idle_loop&&&&poll_handlers&&&0)&{
idlepoll_sleeping&=&0;
ether_poll(poll_each_burst);
mtx_lock_spin(&sched_lock);
mi_switch(SW_VOL,&NULL);
mtx_unlock_spin(&sched_lock);
idlepoll_sleeping&=&1;
tsleep(&idlepoll_sleeping,&0,&"pollid",&hz&*&3);
} }}个人感觉，还是扔掉5.x吧，因为当初粗粗看了5.x，就觉得是个试验品，就没有仔细看，一直在4.x上做。6.1出来了，应该算是稳定住了
&mirnshi 回复于： 22:17:24
引用：原帖由&xfsoul&于&&19:36&发表还有更牛的，双路Opteron&270，就是四个2.0G的Opteron处理器。另外还有双路双核XEON，每个CPU都支持HT。系统应该会认出八个CPU。不过在双路Opteron&250上也无法改善FreeBSD性能的话。就只有用linux了。&个人以为，双核并不是完全意义上的“双CPU”，在目前的这种IA架构上，CPU多了，不见得是好事，这些CPU调度起来都是件麻烦事。从我目前了解到的以及实验数据来说，cpu的处理速度足够了应付中低端(1G及1G以下)，只是总线有问题，所以网络的速度跟不上。
&雨丝风片 回复于： 08:27:06
引用：原帖由&xie_minix&于&&18:11&发表我猜想,开发POLLING的团队有问题.他们对MUTEX的了解不够,最起码在5.3版本时.这是最要命的事情.其次,写代码时没经过思考(请原谅我这么说,他们也不容易),比如你看:...&原作者在此：:mrgreen:[attach]141536[/attach]但从André&Oppermann的一篇文章来看，6.0专门针对SMP的情况对polling进行了修改：[font=Courier&New]引用：Interface&PollingThe&network&interface&polling&implementation&has&been&re-implemented&to&work&correctly&in&SMP&environments.&Polling&is&no&longer&a&global&configuration&variable&but&enabled&or&disabled&individually&per&interface&if&the&driver&supports&it.&Most&commonly&found&network&drivers&support&polling.[/font]而且，从kern_poll.c文件的cvs记录来看，对锁的使用进行优化的工作也一直在进行，比如：http://lists.freebsd.org/pipermail/cvs-src/2005-September/051848.html
&雨丝风片 回复于： 08:36:27
引用：原帖由&xfsoul&于&&18:23&发表实在晕倒，BSD内核中也有这样质量的代码？&先污染，后治理。:mrgreen:[&本帖最后由&雨丝风片&于&&08:51&编辑&]
&雨丝风片 回复于： 09:24:11
引用：原帖由&mirnshi&于&&15:00&发表将mbuf的尺寸增大，并不会带来特别显著的提高，系统会根据包的大小，自动分拆的，大家可以看看协议栈的实现。&...&请教一下，这个分拆体现在哪儿？扩大mbuf尺寸，不考虑是否真能提高性能，至少可以尽量避免系统使用mbuf链或者cluster。另外，楼主两个网卡mtu一致，而且是二层转发，似乎也涉及不到ip&fragmentation的问题。所以请教这个“自动分拆”的含义？&:D
&colddawn 回复于： 09:47:57
他的意思是指包在mbuf和cluster的分拆而不是包数据本身分拆，所以跟MTU无关了，使用cluster是有好处的，例如对于同一包的数据处理可以直接通过指向cluster指针，增加引用计数器，避免数据复制等。如果不使用cluster可以大幅度增加性能当初设计就不会有cluster了。
&雨丝风片 回复于： 09:57:03
引用：原帖由&colddawn&于&&09:47&发表他的意思是指包在mbuf和cluster的分拆而不是包数据本身分拆，所以跟MTU无关了，使用cluster是有好处的，例如对于同一包的数据处理可以直接通过指向cluster指针，增加引用计数器，避免数据复制等。如果不使用clust&...&不是讨论是否需要使用、当时是否有必要设计cluster。我的意思很简单，系统是否使用mbuf链或者mcluster来存储网络数据都取决于mbuf的尺寸，既然把mbuf尺寸调整到足以存放楼主测试的全部数据，又何来“包在mbuf和cluster的分拆”呢？
&mirnshi 回复于： 10:30:47
引用：原帖由&雨丝风片&于&&09:24&发表请教一下，这个分拆体现在哪儿？扩大mbuf尺寸，不考虑是否真能提高性能，至少可以尽量避免系统使用mbuf链或者cluster。另外，楼主两个网卡mtu一致，而且是二层转发，似乎也涉及不到ip&fragmentation的问题&...&这个分拆，是不恰当的，我的本意是分拣。写完后，没有仔细审看，表示歉意。在协议栈实现中，会根据包的大小，申请不同的mbuf。而且在我的印象中，从网卡上来的包使用不到cluster，或者说承担转发时，是不使用cluster的，只有从会话层下来的时候，由于数据包很大，需要拆成适宜大小并组成cluster。所以我以往的经验，做网关类，不必调整cluster的数量，mbuf的数量倒是很重要，如果有大队列，还要调整内核可使用的内存空间大小。所以你即便将mbuf调得很大，协议栈还是要判断一下，再去申请。系统缺省已经有2k的了，足够应付链路上的包了，那你说提高最小的mbuf有必要吗？只会浪费内存。
&雨丝风片 回复于： 11:41:27
引用：原帖由&mirnshi&于&&10:30&发表在协议栈实现中，会根据包的大小，申请不同的mbuf。而且在我的印象中，从网卡上来的包使用不到cluster，或者说承担转发时，是不使用cluster的，只有从会话层下来的时候，由于数据包很大，需要拆成适宜大小并组成cluster。所以我以往的经验，做网关类，不必调整cluster的数量，mbuf的数量倒是很重要，如果有大队列，还要调整内核可使用的内存空间大小。所以你即便将mbuf调得很大，协议栈还是要判断一下，再去申请。系统缺省已经有2k的了，足够应付链路上的包了，那你说提高最小的mbuf有必要吗？只会浪费内存。&...&“从网卡上来的包使用不到cluster”，那m_devget()函数中的此段代码何解？&:D
if&(totlen&+&off&&=&MINCLSIZE)&{
m&=&m_getcl(M_DONTWAIT,&MT_DATA,&M_PKTHDR);
len&=&MCLBYTES;
m&=&m_gethdr(M_DONTWAIT,&MT_DATA);
len&=&MHLEN;“所以你即便将mbuf调得很大，协议栈还是要判断一下，再去申请。”，修改mbuf的大小，就是要影响协议栈的上述“判断”过程。上面是和你讨论“拆分”的事情，现在回到楼主的测试，修改mbuf的大小只是尝试上述不同的分配策略是否会对此造成影响，这主要是流程性的影响。如你所说，可供mbuf使用的内存数量确实也是一个关键，我们可以在测试过程中关注内存的使用情况，看看这方面是否有瓶颈。
&xfsoul 回复于： 11:53:19
内存占用到不大。应该是性能拷贝的性能消耗太大。
&xie_minix 回复于： 12:46:21
netisr_pollmore函数中的 kern_load&=&(kern_load&*&hz)&/&10000;这句有问题.应该错了.他的错误的算法将导致hz在默认100时性能...kern.polling.dbg.pollkern:&1&&&&&&&&&&&&这是网络软中断所占比率为1%kern.polling.dbg.kernpoll_burst:&150&&&以至于poll_burst不断增加到顶.kern.polling.dbg.on_cpu1:&0kern.polling.dbg.net_load:&0kern.polling.dbg.poll_invoke:&kern.polling.dbg.poll_suspect:&744461kern.polling.dbg.pollmore_coun:&719577kern.polling.dbg.poll_coun:&744461下个帖有说明,是我的想法有问题.[&本帖最后由&xie_minix&于&&13:47&编辑&]
&xfsoul 回复于： 13:26:04
xie_minix兄、版主兄还有其他几位兄弟，大家一起努力啊。如果能把FreeBSD&polling的一些缺陷修正，也算是对FreeBSD的不小贡献了。
&xie_minix 回复于： 13:46:19
不对,还是我错了,向大家解释一下:if&(kern_load&&&(100&-&user_frac))&{&这句的原本意思是:求软件中断在整个1秒时间所占百分比是否大于减去其他所占用时间.大于就说明时间够了.poll_burst--;小于则poll_burst++只要加后不大于最大值.poll_burst的值很重要,要不然就不能体现出整个算法的合理性.我们在来看看kern_load&=&(kern_load&*&hz)&/&10000;这句是为了求得网络软中断所占1秒中的比率.10000这个常量有点很难懂.kern_load之前得到的是软件中断所使用的毫秒.那么kern_load*hz代表每秒钟软中断大概是占了多少毫秒,这样推算的话,10000应该是,即先除以1百万毫秒(1秒)得到百分比,再乘以100取出百分数.哎这个10000也不写个说明.[&本帖最后由&xie_minix&于&&13:48&编辑&]
&雨丝风片 回复于： 14:07:45
引用：原帖由&xie_minix&于&&13:46&发表不对,还是我错了,向大家解释一下:if&(kern_load&&&(100&-&user_frac))&{&这句的原本意思是:求软件中断在整个1秒时间所占百分比是否大于减去其他所占用时间.大于就说明时间够了.poll_burst--;小于则p&...&原来如此！看来此公编程风格有待改进。:mrgreen:对于polling的算法还不熟，结合你的文章，继续阅读代码。:D
&mirnshi 回复于： 14:08:23
引用：原帖由&雨丝风片&于&&11:41&发表&...&回答问题前，需要仔细看代码了，许久不弄，就是生疏了。我看了看以前调优的一些记录，的确和cluster相关的，可以通过调高nmbcluster参数，提高系统处理网络效率这个参数需要在启动时，设置，一旦内核启动了，就不能更改了。在/boot/loader.rc中设置警告：这个值不能过大，否则系统会因没有足够的内存分配而启动不起来[&本帖最后由&mirnshi&于&&14:10&编辑&]
&mirnshi 回复于： 14:16:17
FreeBSD在网络处理上，我一直认为是非常强的，我曾在志强2.4，内存1G，4.11，接收900MB，CPU还能空余5-9%，但是发包就不行了，只能达到3、400MB。这是为了测试极限值，所有的包都是收到就丢弃。所以能达到极限。
&xfsoul 回复于： 14:34:13
我在PD&820和AMD&Opteron平台，linux网桥透明转发。当包&512时候，双向千兆线速转发，轻松愉快！
&caibird3rd 回复于： 14:42:24
引用：原帖由&xfsoul&于&&14:34&发表我在PD&820和AMD&Opteron平台，linux网桥透明转发。当包&512时候，双向千兆线速转发，轻松愉快！&现在的系统，包括linux和FB大包的性能都不错。我们还是要相信各位大牛地～要显著提高小包性能，不在系统软件结构或者硬件平台上做工作是不太可能地～:m01:
&colddawn 回复于： 15:26:49
引用：原帖由&雨丝风片&于&&09:57&发表不是讨论是否需要使用、当时是否有必要设计cluster。我的意思很简单，系统是否使用mbuf链或者mcluster来存储网络数据都取决于mbuf的尺寸，既然把mbuf尺寸调整到足以存放楼主测试的全部数据，又何来“包在mbuf&...&cluster不光是用来存贮长度大的数据，同时还有引用计数器之类的设计思路，这样mbuf中可以注入和剥离各层的报头，cluster中存放数据，而不同层传递只需要引用到cluster的指针即可，如果纯粹使用mbuf，在各层中传递数据将会引发大量的mbuf中数据位移操作或者是mbuf拷贝，性能受到影响，所以即使mbuf足够大到可以存储整个包的数据，使用cluster还是有必要的。但这里讨论的桥转发都是在二层处理，所以基本很少牵扯我说的这些操作，可能与主题无关。但同时也可能很少牵扯到mbuf本身数据的操作，只是mbuf链表的增删改，所以你加大mbuf大小的思路也基本影响不到性能，这就要到代码里求证了。
&雨丝风片 回复于： 16:17:31
引用：原帖由&colddawn&于&&15:26&发表cluster不光是用来存贮长度大的数据，同时还有引用计数器之类的设计思路，这样mbuf中可以注入和剥离各层的报头，cluster中存放数据，而不同层传递只需要引用到cluster的指针即可，如果纯粹使用mbuf，在各层中&...&你说的有道理！:D我原来是凭直觉，认为相对于mbuf链或者cluster而言，把数据放在一个mbuf中的效率就要好一些，因为“处理”似乎要简单一些，但好像这种流程上的东西确实也简单不了多少。从mbuf中的数据拷贝来讲，cluster确实比mbuf的效率要高得多：
if&(m-&m_flags&&&M_EXT)&{
n-&m_data&=&m-&m_data&+&
n-&m_ext&=&m-&m_
n-&m_flags&|=&M_EXT;
MEXT_ADD_REF(m);
n-&m_ext.ref_cnt&=&m-&m_ext.ref_
bcopy(mtod(m,&caddr_t)+off,&mtod(n,&caddr_t),
&&&&(u_int)n-&m_len);
&www_ftp 回复于： 16:20:36
测试时发现:HZ&burst_max等增大时&kern.polling.burst&会自己变小.导致系统每秒取的包的总数基本不变,造成大量包丢失.然后此时系统负载及cpu占用还都比较低.不知算法哪儿出问题了.
&xfsoul 回复于： 16:25:09
引用：原帖由&www_ftp&于&&16:20&发表测试时发现:HZ&burst_max等增大时&kern.polling.burst&会自己变小.导致系统每秒取的包的总数基本不变,造成大量包丢失.然后此时系统负载及cpu占用还都比较低.不知算法哪儿出问题了.&嗯&的确是这样。kern.polling.burst的确会自动变的非常小。导致性能上不去。不过当kern.polling.burst比较大（比方500），HZ=4000，这个时候按说包速可以比较大，可是性能也不行。非常希望大家能把问题分析清楚。网络性能对一个网络操作系统来说可是非常重要的啊！
&www_ftp 回复于： 16:42:12
引用：原帖由&xfsoul&于&&16:25&发表嗯&的确是这样。kern.polling.burst的确会自动变的非常小。导致性能上不去。不过当kern.polling.burst比较大（比方500），HZ=4000，这个时候按说包速可以比较大，可是性能也不行。非常希望大家能把问题&...&是呀,这个问题的确很重要,要解决这个问题必须有多位牛人共同努力.实际测试中还发现两个问题,把polling升级到最新,也没有任何性能上的提高.6.0&6.1都有个打开polling在极限下假死机的现象,现象是打开polling,收受大量的小量,这时cpu&100%,然后减低小包数量,也自己恢复不过处于假死机状态.6.1RC1就不存在这个问题,只要减小包的数量,自己马上恢复,不存在假死机状态.
&xie_minix 回复于： 17:05:48
www_ftp老弟.请贴出机器的配置情况.谢谢
&zjzf_2 回复于： 20:32:16
freebsd&6.0的&polling&的确没有什么效果&这个我进行了反复的测试82546网卡freebsd4.11&打开polling&&hz=1000&&p42.8&64bytes的报转发率可以到500m以上而换了freebsd6.0&只能到250M&polling&SMP&AMD64&我都测试过&&&非常遗憾无法突破300m&&:)顺便告诉你&我没有用什么netbsd移植过来的if_bridge&&&&&&&&&&&&&&也没有用freebsd原有的的bridge&&根本不是bridge的问题热心的老大&Dennis2&&帮我找了篇文章&New&Networking&Features&in&FreeBSD&6.0文中提到&The&first&go&on&fine-grained&network&locking&inFreeBSD&5&has&been&greatly&enhanced&andrefined&for&excellent&SMP&scalability.&For&singleprocessor&machines&all&performance®ressionsdue&to&locking&overhead&have&been&eleminatedand&FreeBSD&6&reaches&the&same&speed&in&heavyduty&network&streaming&as&the&FreeBSD&4&series.但是实际上freebsd&6并不能带给我们昔日强劲的包转发性能我也开始怀疑是过多的mutex降低了效率&&&&但是为了坚守bsd阵营&我尝试了DragonFly&DragonFly自称是freebsd4.9的延续&&&&DragonFly的包转发性能可以说是强于freebsd6.x的&我在相同的硬件上可以达到300m&但是较freebsd4.11还是相差太远&目前我个人认为&驱动程序是一个&非常重要的因素&&&因为linux也曾出现过新驱动包转发性能下降的问题我还在继续关注并尝试解决这个问题另外提醒大家&类似问题不要总想着高手能给你一个完美的答案谢老师也在这里&好久没见您Dennis2老大&帮我找了些资料其中包括这个http://proj.sunet.se/LSR3-s/&&&netbsd在万兆以太网创下的一个纪录&不过我想小包才能说明问题另外netbsd&曾经有人做过polling方面的工作&希望能给您带来帮助http://thir.org/thir/NetBSD/devicepolling.en.html最后提议下&&多处理器的工作&大家都盯着对称多处理在想&&&我觉得解决包转发这种对问题应该朝着非对称多处理多想想&当然这个难度不小[&本帖最后由&zjzf_2&于&&20:46&编辑&]
&www_ftp 回复于： 21:44:02
引用：原帖由&xie_minix&于&&17:05&发表www_ftp老弟.请贴出机器的配置情况.谢谢&Intel(R)&Pentium(R)&4&CPU&3.00GHzreal&memory&&=&&(1015&MB)avail&memory&=&&(901&MB)Intel82547EI&&CSA
&xfsoul 回复于： 19:23:06
最新测试结果出炉，数据没有经过整理，太忙了，呵呵。测试硬件平台：CPU：&双Opteron&250（运行频率2.4G）内存：DDR400&双通道（ECC关闭）网卡：Intel双口千兆网卡Smartbit千兆口两个Smartwindow&9.0linux&2.6.9(redhat&enterprise&linux&4&update1)包长&&&带宽&&&&&&&&包速(pps)&&字节速率(Mbps)&&&&CPU占用64&&&&&18.3%&&&&&&&259875&&&&&141.37&&&&&&&&&&&&86%128&&&&30.46%&&&&&&250501&&&&&264.54&&&&&&&&&&&&94.5%256&&&&56.45%&&&&&&250016&&&&&524.19&&&&&&&&&&&&96%512&&&&89.93%&&&&&&209732&&&&&865.77&&&&&&&&&&&&80%1024&&&100%&&&&&&&&119274&&&&&980.91&&&&&&&&&&&&40%1500&&&100%&&&&&&&&82020&&&&&&986.86&&&&&&&&&&&&29.5%混包&&&43.97%&&&&&&401.36&&&&&239825&&&&&&&&&&&&93.5%FreeBSD&4.11(polling&enable，HZ=4000)包长&&&带宽&&&&&&&&包速(pps)&&字节速率(Mbps)&&&&CPU占用64&&&&&32.6%&&&&&&&462963&&&&&251.85&&&&&&&&&&&&1%128&&&&48.87%&&&&&&401929&&&&&424.44&&&&&&&&&&&&1%256&&&&66.35%&&&&&&296209&&&&&616.11&&&&&&&&&&&&1%512&&&&84.94%&&&&&&198098&&&&&817.75&&&&&&&&&&&&0%1024&&&100.0%&&&&&&119274&&&&&980.91&&&&&&&&&&&&0%1500&&&100%&&&&&&&&82020&&&&&&986.86&&&&&&&&&&&&0%混包&&&60.26%&&&&&&328831&&&&&549.97&&&&&&&&&&&&0%&&&&&&&&FreeBSD&6.0&(polling&disabled，&if_bridge)包长&&&带宽&&&&&&&&包速(pps)&&字节速率(Mbps)&&&&CPU占用64&&&&&22.98%&&&&&&326371&&&&&177.55&&&&&&&&&&&&93%128&&&&38.48%&&&&&&316456&&&&&334.18&&&&&&&&&&&&97%256&&&&65.88%&&&&&&294118&&&&&611.77&&&&&&&&&&&&87%512&&&&84.54%&&&&&&197161&&&&&813.88&&&&&&&&&&&&32%1024&&&100%&&&&&&&&119274&&&&&980.91&&&&&&&&&&&&22.5%1500&&&100%&&&&&&&&82020&&&&&&986.86&&&&&&&&&&&&17.5%混包&&&57.97%&&&&&&316351&&&&&529.09&&&&&&&&&&&&88%FreeBSD&6.0&(polling&disabled，&BRIDGE)包长&&&带宽&&&&&&&&包速(pps)&&字节速率(Mbps)&&&&CPU占用64&&&&&26.43%&&&&&&375375&&&&&&204.20&&&&&&&&&&&95%128&&&&44.44%&&&&&&365497&&&&&&385.96&&&&&&&&&&&93%256&&&&65.88%&&&&&&294118&&&&&&611.77&&&&&&&&&&&61%512&&&&84.54%&&&&&&197161&&&&&&813.88&&&&&&&&&&&30%1024&&&100%&&&&&&&&119274&&&&&980.91&&&&&&&&&&&&22.8%1500&&&100%&&&&&&&&82020&&&&&&986.86&&&&&&&&&&&&17%&&&&&&&混包&&&59.48%&&&&&&324561&&&&&&542.83&&&&&&&&&&&82%[&本帖最后由&xfsoul&于&&08:58&编辑&]
&xfsoul 回复于： 19:24:15
先测了这么多，其他的明天继续测。FreeBSD&6.0终于翻身了，不开polling性能优于linux。但是开启polling后，性能会飞速下降！！我郁闷。倒是FreeBSD&4.11的polling还可以！
&colddawn 回复于： 07:42:18
lz可以试试把7-CURRENT的em驱动替换掉FB6的测试一下看看，据说这方面对于SMP支持还在改进中，并且可能替换后性能会有比较可观的提升。还有问下就是为什么这个测试结果比你前面贴出来的大包性能有比较大的提升？软硬件环境和某些配置做过改动吗？[&本帖最后由&colddawn&于&&07:45&编辑&]
&xfsoul 回复于： 08:59:07
硬件平台根本就不一样。上次是P4&2.8B，这次是双路Opteron。当然不一样。
&xfsoul 回复于： 08:59:45
引用：原帖由&colddawn&于&&07:42&发表lz可以试试把7-CURRENT的em驱动替换掉FB6的测试一下看看，据说这方面对于SMP支持还在改进中，并且可能替换后性能会有比较可观的提升。还有问下就是为什么这个测试结果比你前面贴出来的大包性能有比较大的提升&...&我这里没有7-CURRENT啊，你能不能发一个给我？
&colddawn 回复于： 09:21:49
我这里也没有，cvs就能拿到，替换现有的src然后编译下内核就可以了。还有cvsweb也能找到http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/#dirlist
&xfsoul 回复于： 10:07:05
引用：原帖由&colddawn&于&&09:21&发表我这里也没有，cvs就能拿到，替换现有的src然后编译下内核就可以了。还有cvsweb也能找到http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/#dirlist&http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/em/里面只有一个makefile。[&本帖最后由&xfsoul&于&&10:15&编辑&]
&xfsoul 回复于： 10:20:44
现在FreeBSD在双路Opteron上，已经到了双向46万pps不丢包（参见第九页测试记录）。不知道有无办法突破记录呵呵。FreeBSD是不是对xeon平台支持不好啊。还有4Xeon平台，每个Xeon都支持超线程。CPU资源很强大啊。
&xfsoul 回复于： 15:07:04
我怎么看过去一段时间，两个网卡各收到多少包呢？我想测试一下没有网桥时候&FreeBSD收包性能。netstat&-w&10&-i&em0看到的结果根本不对！我用smartbit发了大量的包，netstat都没有统计到。
&雨丝风片 回复于： 16:29:43
引用：原帖由&xfsoul&于&&15:07&发表我怎么看过去一段时间，两个网卡各收到多少包呢？我想测试一下没有网桥时候&FreeBSD收包性能。netstat&-w&10&-i&em0看到的结果根本不对！我用smartbit发了大量的包，netstat都没有统计到。&是有网桥的时候不准还是没网桥的时候不准？
&xfsoul 回复于： 17:24:48
引用：原帖由&雨丝风片&于&&16:29&发表是有网桥的时候不准还是没网桥的时候不准？&netstat在FreeBSD&4.11下统计的大约对头，在FreeBSD&6.1上统计的根本不对。我在FreeBSD&4.11下关了POLLING，开了SMP。测试了一下网桥转发性能（无丢包时峰值吞吐率）。发现性能比开polling差不多，硬件还是前述平台：FreeBSD&4.11(polling&disabled，SMP&enable)包长&&&带宽&&&&&&&&包速(pps)&&字节速率(Mbps)&&&&CPU占用64&&&&&32.0%&&&&&&&454545&&&&&247.27&&&&&&&&&&&&41%128&&&&48.10%&&&&&&395570&&&&&417.72&&&&&&&&&&&&46%256&&&&64.97%&&&&&&290023&&&&&603.25&&&&&&&&&&&&27.5%512&&&&84.94%&&&&&&198098&&&&&817.75&&&&&&&&&&&&30%1024&&&100.0%&&&&&&119274&&&&&980.91&&&&&&&&&&&&14%1500&&&100%&&&&&&&&82020&&&&&&986.86&&&&&&&&&&&&11%混包&&&59.17%&&&&&&322888&&&&&540.03&&&&&&&&&&&&41%[color=Red]另外请问一下在FreeBSD下有没有性能不错的pcap工具[/color]
&xie_minix 回复于： 23:39:41
阁下的机器是否是AMD&8111芯片+AMD&8131&PCI-X.如果是这样.他的A边是最大6.4G,B边是3.2G左右每秒在AMD&8131上.在AMD&8111上只是通常的100M卡.
&xfsoul 回复于： 08:50:24
是单独买的Intel的千兆双端口网卡。还有两块Intel光口网卡。
&xie_minix 回复于： 09:25:50
哦,不是的,你dmesg下,贴出来看看,我的意思想看看芯片组.我有几台机器和你的差不多.是SUN&V20Z的.bge的卡在PCI-X槽上.理论速度是.AMD&8131&A&边通道可以达到6G每秒.B边的也能跑到3G(因为B边通道是8位传输,A是16位穿输).所以总线并不成为瓶颈(可参考AMD&8131芯片说明,既文献24637.pdf).[&本帖最后由&xie_minix&于&&09:32&编辑&]
&xfsoul 回复于： 09:39:15
[root@shyfzx&~/em/em-5.1.5]#&dmesg&Copyright&(c)&&The&FreeBSD&Project.Copyright&(c)&,&,&,&,&&&&&&&&&The&Regents&of&the&University&of&California.&All&rights&reserved.FreeBSD&6.1-RELEASE:&Wed&May&31&09:12:54&UTC&2006&&&&[email]root@shyfzx.star-net.cn[/email]:/usr/obj/usr/src/sys/GENERICTimecounter&"i8254"&frequency&1193182&Hz&quality&0CPU:&AMD&Opteron(tm)&Processor&250&(2392.56-MHz&686-class&CPU)&&Origin&=&"AuthenticAMD"&&Id&=&0xf5a&&Stepping&=&10&&Features=0x78bfbff&FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2&&&AMD&Features=0xe0500800&SYSCALL,NX,MMX+,LM,3DNow+,3DNow&real&memory&&=&&(1023&MB)avail&memory&=&&(992&MB)ACPI&APIC&Table:&&PTLTD&&&&&&&&&&APIC&&&FreeBSD/SMP:&Multiprocessor&System&Detected:&2&CPUs&cpu0&(BSP):&APIC&ID:&&0&cpu1&(AP):&APIC&ID:&&1MADT:&Forcing&active-low&polarity&and&level&trigger&for&SCIioapic0&&Version&1.1&&irqs&0-23&on&motherboardioapic1&&Version&1.1&&irqs&24-27&on&motherboardioapic2&&Version&1.1&&irqs&28-31&on&motherboardkbd1&at&kbdmux0acpi0:&&PTLTD&&&&XSDT&&on&motherboardacpi0:&Power&Button&(fixed)unknown:&I/O&range¬&supportedunknown:&I/O&range¬&supportedTimecounter&"ACPI-fast"&frequency&3579545&Hz&quality&1000acpi_timer0:&&24-bit&timer&at&3.579545MHz&&port&0xb&on&acpi0cpu0:&&ACPI&CPU&&on&acpi0cpu1:&&ACPI&CPU&&on&acpi0acpi_button0:&&Power&Button&&on&acpi0pcib0:&&ACPI&Host-PCI&bridge&&port&0xcf8-0xcff,0xf,0xff&iomem&0xd8000-0xdbfff&on&acpi0pci0:&&ACPI&PCI&bus&&on&pcib0pcib1:&&ACPI&PCI-PCI&bridge&&at&device&6.0&on&pci0pci1:&&ACPI&PCI&bus&&on&pcib1ohci0:&&OHCI&(generic)&USB&controller&&mem&0xfcxfc100fff&irq&19&at&device&0.0&on&pci1ohci0:&[GIANT-LOCKED]usb0:&OHCI&version&1.0,&legacy&supportusb0:&SMM&does¬&respond,&resettingusb0:&&OHCI&(generic)&USB&controller&&on&ohci0usb0:&USB&revision&1.0uhub0:&AMD&OHCI&root&hub,&class&9/0,&rev&1.00/1.00,&addr&1uhub0:&3&ports&with&3&removable,&self&poweredohci1:&&OHCI&(generic)&USB&controller&&mem&0xfcxfc101fff&irq&19&at&device&0.1&on&pci1ohci1:&[GIANT-LOCKED]usb1:&OHCI&version&1.0,&legacy&supportusb1:&SMM&does¬&respond,&resettingusb1:&&OHCI&(generic)&USB&controller&&on&ohci1usb1:&USB&revision&1.0uhub1:&AMD&OHCI&root&hub,&class&9/0,&rev&1.00/1.00,&addr&1uhub1:&3&ports&with&3&removable,&self&poweredatapci0:&&SiI&3114&SATA150&controller&&port&0x7,0x7,0xf,0x3,0xf&mem&0xfcxfc1033ff&irq&16&at&device&5.0&on&pci1ata2:&&ATA&channel&0&&on&atapci0ata3:&&ATA&channel&1&&on&atapci0ata4:&&ATA&channel&2&&on&atapci0ata5:&&ATA&channel&3&&on&atapci0pci1:&&display,&VGA&&at&device&7.0&(no&driver&attached)isab0:&&PCI-ISA&bridge&&at&device&7.0&on&pci0isa0:&&ISA&bus&&on&isab0atapci1:&&AMD&8111&UDMA133&controller&&port&0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf&at&device&7.1&on&pci0ata0:&&ATA&channel&0&&on&atapci1ata1:&&ATA&channel&1&&on&atapci1pci0:&&serial&bus,&SMBus&&at&device&7.2&(no&driver&attached)pci0:&&bridge&&at&device&7.3&(no&driver&attached)pcib2:&&ACPI&PCI-PCI&bridge&&at&device&10.0&on&pci0pci2:&&ACPI&PCI&bus&&on&pcib2pci0:&&base&peripheral,&interrupt&controller&&at&device&10.1&(no&driver&attached)pcib3:&&ACPI&PCI-PCI&bridge&&at&device&11.0&on&pci0pci3:&&ACPI&PCI&bus&&on&pcib3em0:&&Intel(R)&PRO/1000&Network&Connection&Version&-&3.2.18&&port&0xf&mem&0xfe0c0000-0xfe0dffff,0xfexfe07ffff&irq&28&at&device&1.0&on&pci3em0:&Ethernet&address:&00:04:23:b3:cb:76em1:&&Intel(R)&PRO/1000&Network&Connection&Version&-&3.2.18&&port&0xf&mem&0xfe0e0000-0xfe0fffff,0xfexfe0bffff&irq&29&at&device&1.1&on&pci3em1:&Ethernet&address:&00:04:23:b3:cb:77bge0:&&Broadcom&BCM5704C&Dual&Gigabit&Ethernet,&ASIC&rev.&0x2003&&mem&0xfexfe01ffff,0xfexfe00ffff&irq&29&at&device&2.0&on&pci3miibus0:&&MII&bus&&on&bge0brgphy0:&&BCM/1000baseTX&PHY&&on&miibus0brgphy0:&&10baseT,&10baseT-FDX,&100baseTX,&100baseTX-FDX,&1000baseTX,&1000baseTX-FDX,&autobge0:&Ethernet&address:&00:11:09:15:1b:cebge1:&&Broadcom&BCM5704C&Dual&Gigabit&Ethernet,&ASIC&rev.&0x2003&&mem&0xfexfe03ffff,0xfexfe02ffff&irq&30&at&device&2.1&on&pci3miibus1:&&MII&bus&&on&bge1brgphy1:&&BCM/1000baseTX&PHY&&on&miibus1brgphy1:&&10baseT,&10baseT-FDX,&100baseTX,&100baseTX-FDX,&1000baseTX,&1000baseTX-FDX,&autobge1:&Ethernet&address:&00:11:09:15:1d:05pci0:&&base&peripheral,&interrupt&controller&&at&device&11.1&(no&driver&attached)atkbdc0:&&Keyboard&controller&(i8042)&&port&0x60,0x64&irq&1&on&acpi0atkbd0:&&AT&Keyboard&&irq&1&on&atkbdc0kbd0&at&atkbd0atkbd0:&[GIANT-LOCKED]ppc0:&&Standard¶llel&printer&port&&port&0x378-0x37f,0x778-0x77f&irq&7&on&acpi0ppc0:&Generic&chipset&(EPP/NIBBLE)&in&COMPATIBLE&modeppbus0:&&Parallel&port&bus&&on&ppc0plip0:&&PLIP&network&interface&&on&ppbus0lpt0:&&Printer&&on&ppbus0lpt0:&Interrupt-driven&portppi0:&&Parallel&I/O&&on&ppbus0pmtimer0&on&isa0orm0:&&ISA&Option&ROMs&&at&iomem&0xcfff,0xcff,0xc9800-0xcafff&on&isa0sc0:&&System&console&&at&flags&0x100&on&isa0sc0:&VGA&&16&virtual&consoles,&flags=0x300&sio0:&configured&irq&4¬&in&bitmap&of&probed&irqs&0sio0:&port&may¬&be&enabledsio0&at&port&0x3f8-0x3ff&irq&4&flags&0x10&on&isa0sio0:&type&8250&or¬&respondingsio1:&configured&irq&3¬&in&bitmap&of&probed&irqs&0sio1:&port&may¬&be&enabledvga0:&&Generic&ISA&VGA&&at&port&0x3c0-0x3df&iomem&0xa0000-0xbffff&on&isa0Timecounters&tick&every&1.000&msecad0:&78167MB&&Maxtor&6L080L0&BAJ41G20&&at&ata0-master&UDMA133SMP:&AP&CPU&Launched!Trying&to&mount&root&from&ufs:/dev/ad0s2aWARNING:&/&was¬&properly&dismounted
&xfsoul 回复于： 09:47:58
引用：原帖由&xie_minix&于&&09:25&发表哦,不是的,你dmesg下,贴出来看看,我的意思想看看芯片组.我有几台机器和你的差不多.是SUN&V20Z的.bge的卡在PCI-X槽上.理论速度是.AMD&8131&A&边通道可以达到6G每秒.B边的也能跑到3G(因为B边通道是8位传输,A是&...&你说的A边&B边是什么意思？
&xie_minix 回复于： 14:47:25
呵呵,简单画个图给你看看.&&&&&&&&&&&&&&&&|-------通道----------|HOST&----|&&&A&边&&&&&&&&&&&B&边|&------&其他下游设备&&&&&&&&&&|----------------------|&&&&16位带宽&&|&&&&&&&&&&&&&&&&&&|&&8位带宽&&&&&&&&&&&&&|&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&PCI-X桥A&&&&&&&PCI-X桥B&&&&&&&&&&&&&&|&&&&&|&&&&&|&&&&&&&|&&&&|&&&&&|&&&&&&&&&&一些PCI槽....所以在A边PCI槽传送数据到CPU中比B边快一倍,但无所谓了,G兆的卡跑不到那么快.10G的卡又跑不起来.[&本帖最后由&xie_minix&于&&14:51&编辑&]
&雨丝风片 回复于： 16:38:07
引用：原帖由&xfsoul&于&&15:07&发表我怎么看过去一段时间，两个网卡各收到多少包呢？我想测试一下没有网桥时候&FreeBSD收包性能。netstat&-w&10&-i&em0看到的结果根本不对！我用smartbit发了大量的包，netstat都没有统计到。&有一个疑问请教一下。看到xfsoul提到netstat对收包数目的统计不对，就去初步看了一下netstat的源码。以入包为例，netstat在每次时间间隔到达的时候，打印的是接口结构ifnet中的if_ipackets字段的变化：&&&&....
show_stat("lu",&10,&ifnet.if_ipackets&-&ip-&ift_ip,&1);&&&&....
ip-&ift_ip&=&ifnet.if_&&&&....但接口中的这个字段对于桥转发流程来说，仅在if_bridge.c中的bridge_forward()函数和bridge_input()函数中有增加的操作，但在bridge.c中却看不到对这个字段的赋值。结论似乎是netstat只对if_bridge处理的包进行计数，而不对bridge处理的包进行计数。我对这个流程不熟，不知上述分析是否有误？
&xie_minix 回复于： 17:08:36
在驱动程序中会对他进行处理,如:vr_rxeof中ifp-&if_ipackets++;你图中的代码部分的IFNET应该是单个桥自己的.网卡进入的if_ipackets和桥进入的if_ipackets应该是不一样的.[&本帖最后由&xie_minix&于&&17:22&编辑&]
&雨丝风片 回复于： 17:35:18
引用：原帖由&xie_minix&于&&17:08&发表在驱动程序中会对他进行处理,如:vr_rxeof中ifp-&if_ipackets++;我也曾怀疑过这个方向，但由于代码不熟，就只能做点简单的“考证”了：:D毕竟if_bridge.c中对其加1，bridge.c中没有对其加1。如果if_xxxx.c和桥代码是前后关系，就能解释bridge.c的情况，但不能解释if_bridge.c的情况。如果if_xxxx.c和桥代码是二选一的关系，就能解释if_bridge.c的情况，但不能解释bridge.c的情况。除非if_bridge.c和bridge.c并不是简单的替换关系，它们和驱动的处理接口有所不同？查看了一下桥代码和以太网代码的接口，是在if_ethersubr.c文件的ether_input()函数中： /* &*&Tap&the&packet&off&here&for&a&bridge.&&bridge_input() &*&will&return&NULL&if&it&has&consumed&the&packet,&otherwise &*&it&gets&processed&as&normal.&&Note&that&bridge_input() &*&will&always&return&the&original&packet&if&we&need&to &*&process&it&locally. &*/ if&(ifp-&if_bridge)&{
BRIDGE_INPUT(ifp,&m);
if&(m&==&NULL)
} /*&Check&for&bridging&mode&*/ if&(BDG_ACTIVE(ifp)&)
if&((m&=&bridge_in_ptr(ifp,&m))&==&NULL)
其中，后面的bridge_in_ptr()调用就是原来的bridge的处理，而前面的BRIDGE_INPUT()调用则是（号）新加的if_bridge的处理。从这儿看来，bridge和if_bridge的处理代码从以太网处理流程中“截获”的地点是一样的。因此似乎没有道理if_bridge对if_ipackets的加一操作在其自身代码内部进行，而bridge对if_ipackets的加1操作则放到其它地方或是根本就没有进行呢？[&本帖最后由&雨丝风片&于&&17:37&编辑&]
&雨丝风片 回复于： 17:36:55
引用：原帖由&xie_minix&于&&17:08&发表你图中的代码部分的IFNET应该是单个桥自己的.网卡进入的if_ipackets和桥进入的if_ipackets应该是不一样的.&这个我也心存疑虑，就怕两个if_ipackets不是同一个东西，但我暂时还搞不清楚，所以就先拿出来让你指点一下了！:mrgreen:
&caibird3rd 回复于： 11:32:18
感觉最新的测试结果怪怪的linux的小包性能差这么多？FB&4.11的CPU使用率也太低了吧，感觉应该有个百分之几的，1％实在低linux下也有polling的，这里给的结果是什么配置下的？
&ktrudger 回复于： 10:05:50
linux下的NAPI很烂的，开了以后性能会下降。我在linuxforum上发过帖子。
&ktrudger 回复于： 10:09:33
引用：原帖由&caibird3rd&于&&11:32&发表感觉最新的测试结果怪怪的linux的小包性能差这么多？FB&4.11的CPU使用率也太低了吧，感觉应该有个百分之几的，1％实在低linux下也有polling的，这里给的结果是什么配置下的？&我只是如实的记录实际测试结果，如果谁的测试成绩和我的结果差异很大，不妨提出来对照一下。CPU占用率都是通过top读出来的稳定值。
&colddawn 回复于： 13:17:51
据说FB4.X版本计算LA值有些问题，有实际CPU已经满载，但根本不计入LA的情况存在。
&antijp 回复于： 21:50:49
对了，楼主试试看把kern.polling.idle_poll置1看看，另外同时最好不要运行其他的应用
&gwzph 回复于： 11:32:16
FB6.2的polling问题有没有修正？尤其是SMP+POLLING现在看到各种说法都有，简直没法选型了例如我的情况，功能简单，静态路由+NAT+简单流控，但要求高性能，CLIENTS数量，到底是选择哪种组合好？FB4.X+polling还是FB6.X+polling，还是FB6.X+SMP，还是FB6.X+SMP+polling别扯到硬墙那边去，就用BSD！
&rhinux 回复于： 15:53:59
引用：原帖由&antijp&于&&21:50&发表&[url=http://bbs2.chinaunix.net/redirect.php?goto=findpost&pid=5365669&ptid=760331]对了，楼主试试看把kern.polling.idle_poll置1看看，另外同时最好不要运行其他的应用&这个参数在&freebsd5.5的时候有bug但我现咱6.2R&kern.polling.idle_poll置1&用top&-S&看idlepoll&cpu占有是99%&,如果我其他程序同样跑的时候idlepoll同样是&99%
& 相关主题：
