亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

<form id="5llby"></form>

<dfn id="5llby"></dfn>

Chinaunix

標(biāo)題: 精通polling參數(shù)調(diào)優(yōu)的進(jìn)來(lái)幫幫忙吧 [打印本頁(yè)]

作者: xfsoul 時(shí)間: 2006-05-23 18:30
標(biāo)題: 精通polling參數(shù)調(diào)優(yōu)的進(jìn)來(lái)幫幫忙吧
我測(cè)試FreeBSD無(wú)丟包網(wǎng)絡(luò)轉(zhuǎn)發(fā)性能。
我現(xiàn)在測(cè)試用的硬件配置：
CPU：奔四2.8G
內(nèi)存：1G DDR333雙通道
網(wǎng)卡：雙Intel千兆網(wǎng)卡用來(lái)做網(wǎng)橋，還有一個(gè)百兆的用來(lái)訪問(wèn)
還有千兆網(wǎng)線和smartbit千兆口

我開了polling以后，無(wú)論怎么設(shè)置,轉(zhuǎn)發(fā)性能都上不去，64字節(jié)下雙向到達(dá)18萬(wàn)pps以后，就開始丟包，但CPU占用率一直不到1%

我嘗試過(guò)設(shè)置內(nèi)核配置文件的值HZ=1000改為2000也不行，我還設(shè)置過(guò)如下參數(shù)，都沒(méi)有能很好的提升性能：
kern.polling.user_frac
kern.polling.each_burst
kern.polling.burst_max

[ 本帖最后由 xfsoul 于 2006-5-23 18:32 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-23 18:45
而且我在網(wǎng)上看到很多人碰到和我一樣的問(wèn)題：
在FreeBSD6系列中開了polling性能會(huì)很差：
http://www.monkey.org/freebsd/ar ... 00501/msg00060.html
http://www.freebsdchina.org/foru ... 70d4b88fede6fedee03

我這里開了polling性能比linux差很多。

[ 本帖最后由 xfsoul 于 2006-5-23 18:51 編輯 ]

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-23 18:55
這封郵件你看了沒(méi)有？

http://unix.derkeiler.com/Mailin ... 06-03/msg00142.html

作者: xfsoul 時(shí)間: 2006-05-23 19:05
沒(méi)有看到。
現(xiàn)在怎么辦呢。
在第一個(gè)硬件平臺(tái)上測(cè)試。FreeBSD網(wǎng)絡(luò)轉(zhuǎn)發(fā)性能貌似不如linux

作者: xfsoul 時(shí)間: 2006-05-23 19:08
我重新編譯內(nèi)核，徹底去掉polling看看，性能能否比得上linux。

作者: xie_minix 時(shí)間: 2006-05-23 23:24
1.2.1  全局變量
從第106行開始,都是POLLING相關(guān)的全局變量.首先是建立一SYSCTL樹的節(jié)點(diǎn).下圖中的SYSCTL_NODE宏代表在父節(jié)點(diǎn)_kern下建立一個(gè)_kern_polling節(jié)點(diǎn).
SYSCTL_NODE(_kern, OID_AUTO, polling, CTLFLAG_RW, 0, "Device polling parameters");
      下圖中的變量全部可用sysctl來(lái)查看,大部分都可以調(diào)整設(shè)置.這些全局變量都是使用宏SYSCTL_UINT把他們加入到_kern_polling節(jié)點(diǎn)下,成為該節(jié)點(diǎn)的葉子.之所以這樣,是因?yàn)榭梢酝ㄟ^(guò)用戶區(qū)來(lái)調(diào)整這些參數(shù).

-----------------------------------------------------------------------------------------------------
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_trap;
static u_int32_t user_frac = 50;
static u_int32_t reg_frac = 20 ;static u_int32_t short_ticks;
static u_int32_t lost_polls;
static u_int32_t pending_polls;
static int residual_burst = 0;
static u_int32_t poll_handlers;
static int polling = 0;
static u_int32_t phase;

static u_int32_t suspect;
static u_int32_t stalled;
static u_int32_t idlepoll_sleeping;                                                       ------ kern_poll.c
----------------------------圖1-2-2 ----------------------------
在圖1-2-2中.這些變量按功能分可分為  3  大類.
A. 開關(guān)型:
polling: 初始為0,即默認(rèn)為不打開輪詢功能.要打開輪詢功能,必須用:
#sysctl kern.polling=1
poll_in_idle_loop:該參數(shù)用于poll_idle函數(shù),用來(lái)確定是否進(jìn)入一低優(yōu)先權(quán)的循環(huán)輪詢中.即CPU空閑時(shí)是否來(lái)執(zhí)行輪詢.

poll_in_trap:此參數(shù)不但是在陷入時(shí)是否執(zhí)行輪詢的開關(guān),而且其值也是在陷入(trap)時(shí)執(zhí)行多少次輪詢
B. 算法參數(shù)
poll_each_burst:一個(gè)基本的輪詢次數(shù),很多其他變量都來(lái)和他進(jìn)行比較(主要是空閑時(shí)執(zhí)行輪詢或陷入時(shí)執(zhí)行輪詢).該值系統(tǒng)默認(rèn)是5,

poll_burst:一個(gè)動(dòng)態(tài)的輪詢次數(shù),主要用于根據(jù)核心(輪詢)占用的時(shí)間片調(diào)整輪詢次數(shù),在核心(輪詢)時(shí)間片小于預(yù)定的時(shí)間片時(shí),該值加1,當(dāng)核心(輪詢)時(shí)間片過(guò)長(zhǎng),導(dǎo)致丟失一個(gè)或更多的時(shí)鐘嘀嗒時(shí),該值將減去該值的8分之1.這種算法是FreeBSD中輪詢技術(shù)的主要算法.當(dāng)然有一定的局限性.當(dāng)網(wǎng)絡(luò)分組快速增加時(shí),此算法只是加1來(lái)增加次數(shù)再來(lái)調(diào)用軟件中斷,從而形成軟中斷暴增的做法并不好.而且在占用時(shí)間片過(guò)長(zhǎng)時(shí)的減8分之1的做法也缺少理論依據(jù).

poll_burst_max:輪訓(xùn)的最大值,該值是用來(lái)限制poll_burst在累加過(guò)程中的最大量.當(dāng)然該值可以調(diào)整.他的調(diào)整范圍在后面講的兩個(gè)宏之內(nèi).

user_frac:用戶區(qū)占用的CPU時(shí)間片的百分比.該值用來(lái)確定核心(輪詢)所占時(shí)間片是否有剩余,如果有的話就調(diào)整動(dòng)態(tài)值poll_burst,使其加1.

residual_burst:在正常的輪詢次數(shù)中,都是以poll_each_burst為標(biāo)準(zhǔn)的,而當(dāng)動(dòng)態(tài)的poll_burst>poll_each_burst時(shí)候,就會(huì)產(chǎn)生剩余沒(méi)輪詢的次數(shù),該次數(shù)就是residual_burst,當(dāng)然其結(jié)果就是繼續(xù)輪詢完residual_burst.

idlepoll_sleeping:該值的使用前提是poll_in_idle_loop變量開關(guān)已經(jīng)打開,即在CPU空閑時(shí)支持輪詢.系統(tǒng)置該值為0,可以直接進(jìn)入到CPU空閑時(shí)的輪詢代碼中;如果poll_in_idle_loop變量開關(guān)還沒(méi)開放,系統(tǒng)會(huì)給該值置1,也就是說(shuō).該值其實(shí)是一個(gè)CPU空閑時(shí)是否進(jìn)入輪詢代碼的狀態(tài),

reg_frac:在整個(gè)循環(huán)代碼執(zhí)行了該值的次數(shù)之后,就進(jìn)行檢查網(wǎng)卡的狀態(tài)寄存器.看看網(wǎng)卡是否有什么問(wèn)題.

pending_polls:在進(jìn)入輪詢前(我們有個(gè)時(shí)鐘嘀嗒鉤子函數(shù)),此參數(shù)加1,再輪詢后會(huì)對(duì)其減1,再次進(jìn)入時(shí)鐘嘀嗒后半部分會(huì)判斷是否平衡,如果由于輪詢時(shí)間過(guò)長(zhǎng),此次嘀嗒便會(huì)錯(cuò)過(guò).
C. 調(diào)試與參考
short_ticks:每次時(shí)鐘嘀嗒鉤子函數(shù)所花的時(shí)間如果小于5毫秒.那這種間隔時(shí)間太短了.這是以HZ=100來(lái)計(jì)算的.源代碼作者認(rèn)為.在100M卡時(shí),HZ數(shù)調(diào)整到1000比較合適,那么我們的時(shí)鐘嘀嗒鉤子函數(shù)所花時(shí)間在小于0.5毫秒是合適的.
lost_polls: 由于pending_polls的不平衡.記錄一次嘀嗒時(shí)間錯(cuò)過(guò),該值會(huì)不停的累加,給系統(tǒng)管理員提示可以調(diào)整poll_burst_max值小一些.或根據(jù)情況把user_frac(用戶占用CPU時(shí)間片的百分比)的值調(diào)的更小些.
poll_handlers:有多少個(gè)網(wǎng)絡(luò)設(shè)備支持并注冊(cè)了輪詢.
phase:指示輪詢進(jìn)行到了哪個(gè)階段.輪詢代碼共分為6個(gè)階段.
0階段代表是初始階段或上次輪詢的結(jié)束.
1階段時(shí)鐘嘀嗒鉤子函數(shù)在設(shè)置網(wǎng)絡(luò)軟中斷(輪詢中斷)前
2階段時(shí)鐘嘀嗒鉤子函數(shù)在設(shè)置網(wǎng)絡(luò)軟中斷(輪詢中斷)后.
3階段是進(jìn)入軟中斷netisr_poll前.
4階段是從軟中斷netisr_poll中出來(lái).
5階段是進(jìn)入軟中斷netisr_pollmore前
6階段是從軟中斷netisr_pollmore中出來(lái).
suspect:由于最后的軟中斷netisr_pollmore在處理時(shí)會(huì)再完成時(shí)把階段標(biāo)志phase置為0(即一次POLLING的完成,),或出現(xiàn)其他未完成情況時(shí)進(jìn)入階段5和6.那么就是說(shuō).我們的時(shí)鐘嘀嗒鉤子在最初時(shí)小于2階段的話,一定是在0階段.如果出現(xiàn)1或2階段的話就意味著時(shí)鐘硬件中斷發(fā)生了嵌套.此值在出現(xiàn)這種問(wèn)題時(shí)進(jìn)行記錄.

stalled:由于pending_polls太大(大于100),也就是說(shuō)由于每次輪詢時(shí)間過(guò)長(zhǎng),以至于輪詢丟失了太多嘀嗒,當(dāng)?shù)竭_(dá)100次時(shí),該值加1.(源代碼的作者認(rèn)為不會(huì)發(fā)生此類事情,除了在網(wǎng)卡激活時(shí))

以上是一些參數(shù)說(shuō)明,你可以參照下.(不過(guò)是基于5.3的)
另外,請(qǐng)開空閑HOOK.

作者: xie_minix 時(shí)間: 2006-05-23 23:51
我想知道調(diào)度器的情況.以下是對(duì)/sys/kern/kern_poll.c中在第106行左右的
SYSCTL_NODE(_kern, OID_AUTO, polling, CTLFLAG_RW, 0,
"Device polling parameters");
的后面加入以下:(拷貝粘帖就可以了)
SYSCTL_NODE(_kern_polling, OID_AUTO, dbg, CTLFLAG_RW, 0,
"Device polling node kernel debug");

static uint32_t poll_coun;
SYSCTL_UINT(_kern_polling_dbg, OID_AUTO, poll_coun, CTLFLAG_RD, &poll_coun,0,"netisr_poll and netisr_pollmore count");

static uint32_t pollmore_coun;
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_start;
static uint32_t poll_suspect;
SYSCTL_UINT(_kern_polling_dbg, OID_AUTO, poll_suspect, CTLFLAG_RD, &poll_suspect,0,"poll_suspect count");
static uint32_t poll_invoke;
SYSCTL_UINT(_kern_polling_dbg, OID_AUTO, poll_invoke, CTLFLAG_RD, &poll_invoke,0,"poll_invoke");
static int32_t net_load;
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()函數(shù)中的第6,7行左右if (residual_burst > 0) {語(yǔ)句后
加入:
pollmore_coun++;
if (pollmore_coun>0xfffffffe)
pollmore_coun=0;
到netisr_poll()函數(shù)中第一行的大括號(hào)后面加上:
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;
其他的你還暫時(shí)用不上.
重新編譯核心.
重啟動(dòng)開POLLING后.執(zhí)行:
sysctl kern.polling.
大概每秒執(zhí)行下看看,把數(shù)據(jù)發(fā)上來(lái).

[ 本帖最后由 xie_minix 于 2006-5-23 23:58 編輯 ]

作者: xie_minix 時(shí)間: 2006-05-24 00:08
目前本人正在做POLLING的NetBSD移植.
對(duì)于POLLING的效率問(wèn)題聽過(guò)很多網(wǎng)友
反映,我沒(méi)有條件測(cè)試,移植的目的主要
是想解決SMP上效率問(wèn)題,還有參數(shù)的動(dòng)態(tài)
調(diào)整,希望大家能幫忙一起解決.NetBSD的
POLLING原代碼我爭(zhēng)取在這幾天發(fā)到這.關(guān)于
POLLING的原代碼詳解也將快發(fā)到CNFUG的
期刊上(整整寫了一年了,效率和沒(méi)調(diào)優(yōu)的
POLLING一樣).到時(shí)希望大家指正.

[ 本帖最后由 xie_minix 于 2006-5-24 00:10 編輯 ]

作者: bz169 時(shí)間: 2006-05-24 06:31
在FBSD下打開Polling的效果并不明顯
尤其是橋+polling

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-24 08:37
多謝xfsoul的測(cè)試和xie_minix的分析！我找到了一篇含有polling性能測(cè)試的文章，并把FreeBSD的net、performance和hackers郵件列表上從2003年到現(xiàn)在的關(guān)于polling的討論話題整理了一下，希望大家能夠一起把這個(gè)問(wèn)題弄明白。^_^

Improving Passive Packet Capture: Beyond Device Polling
http://luca.ntop.org/Ring.pdf

FreeBSD-net

if_bridge + polling get lower througphts
http://unix.derkeiler.com/Mailin ... 06-03/msg00142.html

Polling for ath driver
http://unix.derkeiler.com/Mailin ... 06-02/msg00054.html

dummynet, em driver, device polling issues :-((
http://unix.derkeiler.com/Mailin ... t/2005-10/0019.html

[REVIEW/TEST] polling(4) changes
http://unix.derkeiler.com/Mailin ... t/2005-09/0259.html

About guideline of parameters tuning while in polling mode.
http://unix.derkeiler.com/Mailin ... t/2005-09/0147.html

polling in 4.11 vs 5.4
http://unix.derkeiler.com/Mailin ... t/2005-08/0183.html

polling and twa coexistence problems under 5.4-PRE
http://unix.derkeiler.com/Mailin ... t/2005-03/0217.html

Re: Giant-free polling [PATCH]
http://unix.derkeiler.com/Mailin ... t/2005-03/0011.html

xl(4) & polling
http://unix.derkeiler.com/Mailin ... t/2005-02/0090.html

freebsd router project. Problems with polling?
http://unix.derkeiler.com/Mailin ... t/2005-01/0259.html

polling(4) rocks!
http://unix.derkeiler.com/Mailin ... t/2004-11/0144.html

sf(4) device polling
http://unix.derkeiler.com/Mailin ... t/2004-11/0067.html

device polling takes more CPU hits??
http://unix.derkeiler.com/Mailin ... t/2004-07/0158.html

[PATCH] vr(4) locking (and DEVICE_POLLING)
http://unix.derkeiler.com/Mailin ... t/2004-07/0049.html

[PATCH] rl(4) locking and DEVICE_POLLING
http://unix.derkeiler.com/Mailin ... t/2004-07/0048.html

Per-interface polling(4) status
http://unix.derkeiler.com/Mailin ... t/2004-04/0104.html

polling(4) and rl(4)
http://unix.derkeiler.com/Mailin ... t/2004-04/0095.html

Re: Testers wanted: polling(4) support for vr(4)
http://unix.derkeiler.com/Mailin ... t/2004-04/0094.html

Device polling, kern.polling.burst_max and gig-e
http://unix.derkeiler.com/Mailin ... t/2004-01/0380.html

DEVICE_POLLING with SMP
http://unix.derkeiler.com/Mailin ... t/2004-01/0349.html

Paper on device polling and packet capture performance
http://unix.derkeiler.com/Mailin ... t/2004-01/0070.html

Re: Polling CPU usage
http://unix.derkeiler.com/Mailin ... t/2004-01/0027.html

Polling CPU usage
http://unix.derkeiler.com/Mailin ... t/2003-12/0139.html

DEVICE_POLLING together with link0 interrupt offloading?
http://unix.derkeiler.com/Mailin ... t/2003-09/0156.html

Device polling support for em and bge
http://unix.derkeiler.com/Mailin ... t/2003-08/0238.html

FreeBSD-performance

Re: [fbsd] Re: Device polling heavy traffic
http://unix.derkeiler.com/Mailin ... 06-01/msg00006.html

Device polling heavy traffic
http://unix.derkeiler.com/Mailin ... 05-12/msg00069.html

polling in 4.11 vs 5.4
http://unix.derkeiler.com/Mailin ... e/2005-08/0047.html

freebsd router project. Problems with polling?
http://unix.derkeiler.com/Mailin ... e/2005-01/0061.html

FreeBSD-hackers

em0, polling performance, P4 2.8ghz FSB 800mhz
http://unix.derkeiler.com/Mailin ... s/2004-02/0389.html

Device polling, with SMP?
http://unix.derkeiler.com/Mailin ... s/2003-11/0259.html

[ 本帖最后由雨絲風(fēng)片于 2006-5-24 09:24 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-24 09:08
謝謝樓上幾位達(dá)人熱心相助，尤其是版主兄，真是非常敬業(yè)。我們還有幾個(gè)硬件平臺(tái)沒(méi)有測(cè)試。在現(xiàn)有的平臺(tái)上，我先更新驅(qū)動(dòng)程序測(cè)試，更換4.11版本FreeBSD進(jìn)行測(cè)試，同時(shí)再查閱polling的相關(guān)資料。希望各位能繼續(xù)關(guān)注和幫助我。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-24 09:23

原帖由 xfsoul 于 2006-5-24 09:08 發(fā)表
謝謝樓上幾位達(dá)人熱心相助，尤其是版主兄，真是非常敬業(yè)。我們還有幾個(gè)硬件平臺(tái)沒(méi)有測(cè)試。在現(xiàn)有的平臺(tái)上，我先更新驅(qū)動(dòng)程序測(cè)試，更換4.11版本FreeBSD進(jìn)行測(cè)試，同時(shí)再查閱polling的相關(guān)資料。希望各位能繼續(xù)關(guān)注 ...

我原來(lái)沒(méi)有研究過(guò)這個(gè)題目，也是從xie_minix的文章中才了解了大概，所以目前只能幫你做點(diǎn)打雜的工作。

關(guān)鍵還是要靠你的辛苦測(cè)試、xie_minix的理論分析、還有大家的討論。希望通過(guò)大家的努力，能夠把這里面的問(wèn)題分析清楚。

作者: xfsoul 時(shí)間: 2006-05-24 09:54
透露一下，同一臺(tái)工控機(jī)，在linux 2.6.9內(nèi)核下網(wǎng)橋轉(zhuǎn)發(fā)不丟包測(cè)試數(shù)據(jù)如下（雙向各是這么多，后面為CPU占用率）：
64字節(jié)：17.8萬(wàn)pps/100% 128字節(jié)：12.8萬(wàn)pp/94% 256字節(jié):7.7萬(wàn)pps/62% 1518：3萬(wàn)pps/46%。

在FreeBSD下，如果不開polling（編譯內(nèi)核時(shí)沒(méi)有加入polling選項(xiàng)），性能就比linux差：

作者: colddawn 時(shí)間: 2006-05-24 10:15
到現(xiàn)在沒(méi)看明白lz的環(huán)境，既然是做網(wǎng)橋，怎么又測(cè)試的是轉(zhuǎn)發(fā)性能？難道是詞語(yǔ)的意思我沒(méi)理解？到底是純橋接性能的測(cè)試還是牽扯到了三層轉(zhuǎn)發(fā)？如果是后者，估計(jì)要提高性能不太容易，前者的話最好說(shuō)明下你用的哪個(gè)網(wǎng)橋，F(xiàn)B5.3以后有bridge和if_bridge兩種，后者是新近從netbsd引進(jìn)的，性能貌似還不是很穩(wěn)定，前者的代碼已經(jīng)最少有3年沒(méi)更新了，不過(guò)性能還是不錯(cuò)的。另外就是是否加載了包過(guò)濾機(jī)制等，內(nèi)核配置文件等。最好詳細(xì)說(shuō)下，有時(shí)一些小地方很容易對(duì)性能產(chǎn)生比較大的影響。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-24 10:23

原帖由 colddawn 于 2006-5-24 10:15 發(fā)表
到現(xiàn)在沒(méi)看明白lz的環(huán)境，既然是做網(wǎng)橋，怎么又測(cè)試的是轉(zhuǎn)發(fā)性能？難道是詞語(yǔ)的意思我沒(méi)理解？到底是純橋接性能的測(cè)試還是牽扯到了三層轉(zhuǎn)發(fā)？如果是后者，估計(jì)要提高性能不太容易，前者的話最好說(shuō)明下你用的哪個(gè)網(wǎng) ...

嗯，樓主不妨把自己的試驗(yàn)環(huán)境和配置情況做個(gè)比較詳細(xì)的說(shuō)明，有圖更好！

作者: xfsoul 時(shí)間: 2006-05-24 10:38
網(wǎng)橋就是工作在二層的啊。
if_bridge不就是用來(lái)透明轉(zhuǎn)發(fā)的么？
當(dāng)然測(cè)試雙向轉(zhuǎn)發(fā)性能了。

作者: colddawn 時(shí)間: 2006-05-24 11:10
哦，說(shuō)透明轉(zhuǎn)發(fā)就能理解是二層轉(zhuǎn)發(fā)了，否則我會(huì)默認(rèn)你所謂轉(zhuǎn)發(fā)為三層ip轉(zhuǎn)發(fā)的，這里很容易誤解的。
如果是if_bridge，那從6.0-6.1甚至幾個(gè)patch之間似乎都有不小變動(dòng)的，并且就我個(gè)人使用來(lái)看性能目前遠(yuǎn)不如bridge，你可以先用bridge試試看。

作者: xfsoul 時(shí)間: 2006-05-24 11:29
樓上的兄弟，if_bridge和bridge有什么差別？？

我是安裝如下方法加網(wǎng)橋功能的：
在內(nèi)核配置文件中加入如下三項(xiàng)重新編譯內(nèi)核：
options BRIDGE
options DEVICE_POLLING
options HZ=1000

作者: xfsoul 時(shí)間: 2006-05-24 11:30
怎么使用bridge呢？

作者: LnBSD 時(shí)間: 2006-05-24 11:36

原帖由 xfsoul 于 2006-5-24 11:30 發(fā)表
怎么使用bridge呢？

你現(xiàn)在用的就是bridge
千兆網(wǎng)卡可以調(diào)大一點(diǎn)
options HZ=4000－－6000
等待你的測(cè)試結(jié)果

[ 本帖最后由 LnBSD 于 2006-5-24 11:38 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-24 11:47
我現(xiàn)在用bridge性能也這么差。
看來(lái)我換if_bridge看看能不能好點(diǎn)。

作者: xfsoul 時(shí)間: 2006-05-24 11:49

原帖由 LnBSD 于 2006-5-24 11:36 發(fā)表

你現(xiàn)在用的就是bridge
千兆網(wǎng)卡可以調(diào)大一點(diǎn)
options HZ=4000－－6000
等待你的測(cè)試結(jié)果

這個(gè)數(shù)字我嘗試過(guò)600、1500、2000、8000、10000，結(jié)果性能都沒(méi)有是1000的時(shí)候好。

作者: xfsoul 時(shí)間: 2006-05-24 13:13
我換成if_bridge以后，發(fā)現(xiàn)性能果然更差了。

作者: LnBSD 時(shí)間: 2006-05-24 13:15

原帖由 xfsoul 于 2006-5-24 13:13 發(fā)表
我換成if_bridge以后，發(fā)現(xiàn)性能果然更差了。

tryfb4.11

作者: xfsoul 時(shí)間: 2006-05-24 14:27
呆會(huì)我將我測(cè)試到的最好的結(jié)果發(fā)上來(lái)。
options SCHED_ULE
我打開了這一項(xiàng)，為什么編譯內(nèi)核就會(huì)出錯(cuò)？
提示kern_switch.c中有宏沒(méi)有定義。

作者: colddawn 時(shí)間: 2006-05-24 15:04
SCHED_ULE 和SCHED_4BSD不能同時(shí)存在，你是不是忘記注釋掉另外一個(gè)了？

另外在測(cè)試的時(shí)候記錄幾次這幾個(gè)命令的輸出結(jié)果：
sysctl -a|grep polling
sysctl -a|grep bridge

[ 本帖最后由 colddawn 于 2006-5-24 15:05 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-24 18:49
硬件平臺(tái)：
Intel P4 2.8B 533外頻
網(wǎng)卡  雙Intel千兆PCI-X網(wǎng)卡工作在64bit 100MHz，組成bridge
雙千兆網(wǎng)線
Smartbit千兆口兩個(gè)

軟件平臺(tái)：
Smartwindow 9.0
Redhat Enterprise Linux 4U1
FreeBSD 6.1

包長(zhǎng)包含了以太網(wǎng)楨頭部和尾部
帶寬指帶寬利用率，利用了千兆的百分之幾.
包速率是pps，每秒發(fā)送的數(shù)據(jù)包的速度。
用smartbit雙向以相同的速率發(fā)包，統(tǒng)計(jì)的是沒(méi)有丟包時(shí)的峰值性能，包速率和帶寬的記錄值
是單向的值。所以總速率應(yīng)該在此基礎(chǔ)上乘以二。

FreeBSD6.1系統(tǒng)開了polling，下面的測(cè)試記錄是在多次嘗試調(diào)整polling參數(shù)得出的最佳結(jié)果。

包長(zhǎng) linux(帶寬/包速率/CPU使用率)       FreeBSD 6.1
64       12%    178571  99.6%             12.88%  183016  50%
128    15.2% 128468  96.4%             15.28%  125755  0.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 于 2006-5-24 19:03 編輯 ]

作者: xie_minix 時(shí)間: 2006-05-25 02:47
測(cè)試的數(shù)據(jù)非常有意思,大家看到?jīng)]有,在包大于256字節(jié)的時(shí)候,FB就不行了,估計(jì)和MBUF有關(guān).
大家知道,FB的MBUF大小是256字節(jié).如果包大于256字節(jié),m_devget函數(shù)執(zhí)行起來(lái)就麻煩多了.
xfsoul你可以把
#define MSIZE 256 /* size of an mbuf */
改成
#define MSIZE PAGE_SIZE /* size of an mbuf */
如果情況可以,再調(diào)到2048,1024,512進(jìn)行測(cè)試

作者: xfsoul 時(shí)間: 2006-05-25 08:41
樓上的大哥，您太強(qiáng)了！
不過(guò)有三個(gè)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 時(shí)間: 2006-05-25 08:44
我覺得是不是polling太吃內(nèi)存了？
所以CPU利用率很低，性能也不行，因?yàn)閮?nèi)存不夠快了？
把MSIZE改那么大，有負(fù)面影響嗎？我改為2048就可以了吧？
而且把MSIZE改大了，小包性能有無(wú)下降，還要進(jìn)行測(cè)試。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-25 08:53

原帖由 xfsoul 于 2006-5-25 08:41 發(fā)表
樓上的大哥，您太強(qiáng)了！
不過(guò)有三個(gè)MSIZE的定義，而且值還不一樣，到底要怎么改呢？
-bash-2.05b# cd /usr/src/sys
-bash-2.05b# grep -r "#define MSIZE" *
compile/NTD/machine/param.h:#define ...

改這個(gè)里面的：
/usr/src/sys/sys/param.h

作者: antijp 時(shí)間: 2006-05-25 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 not only mbuf, but also mbufclusters.

作者: antijp 時(shí)間: 2006-05-25 08:56

原帖由 雨絲風(fēng)片 于 2006-5-25 08:53 發(fā)表

改這個(gè)里面的：
/usr/src/sys/sys/param.h

I think modify the source file is finding trouble.
Simply recompile the kernel with this

options MSIZE=512

復(fù)制代碼

in your kernel configuration file.

作者: xfsoul 時(shí)間: 2006-05-25 09:05
# sysctl -a | grep mbuf
   mbuf_tag    0    0K    -       2  32
mbuf_jumbo_1:  16384,       0,    0,    0,       0
mbuf_jumbo_9: 9216,       0,    0,    0,       0
mbuf_jumbo_p: 4096,       0,    0,    0,       0
mbuf_cluster: 2048, 16960, 2176,    6,    2176
mbuf:          256,       0, 2178, 132,    6933
mbuf_packet:    256,       0, 1024, 1286, 176098214

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-25 09:08

原帖由 antijp 于 2006-5-25 08:54 發(fā)表
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 not only mbuf, but also mbufclusters.

樓主測(cè)試的數(shù)據(jù)包大小是確定的，改這個(gè)值就是想盡量避免使用cluster，看看從對(duì)純mbuf的處理和對(duì)cluster的處理流程上是否能找到一些線索。但我感覺應(yīng)該不只是處理流程的區(qū)別，很可能和內(nèi)存的分配、緩存、復(fù)用也有關(guān)系。多試無(wú)妨。

作者: xie_minix 時(shí)間: 2006-05-25 09:14
xfsoul:等你的消息,我想看看到底是不是m_devget的問(wèn)題
另:antijp的方法很好.我對(duì)使用FB不太熟悉

[ 本帖最后由 xie_minix 于 2006-5-25 09:16 編輯 ]

作者: antijp 時(shí)間: 2006-05-25 09:36

原帖由 雨絲風(fēng)片 于 2006-5-25 09:08 發(fā)表

樓主測(cè)試的數(shù)據(jù)包大小是確定的，改這個(gè)值就是想盡量避免使用cluster，看看從對(duì)純mbuf的處理和對(duì)cluster的處理流程上是否能找到一些線索。但我感覺應(yīng)該不只是處理流程的區(qū)別，很可能和內(nèi)存的分配、緩存、復(fù)用也 ...

According to the statistics posted out, the mbufclusters must have been used. But I doubt that this statistics was not gathered when running the benchmark, so perhaps it's not very useful.

[ 本帖最后由 antijp 于 2006-5-25 09:46 編輯 ]

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-25 09:47

原帖由 antijp 于 2006-5-25 09:36 發(fā)表

According to the statistics posted out, the mbufclusters must have been used. But I doubt that this statistics was not gathered when running the benchmark, so perhaps it't not very useful.

從樓主的數(shù)據(jù)長(zhǎng)度即可判斷出測(cè)試的時(shí)候肯定會(huì)使用cluster了：

If the amount of data is greater than or equal to 208 (MINCLBYTES), one or more clusters are used.

當(dāng)然，由于mbuf頭結(jié)構(gòu)的修改，目前的門限數(shù)值比208還要小。現(xiàn)在就是想先看看它不用cluster的時(shí)候的測(cè)試性能如何。

作者: xfsoul 時(shí)間: 2006-05-25 09:50
我編譯內(nèi)核加了：
options       MSIZE=1024

options       BRIDGE
options       DEVICE_POLLING
options       HZ=4000

編譯好后，測(cè)試包長(zhǎng)為512字節(jié)，發(fā)現(xiàn)性能沒(méi)有絲毫提升。
下面是smartbit發(fā)包的時(shí)候，讀出來(lái)的系統(tǒng)數(shù)據(jù)：
# sysctl kern.polling
kern.polling.idlepoll_sleeping: 1
kern.polling.stalled: 66
kern.polling.suspect: 6042
kern.polling.phase: 0
kern.polling.enable: 1
kern.polling.handlers: 4
kern.polling.residual_burst: 0
kern.polling.pending_polls: 0
kern.polling.lost_polls: 6762
kern.polling.short_ticks: 1178
kern.polling.reg_frac: 20
kern.polling.user_frac: 30
kern.polling.idle_poll: 0
kern.polling.each_burst: 100
kern.polling.burst_max: 300
kern.polling.burst: 300

# sysctl -a | grep mbuf
   mbuf_tag    0    0K    -       2  32
mbuf_jumbo_1:  16384,       0,    0,    0,       0
mbuf_jumbo_9: 9216,       0,    0,    0,       0
mbuf_jumbo_p: 4096,       0,    0,    0,       0
mbuf_cluster: 2048, 16960, 1920,    6,    1920
mbuf:          1024,       0, 1922, 126,    1245
mbuf_packet: 1024,       0, 1990,    58, 15962674

[ 本帖最后由 xfsoul 于 2006-5-25 09:52 編輯 ]

作者: colddawn 時(shí)間: 2006-05-25 09:54
kern.polling.burst_max: 300
kern.polling.burst: 300
這兩個(gè)值一樣，似乎burst不夠用了，繼續(xù)調(diào)大些試試看？？

作者: colddawn 時(shí)間: 2006-05-25 09:59
另外注意到你測(cè)試的數(shù)據(jù)FB的CPU占用率方面比較奇怪，尤其是小包的第一個(gè)50%，是不是開啟了HTT？關(guān)閉掉試試看。
還有這個(gè)參數(shù)kern.polling.user_frac: Desired user fraction of cpu time
把user占用的cpu時(shí)間片盡量壓縮，這樣內(nèi)核CPU利用率會(huì)比較高，畢竟linux下都高過(guò)90%了，F(xiàn)B這么少說(shuō)明是有問(wèn)題的。

作者: xfsoul 時(shí)間: 2006-05-25 10:00

原帖由 colddawn 于 2006-5-25 09:54 發(fā)表
kern.polling.burst_max: 300
kern.polling.burst: 300
這兩個(gè)值一樣，似乎burst不夠用了，繼續(xù)調(diào)大些試試看？？

HZ=4000
burst=300
理論可以發(fā)120萬(wàn)pps呢。

ps:我調(diào)成500性能也無(wú)變化

作者: xfsoul 時(shí)間: 2006-05-25 10:02

原帖由 colddawn 于 2006-5-25 09:59 發(fā)表
另外注意到你測(cè)試的數(shù)據(jù)FB的CPU占用率方面比較奇怪，尤其是小包的第一個(gè)50%，是不是開啟了HTT？關(guān)閉掉試試看。
還有這個(gè)參數(shù)kern.polling.user_frac: Desired user fraction of cpu time
把user占用的cpu時(shí)間片 ...

那個(gè)參數(shù)調(diào)整到更小也沒(méi)有意義，我從5開始每10一個(gè)檔都調(diào)節(jié)過(guò)了。

CPU利用率很低我也很奇怪，為什么這么多資源FB不去使用。
但是如果不開polling，CPU占用就上去了，也是90%多。

作者: colddawn 時(shí)間: 2006-05-25 10:03
kern.polling.burst: Current polling burst size
fw2# sysctl -d kern.polling.burst_max
kern.polling.burst_max: Max Polling burst size

應(yīng)該是要調(diào)整max，lz是說(shuō)錯(cuò)了還是調(diào)錯(cuò)了？

作者: xfsoul 時(shí)間: 2006-05-25 10:05

原帖由 colddawn 于 2006-5-25 10:03 發(fā)表
kern.polling.burst: Current polling burst size
fw2# sysctl -d kern.polling.burst_max
kern.polling.burst_max: Max Polling burst size

應(yīng)該是要調(diào)整max，lz是說(shuō)錯(cuò)了還是調(diào)錯(cuò)了？

我就是調(diào)整的max
sysctl kern.polling.burst_max=150
sysctl kern.polling.burst_max=200
sysctl kern.polling.burst_max=300
sysctl kern.polling.burst_max=400
sysctl kern.polling.burst_max=500
sysctl kern.polling.burst_max=1000
都試過(guò)了。

我測(cè)試的數(shù)據(jù)是我微調(diào)內(nèi)核參數(shù)得到的最好數(shù)據(jù)。

作者: xie_minix 時(shí)間: 2006-05-25 10:24
我還是希望能看到大概每秒執(zhí)行軟中斷的次數(shù)(POLLING),這樣可以確定調(diào)度器及系統(tǒng)的基本情況.
我在我家里的機(jī)器上(SMP PII 450 256M if_vr * 1)
3. 一些測(cè)試值:
kern.polling.dbg.poll_coun: 5404323 軟中斷實(shí)現(xiàn)的總次數(shù),默認(rèn)設(shè)置每秒大概在30000左右次調(diào)用
kern.polling.dbg.pollmore_coun: 4952549
kern.polling.dbg.poll_suspect: 0
kern.polling.dbg.poll_invoke: 24 從硬件時(shí)鐘中斷到netisr_poll的毫秒
kern.polling.dbg.net_load: 30 從NETISR_POLL到NETISR_POLLMORE的毫秒
kern.polling.burst: 150
kern.polling.burst_max: 150
kern.polling.each_burst: 20
kern.polling.idle_poll: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 20
kern.polling.short_ticks: 258
kern.polling.lost_polls: 4
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 1
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 2
kern.polling.stalled: 0
kern.polling.idlepoll_sleeping: 1

[ 本帖最后由 xie_minix 于 2006-5-25 10:26 編輯 ]

作者: antijp 時(shí)間: 2006-05-25 10:24

原帖由 雨絲風(fēng)片 于 2006-5-25 09:47 發(fā)表

從樓主的數(shù)據(jù)長(zhǎng)度即可判斷出測(cè)試的時(shí)候肯定會(huì)使用cluster了：

當(dāng)然，由于mbuf頭結(jié)構(gòu)的修改，目前的門限數(shù)值比208還要小。現(xiàn)在就是想先看看它不用cluster的時(shí)候的測(cè)試性能如何。

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 時(shí)間: 2006-05-25 10:31
我把msize改為4096性能也無(wú)提升，看來(lái)不是MSIZE的問(wèn)題：
下面是發(fā)包的時(shí)候抓下來(lái)的系統(tǒng)參數(shù)：

現(xiàn)在CPU占用率倒是上去了，發(fā)512字節(jié)的包的時(shí)候，到達(dá)了平均27%。我又測(cè)試了64字節(jié)的性能，也沒(méi)有提升！在64字節(jié)下，雙向各以18萬(wàn)pps速率發(fā)包的時(shí)候，CPU占用率也大幅提高，到達(dá)81%！可恨的是性能并無(wú)絲毫提升！
# sysctl -a | grep mbuf
   mbuf_tag    0    0K    -       2  32
mbuf_jumbo_1:  16384,       0,    0,    0,       0
mbuf_jumbo_9: 9216,       0,    0,    0,       0
mbuf_jumbo_p: 4096,       0,    0,    0,       0
mbuf_cluster: 2048, 16960, 2048,    6,    2048
mbuf:          4096,       0, 2050, 126,    746
mbuf_packet: 4096,       0, 1983, 193,  3819588

# sysctl -a | grep kern.polling
kern.polling.idlepoll_sleeping: 1
kern.polling.stalled: 66
kern.polling.suspect: 6078
kern.polling.phase: 0
kern.polling.enable: 1
kern.polling.handlers: 4
kern.polling.residual_burst: 0
kern.polling.pending_polls: 0
kern.polling.lost_polls: 8083
kern.polling.short_ticks: 1400
kern.polling.reg_frac: 200
kern.polling.user_frac: 20
kern.polling.idle_poll: 0
kern.polling.each_burst: 300
kern.polling.burst_max: 500
kern.polling.burst: 500

強(qiáng)烈懷疑是內(nèi)存操作速度太慢所致。
可是怎么驗(yàn)證呢。

[ 本帖最后由 xfsoul 于 2006-5-25 10:35 編輯 ]

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-25 11:06

原帖由 antijp 于 2006-5-25 10:24 發(fā)表

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éi)注意。Stevens寫書的時(shí)候用的MSIZE是128，那個(gè)時(shí)候決定MINCLSIZE的方法就是兩個(gè)mbuf的數(shù)據(jù)區(qū)大小，一個(gè)帶packet頭，一個(gè)不帶。因此，Stevens所舉的4.4BSD中的MINCLSIZE就是128-20+128-20-8 = 208，也就是說(shuō)只要用兩個(gè)mbuf無(wú)法存儲(chǔ)的數(shù)據(jù)，就需要使用cluster。（使用這個(gè)算法，如果MSIZE是256，則MINCLSIZE為464）

后來(lái)，mbuf的頭結(jié)構(gòu)確實(shí)是擴(kuò)展了，但MINCLSIZE的計(jì)算方法也改了。假設(shè)MSIZE為256，則MINCLSIZE為256-24-24+1 = 209，凡大于等于這個(gè)數(shù)值的數(shù)據(jù)就需要使用cluster。相對(duì)于4.4BSD中MSIZE同樣等于256的情況（MINCLSIZE =464），這個(gè)門限降低了一半。

作者: antijp 時(shí)間: 2006-05-25 12:16
Now I'm building 6.1 on another i386 machine, I'll check the size later.

作者: antijp 時(shí)間: 2006-05-25 12:41
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 時(shí)間: 2006-05-25 14:15
個(gè)人感覺這個(gè)測(cè)試結(jié)果大包性能提升不太像mbuf大小問(wèn)題。

作者: mirnshi 時(shí)間: 2006-05-25 15:00
帖子好長(zhǎng)呀，看了半天。

如果是橋模式，從網(wǎng)卡中斷開始，一直到這個(gè)包不在2層，都是在一個(gè)中斷里，所以橋轉(zhuǎn)發(fā)的效率很關(guān)鍵，專做橋設(shè)備就需要增加隊(duì)列之類的，提高包響應(yīng)速度了，否則僅僅要響應(yīng)中斷，系統(tǒng)就受不了了。
polling模式在某些情況下是可以提高效率的，polling模式主要原理就是網(wǎng)卡將數(shù)據(jù)包放到隊(duì)列中，cpu通過(guò)輪訓(xùn)的方式獲取數(shù)據(jù)包，屬于主動(dòng)方式，而中斷相當(dāng)于被動(dòng)接收。如果cpu在輪訓(xùn)間隔內(nèi)可以有效地處理隊(duì)列中的包，就可以提高效率，否則就會(huì)降低效率。
查看系統(tǒng)效率，尤其是網(wǎng)卡的，不僅僅要看vmstat，netstat可是必須要看的，可以看到包流量，錯(cuò)誤數(shù)等等。在有足夠cpu處理的情況下，如果流量上不去，那就要看看網(wǎng)卡了，看看錯(cuò)誤數(shù)是不是很高。這些數(shù)據(jù)都是互相影響的，但也不能作為唯一判定值。所以一定要通過(guò)判斷vmstat，netstat的監(jiān)測(cè)數(shù)據(jù)，在去調(diào)整相應(yīng)參數(shù)。

將mbuf的尺寸增大，并不會(huì)帶來(lái)特別顯著的提高，系統(tǒng)會(huì)根據(jù)包的大小，自動(dòng)分拆的，大家可以看看協(xié)議棧的實(shí)現(xiàn)。

作者: caibird3rd 時(shí)間: 2006-05-25 15:13
注意別把注意力全放在操作系統(tǒng)上，測(cè)試機(jī)本身（所用總線規(guī)格等）、網(wǎng)絡(luò)連接、smartbit的設(shè)置等等
都應(yīng)該檢查一遍

作者: xie_minix 時(shí)間: 2006-05-25 16:07
其實(shí)樓主的要求很簡(jiǎn)單,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.
我們是來(lái)給他想辦法,同時(shí)也提高我們自己.去尋找具體原因.你可以懷疑某個(gè)地
方出問(wèn)題,即使是比較幼稚的想法.但必須去實(shí)現(xiàn).用代碼或調(diào)試各種參數(shù)去測(cè)試.
另外說(shuō)句: 樓上的caibird3rd明顯沒(méi)進(jìn)入狀態(tài).哈哈
已經(jīng)有很多人都在反映該問(wèn)題.我知道的許多非常專業(yè)的放火墻開發(fā)人員(DDOS方向)
也遇到此問(wèn)題.到目前還沒(méi)有解決.以至于他們轉(zhuǎn)向了LINUX.
對(duì)于現(xiàn)在的FB,鎖的粗細(xì)粒度使用的還是有問(wèn)題.比如大家看看POLLING的5.3.使用
GAINT太多,還有些代碼重復(fù),不多評(píng)論了.繼續(xù)檢查

作者: www_ftp 時(shí)間: 2006-05-25 16:54
在Free BSD 6.0以后,polling的確不起什么作用,就是調(diào)的參數(shù)再好,最多只能達(dá)到不開polling的程度.在linux下也測(cè)試過(guò)打不打開polling性能也沒(méi)有什么變化.聽過(guò)4.11打開與不打開polling差別很大.

作者: xfsoul 時(shí)間: 2006-05-25 17:21
我現(xiàn)在已經(jīng)不指望通過(guò)調(diào)節(jié)FreeBSD參數(shù)來(lái)提高性能了。
我暫停這個(gè)測(cè)試，下周繼續(xù)在另外一個(gè)平臺(tái)上測(cè)試性能。
我已經(jīng)配置好了FreeBSD 4.11和FreeBSD6.1雙系統(tǒng)。對(duì)于該平臺(tái)，linux的性能已經(jīng)測(cè)試過(guò)了，由于該平臺(tái)性能比較強(qiáng)，linux表現(xiàn)還過(guò)得去。
硬件平臺(tái)：
CPU：雙路Opteron 2.4G
內(nèi)存：1G DDR400 雙通道開啟，ECC關(guān)閉
網(wǎng)卡：Intel雙光纖口網(wǎng)卡、Intel雙口網(wǎng)卡。這四個(gè)網(wǎng)卡都是連接在北橋上，PCI-X 64bit， 133MHz。

大約下周二開始測(cè)試。大家有空不妨幫我想想辦法呵，我先謝過(guò)了。

作者: caibird3rd 時(shí)間: 2006-05-25 17:29

原帖由 xie_minix 于 2006-5-25 16:07 發(fā)表
其實(shí)樓主的要求很簡(jiǎn)單,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.
我們是來(lái)給他想辦法,同時(shí)也提高我們自己.去尋找具體原因.你可以懷疑某個(gè)地
方出問(wèn)題,即使是比較幼稚的想法.但必須去實(shí)現(xiàn).用代碼或調(diào)試各種參數(shù)去測(cè)試.
另外說(shuō)句: 樓上的caibird3rd明顯沒(méi)進(jìn)入狀態(tài).哈哈
已經(jīng)有很多人都在反映該問(wèn)題.我知道的許多非常專業(yè)的放火墻開發(fā)人員(DDOS方向)
也遇到此問(wèn)題.到目前還沒(méi)有解決.以至于他們轉(zhuǎn)向了LINUX.
對(duì)于現(xiàn)在的FB,鎖的粗細(xì)粒度使用的還是有問(wèn)題.比如大家看看POLLING的5.3.使用
GAINT太多,還有些代碼重復(fù),不多評(píng)論了.繼續(xù)檢查 ...

哈哈，對(duì)FB我倒是不熟，只是略有耳聞FB的性能如何穩(wěn)定和有效率，真的比Linux差很多嗎？
說(shuō)老實(shí)話，對(duì)于比較成熟的一個(gè)發(fā)行版來(lái)說(shuō)，其運(yùn)行時(shí)的各種缺省參數(shù)一般都是仔細(xì)調(diào)優(yōu)了的，充分
權(quán)衡了各個(gè)子系統(tǒng)的影響、考慮到了各類常見應(yīng)用環(huán)境。

懷疑僅僅通過(guò)調(diào)整參數(shù)，能夠獲得多大的性能提升。
我的經(jīng)驗(yàn)，這種情況，要么是系統(tǒng)代碼內(nèi)在結(jié)構(gòu)決定，要么就是硬件平臺(tái)甚至測(cè)試環(huán)境的影響。
不是我瞧不起各位老大的能力，前者的分析很難啊。
在這里給各位加油，希望有一天FB里面也有大量國(guó)人的補(bǔ)丁，呵呵

作者: mirnshi 時(shí)間: 2006-05-25 17:49

原帖由 caibird3rd 于 2006-5-25 17:29 發(fā)表

哈哈，對(duì)FB我倒是不熟，只是略有耳聞FB的性能如何穩(wěn)定和有效率，真的比Linux差很多嗎？
說(shuō)老實(shí)話，對(duì)于比較成熟的一個(gè)發(fā)行版來(lái)說(shuō)，其運(yùn)行時(shí)的各種缺省參數(shù)一般都是仔細(xì)調(diào)優(yōu)了的，充分
權(quán)衡了各個(gè)子系統(tǒng)的影 ...

無(wú)論OS，還是DB，它的發(fā)行版都是為了適合絕大多數(shù)情況的，要想在某種應(yīng)用和場(chǎng)合發(fā)揮最大的性能，各項(xiàng)參數(shù)是必須調(diào)整的。所以不要這么講，否則各類系統(tǒng)的管理員就要失業(yè)了。

作者: xie_minix 時(shí)間: 2006-05-25 18:11
mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問(wèn)題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒(méi)經(jīng)過(guò)思考(請(qǐng)?jiān)徫疫@么說(shuō),他們也不容易),比如你看:
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); <---------
他是不是怕沒(méi)鎖住啊,哈哈

作者: xfsoul 時(shí)間: 2006-05-25 18:23

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問(wèn)題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒(méi)經(jīng)過(guò)思考(請(qǐng)?jiān)徫疫@么說(shuō),他們也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx ...

實(shí)在暈倒，BSD內(nèi)核中也有這樣質(zhì)量的代碼？

作者: caibird3rd 時(shí)間: 2006-05-25 19:05

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問(wèn)題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒(méi)經(jīng)過(guò)思考(請(qǐng)?jiān)徫疫@么說(shuō),他們也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx ...

不曉得是不是跟linux的大內(nèi)核鎖一樣，可以重復(fù)進(jìn)入的？
ether_poll（）說(shuō)不定在別的地方還有調(diào)用到，所以要加鎖
大內(nèi)核鎖在linux里已經(jīng)很少用到了。看來(lái)linux更注重性能的說(shuō)法有一定道理

另外，不曉得FB有沒(méi)有針對(duì)Opteron的優(yōu)化？樓主用的Opteron應(yīng)該很牛啦

[ 本帖最后由 caibird3rd 于 2006-5-25 19:08 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-25 19:36
標(biāo)題: 回復(fù) 62樓 caibird3rd 的帖子
還有更牛的，雙路Opteron 270，就是四個(gè)2.0G的Opteron處理器。
另外還有雙路雙核XEON，每個(gè)CPU都支持HT。系統(tǒng)應(yīng)該會(huì)認(rèn)出八個(gè)CPU。
不過(guò)在雙路Opteron 250上也無(wú)法改善FreeBSD性能的話。
就只有用linux了。

作者: mirnshi 時(shí)間: 2006-05-25 22:07

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問(wèn)題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒(méi)經(jīng)過(guò)思考(請(qǐng)?jiān)徫疫@么說(shuō),他們也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx ...

6.x中的代碼，不同呀。主版本3、5都不是很好，命短。

/*
* ether_poll is called from the idle loop.
*/
void
ether_poll(int count)
{
int i;
NET_LOCK_GIANT();
mtx_lock(&poll_mtx);
if (count > poll_each_burst)
count = poll_each_burst;
for (i = 0 ; i < poll_handlers ; i++)
pr[i].handler(pr[i].ifp, POLL_ONLY, count);
mtx_unlock(&poll_mtx);
NET_UNLOCK_GIANT();
}
static void
poll_idle(void)
{
struct thread *td = curthread;
struct rtprio rtp;
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);
} else {
idlepoll_sleeping = 1;
tsleep(&idlepoll_sleeping, 0, "pollid", hz * 3);
}
}
}

復(fù)制代碼

個(gè)人感覺，還是扔掉5.x吧，因?yàn)楫?dāng)初粗粗看了5.x，就覺得是個(gè)試驗(yàn)品，就沒(méi)有仔細(xì)看，一直在4.x上做。6.1出來(lái)了，應(yīng)該算是穩(wěn)定住了

作者: mirnshi 時(shí)間: 2006-05-25 22:17

原帖由 xfsoul 于 2006-5-25 19:36 發(fā)表
還有更牛的，雙路Opteron 270，就是四個(gè)2.0G的Opteron處理器。
另外還有雙路雙核XEON，每個(gè)CPU都支持HT。系統(tǒng)應(yīng)該會(huì)認(rèn)出八個(gè)CPU。
不過(guò)在雙路Opteron 250上也無(wú)法改善FreeBSD性能的話。
就只有用linux了。

個(gè)人以為，雙核并不是完全意義上的“雙CPU”，在目前的這種IA架構(gòu)上，CPU多了，不見得是好事，這些CPU調(diào)度起來(lái)都是件麻煩事。
從我目前了解到的以及實(shí)驗(yàn)數(shù)據(jù)來(lái)說(shuō)，cpu的處理速度足夠了應(yīng)付中低端(1G及1G以下)，只是總線有問(wèn)題，所以網(wǎng)絡(luò)的速度跟不上。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-26 08:27

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問(wèn)題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒(méi)經(jīng)過(guò)思考(請(qǐng)?jiān)徫疫@么說(shuō),他們也不容易),比如你看:
...

原作者在此：

但從André Oppermann的一篇文章來(lái)看，6.0專門針對(duì)SMP的情況對(duì)polling進(jìn)行了修改：

Interface Polling

The 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.

而且，從kern_poll.c文件的cvs記錄來(lái)看，對(duì)鎖的使用進(jìn)行優(yōu)化的工作也一直在進(jìn)行，比如：
http://lists.freebsd.org/piperma ... ptember/051848.html

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-26 08:36

原帖由 xfsoul 于 2006-5-25 18:23 發(fā)表

實(shí)在暈倒，BSD內(nèi)核中也有這樣質(zhì)量的代碼？

先污染，后治理。

[ 本帖最后由雨絲風(fēng)片于 2006-5-26 08:51 編輯 ]

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-26 09:24

原帖由 mirnshi 于 2006-5-25 15:00 發(fā)表
將mbuf的尺寸增大，并不會(huì)帶來(lái)特別顯著的提高，系統(tǒng)會(huì)根據(jù)包的大小，自動(dòng)分拆的，大家可以看看協(xié)議棧的實(shí)現(xiàn)。 ...

請(qǐng)教一下，這個(gè)分拆體現(xiàn)在哪兒？

擴(kuò)大mbuf尺寸，不考慮是否真能提高性能，至少可以盡量避免系統(tǒng)使用mbuf鏈或者cluster。另外，樓主兩個(gè)網(wǎng)卡mtu一致，而且是二層轉(zhuǎn)發(fā)，似乎也涉及不到ip fragmentation的問(wèn)題。所以請(qǐng)教這個(gè)“自動(dòng)分拆”的含義？

作者: colddawn 時(shí)間: 2006-05-26 09:47
他的意思是指包在mbuf和cluster的分拆而不是包數(shù)據(jù)本身分拆，所以跟MTU無(wú)關(guān)了，使用cluster是有好處的，例如對(duì)于同一包的數(shù)據(jù)處理可以直接通過(guò)指向cluster指針，增加引用計(jì)數(shù)器，避免數(shù)據(jù)復(fù)制等。如果不使用cluster可以大幅度增加性能當(dāng)初設(shè)計(jì)就不會(huì)有cluster了。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-26 09:57

原帖由 colddawn 于 2006-5-26 09:47 發(fā)表
他的意思是指包在mbuf和cluster的分拆而不是包數(shù)據(jù)本身分拆，所以跟MTU無(wú)關(guān)了，使用cluster是有好處的，例如對(duì)于同一包的數(shù)據(jù)處理可以直接通過(guò)指向cluster指針，增加引用計(jì)數(shù)器，避免數(shù)據(jù)復(fù)制等。如果不使用clust ...

不是討論是否需要使用、當(dāng)時(shí)是否有必要設(shè)計(jì)cluster。我的意思很簡(jiǎn)單，系統(tǒng)是否使用mbuf鏈或者mcluster來(lái)存儲(chǔ)網(wǎng)絡(luò)數(shù)據(jù)都取決于mbuf的尺寸，既然把mbuf尺寸調(diào)整到足以存放樓主測(cè)試的全部數(shù)據(jù)，又何來(lái)“包在mbuf和cluster的分拆”呢？

作者: mirnshi 時(shí)間: 2006-05-26 10:30

原帖由 雨絲風(fēng)片 于 2006-5-26 09:24 發(fā)表

請(qǐng)教一下，這個(gè)分拆體現(xiàn)在哪兒？

擴(kuò)大mbuf尺寸，不考慮是否真能提高性能，至少可以盡量避免系統(tǒng)使用mbuf鏈或者cluster。另外，樓主兩個(gè)網(wǎng)卡mtu一致，而且是二層轉(zhuǎn)發(fā)，似乎也涉及不到ip fragmentation的問(wèn)題 ...

這個(gè)分拆，是不恰當(dāng)?shù)�，我的本意是分揀。寫完后，沒(méi)有仔細(xì)審看，表示歉意。

在協(xié)議棧實(shí)現(xiàn)中，會(huì)根據(jù)包的大小，申請(qǐng)不同的mbuf。而且在我的印象中，從網(wǎng)卡上來(lái)的包使用不到cluster，或者說(shuō)承擔(dān)轉(zhuǎn)發(fā)時(shí)，是不使用cluster的，只有從會(huì)話層下來(lái)的時(shí)候，由于數(shù)據(jù)包很大，需要拆成適宜大小并組成cluster。所以我以往的經(jīng)驗(yàn)，做網(wǎng)關(guān)類，不必調(diào)整cluster的數(shù)量，mbuf的數(shù)量倒是很重要，如果有大隊(duì)列，還要調(diào)整內(nèi)核可使用的內(nèi)存空間大小。

所以你即便將mbuf調(diào)得很大，協(xié)議棧還是要判斷一下，再去申請(qǐng)。系統(tǒng)缺省已經(jīng)有2k的了，足夠應(yīng)付鏈路上的包了，那你說(shuō)提高最小的mbuf有必要嗎？只會(huì)浪費(fèi)內(nèi)存。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-26 11:41

原帖由 mirnshi 于 2006-5-26 10:30 發(fā)表
在協(xié)議棧實(shí)現(xiàn)中，會(huì)根據(jù)包的大小，申請(qǐng)不同的mbuf。而且在我的印象中，從網(wǎng)卡上來(lái)的包使用不到cluster，或者說(shuō)承擔(dān)轉(zhuǎn)發(fā)時(shí)，是不使用cluster的，只有從會(huì)話層下來(lái)的時(shí)候，由于數(shù)據(jù)包很大，需要拆成適宜大小并組成cluster。所以我以往的經(jīng)驗(yàn)，做網(wǎng)關(guān)類，不必調(diào)整cluster的數(shù)量，mbuf的數(shù)量倒是很重要，如果有大隊(duì)列，還要調(diào)整內(nèi)核可使用的內(nèi)存空間大小。

所以你即便將mbuf調(diào)得很大，協(xié)議棧還是要判斷一下，再去申請(qǐng)。系統(tǒng)缺省已經(jīng)有2k的了，足夠應(yīng)付鏈路上的包了，那你說(shuō)提高最小的mbuf有必要嗎？只會(huì)浪費(fèi)內(nèi)存。 ...

“從網(wǎng)卡上來(lái)的包使用不到cluster”，那m_devget()函數(shù)中的此段代碼何解？

if (totlen + off >= MINCLSIZE) {
m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);
len = MCLBYTES;
} else {
m = m_gethdr(M_DONTWAIT, MT_DATA);
len = MHLEN;

復(fù)制代碼

“所以你即便將mbuf調(diào)得很大，協(xié)議棧還是要判斷一下，再去申請(qǐng)。”，修改mbuf的大小，就是要影響協(xié)議棧的上述“判斷”過(guò)程。

上面是和你討論“拆分”的事情，現(xiàn)在回到樓主的測(cè)試，修改mbuf的大小只是嘗試上述不同的分配策略是否會(huì)對(duì)此造成影響，這主要是流程性的影響。如你所說(shuō)，可供mbuf使用的內(nèi)存數(shù)量確實(shí)也是一個(gè)關(guān)鍵，我們可以在測(cè)試過(guò)程中關(guān)注內(nèi)存的使用情況，看看這方面是否有瓶頸。

作者: xfsoul 時(shí)間: 2006-05-26 11:53
內(nèi)存占用到不大。應(yīng)該是性能拷貝的性能消耗太大。

作者: xie_minix 時(shí)間: 2006-05-26 12:46
netisr_pollmore函數(shù)中的
kern_load = (kern_load * hz) / 10000;這句有問(wèn)題.
應(yīng)該錯(cuò)了.
他的錯(cuò)誤的算法將導(dǎo)致hz在默認(rèn)100時(shí)性能...
kern.polling.dbg.pollkern: 1 這是網(wǎng)絡(luò)軟中斷所占比率為1%
kern.polling.dbg.kernpoll_burst: 150 以至于poll_burst不斷增加到頂.
kern.polling.dbg.on_cpu1: 0
kern.polling.dbg.net_load: 0
kern.polling.dbg.poll_invoke: 344070598
kern.polling.dbg.poll_suspect: 744461
kern.polling.dbg.pollmore_coun: 719577
kern.polling.dbg.poll_coun: 744461
下個(gè)帖有說(shuō)明,是我的想法有問(wèn)題.

[ 本帖最后由 xie_minix 于 2006-5-26 13:47 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-26 13:26
xie_minix兄、版主兄還有其他幾位兄弟，大家一起努力啊。
如果能把FreeBSD polling的一些缺陷修正，也算是對(duì)FreeBSD的不小貢獻(xiàn)了。

作者: xie_minix 時(shí)間: 2006-05-26 13:46
不對(duì),還是我錯(cuò)了,向大家解釋一下:
if (kern_load > (100 - user_frac)) {
這句的原本意思是:
求軟件中斷在整個(gè)1秒時(shí)間所占百分比是否大于減去其他所占用時(shí)間.
大于就說(shuō)明時(shí)間夠了.poll_burst--;
小于則poll_burst++只要加后不大于最大值.
poll_burst的值很重要,要不然就不能體現(xiàn)出整個(gè)算法的合理性.
我們?cè)趤?lái)看看kern_load = (kern_load * hz) / 10000;這句
是為了求得網(wǎng)絡(luò)軟中斷所占1秒中的比率.10000這個(gè)常量有點(diǎn)
很難懂.kern_load之前得到的是軟件中斷所使用的毫秒.
那么kern_load*hz代表每秒鐘軟中斷大概是占了多少毫秒,
這樣推算的話,10000應(yīng)該是1000000/100,即先除以1百萬(wàn)毫秒(1秒)
得到百分比,再乘以100取出百分?jǐn)?shù).
哎這個(gè)10000也不寫個(gè)說(shuō)明.

[ 本帖最后由 xie_minix 于 2006-5-26 13:48 編輯 ]

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-26 14:07

原帖由 xie_minix 于 2006-5-26 13:46 發(fā)表
不對(duì),還是我錯(cuò)了,向大家解釋一下:
if (kern_load > (100 - user_frac)) {
這句的原本意思是:
求軟件中斷在整個(gè)1秒時(shí)間所占百分比是否大于減去其他所占用時(shí)間.
大于就說(shuō)明時(shí)間夠了.poll_burst--;
小于則p ...

原來(lái)如此！看來(lái)此公編程風(fēng)格有待改進(jìn)。

對(duì)于polling的算法還不熟，結(jié)合你的文章，繼續(xù)閱讀代碼。

作者: mirnshi 時(shí)間: 2006-05-26 14:08

原帖由 雨絲風(fēng)片 于 2006-5-26 11:41 發(fā)表

...

回答問(wèn)題前，需要仔細(xì)看代碼了，許久不弄，就是生疏了。
我看了看以前調(diào)優(yōu)的一些記錄，的確和cluster相關(guān)的，可以通過(guò)調(diào)高nmbcluster參數(shù)，提高系統(tǒng)處理網(wǎng)絡(luò)效率
這個(gè)參數(shù)需要在啟動(dòng)時(shí)，設(shè)置，一旦內(nèi)核啟動(dòng)了，就不能更改了。在/boot/loader.rc中設(shè)置
警告：這個(gè)值不能過(guò)大，否則系統(tǒng)會(huì)因沒(méi)有足夠的內(nèi)存分配而啟動(dòng)不起來(lái)

[ 本帖最后由 mirnshi 于 2006-5-26 14:10 編輯 ]

作者: mirnshi 時(shí)間: 2006-05-26 14:16
FreeBSD在網(wǎng)絡(luò)處理上，我一直認(rèn)為是非常強(qiáng)的，我曾在志強(qiáng)2.4，內(nèi)存1G，4.11，接收900MB，CPU還能空余5-9%，但是發(fā)包就不行了，只能達(dá)到3、400MB。這是為了測(cè)試極限值，所有的包都是收到就丟棄。所以能達(dá)到極限。

作者: xfsoul 時(shí)間: 2006-05-26 14:34
標(biāo)題: 回復(fù) 79樓 mirnshi 的帖子
我在PD 820和AMD Opteron平臺(tái)，linux網(wǎng)橋透明轉(zhuǎn)發(fā)。當(dāng)包>512時(shí)候，雙向千兆線速轉(zhuǎn)發(fā)，輕松愉快！

作者: caibird3rd 時(shí)間: 2006-05-26 14:42

原帖由 xfsoul 于 2006-5-26 14:34 發(fā)表
我在PD 820和AMD Opteron平臺(tái)，linux網(wǎng)橋透明轉(zhuǎn)發(fā)。當(dāng)包>512時(shí)候，雙向千兆線速轉(zhuǎn)發(fā)，輕松愉快！

現(xiàn)在的系統(tǒng)，包括linux和FB大包的性能都不錯(cuò)。我們還是要相信各位大牛地～
要顯著提高小包性能，不在系統(tǒng)軟件結(jié)構(gòu)或者硬件平臺(tái)上做工作是不太可能地～

作者: colddawn 時(shí)間: 2006-05-26 15:26

原帖由 雨絲風(fēng)片 于 2006-5-26 09:57 發(fā)表

不是討論是否需要使用、當(dāng)時(shí)是否有必要設(shè)計(jì)cluster。我的意思很簡(jiǎn)單，系統(tǒng)是否使用mbuf鏈或者mcluster來(lái)存儲(chǔ)網(wǎng)絡(luò)數(shù)據(jù)都取決于mbuf的尺寸，既然把mbuf尺寸調(diào)整到足以存放樓主測(cè)試的全部數(shù)據(jù)，又何來(lái)“包在mbuf ...

cluster不光是用來(lái)存貯長(zhǎng)度大的數(shù)據(jù)，同時(shí)還有引用計(jì)數(shù)器之類的設(shè)計(jì)思路，這樣mbuf中可以注入和剝離各層的報(bào)頭，cluster中存放數(shù)據(jù)，而不同層傳遞只需要引用到cluster的指針即可，如果純粹使用mbuf，在各層中傳遞數(shù)據(jù)將會(huì)引發(fā)大量的mbuf中數(shù)據(jù)位移操作或者是mbuf拷貝，性能受到影響，所以即使mbuf足夠大到可以存儲(chǔ)整個(gè)包的數(shù)據(jù)，使用cluster還是有必要的。
但這里討論的橋轉(zhuǎn)發(fā)都是在二層處理，所以基本很少牽扯我說(shuō)的這些操作，可能與主題無(wú)關(guān)。但同時(shí)也可能很少牽扯到mbuf本身數(shù)據(jù)的操作，只是mbuf鏈表的增刪改，所以你加大mbuf大小的思路也基本影響不到性能，這就要到代碼里求證了。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-26 16:17

原帖由 colddawn 于 2006-5-26 15:26 發(fā)表
cluster不光是用來(lái)存貯長(zhǎng)度大的數(shù)據(jù)，同時(shí)還有引用計(jì)數(shù)器之類的設(shè)計(jì)思路，這樣mbuf中可以注入和剝離各層的報(bào)頭，cluster中存放數(shù)據(jù)，而不同層傳遞只需要引用到cluster的指針即可，如果純粹使用mbuf，在各層中 ...

你說(shuō)的有道理！

我原來(lái)是憑直覺，認(rèn)為相對(duì)于mbuf鏈或者cluster而言，把數(shù)據(jù)放在一個(gè)mbuf中的效率就要好一些，因?yàn)椤疤幚怼彼坪跻?jiǎn)單一些，但好像這種流程上的東西確實(shí)也簡(jiǎn)單不了多少。從mbuf中的數(shù)據(jù)拷貝來(lái)講，cluster確實(shí)比mbuf的效率要高得多：

if (m->m_flags & M_EXT) {
n->m_data = m->m_data + off;
n->m_ext = m->m_ext;
n->m_flags |= M_EXT;
MEXT_ADD_REF(m);
n->m_ext.ref_cnt = m->m_ext.ref_cnt;
} else
bcopy(mtod(m, caddr_t)+off, mtod(n, caddr_t),
(u_int)n->m_len);

復(fù)制代碼

作者: www_ftp 時(shí)間: 2006-05-26 16:20
測(cè)試時(shí)發(fā)現(xiàn):HZ burst_max等增大時(shí) kern.polling.burst 會(huì)自己變小.導(dǎo)致系統(tǒng)每秒取的包的總數(shù)基本不變,造成大量包丟失.然后此時(shí)系統(tǒng)負(fù)載及cpu占用還都比較低.不知算法哪兒出問(wèn)題了.

作者: xfsoul 時(shí)間: 2006-05-26 16:25

原帖由 www_ftp 于 2006-5-26 16:20 發(fā)表
測(cè)試時(shí)發(fā)現(xiàn):HZ burst_max等增大時(shí) kern.polling.burst 會(huì)自己變小.導(dǎo)致系統(tǒng)每秒取的包的總數(shù)基本不變,造成大量包丟失.然后此時(shí)系統(tǒng)負(fù)載及cpu占用還都比較低.不知算法哪兒出問(wèn)題了.

嗯的確是這樣。kern.polling.burst的確會(huì)自動(dòng)變的非常小。導(dǎo)致性能上不去。
不過(guò)當(dāng)kern.polling.burst比較大（比方500），HZ=4000，這個(gè)時(shí)候按說(shuō)包速可以比較大，可是性能也不行。

非常希望大家能把問(wèn)題分析清楚。
網(wǎng)絡(luò)性能對(duì)一個(gè)網(wǎng)絡(luò)操作系統(tǒng)來(lái)說(shuō)可是非常重要的��！

作者: www_ftp 時(shí)間: 2006-05-26 16:42

原帖由 xfsoul 于 2006-5-26 16:25 發(fā)表

嗯的確是這樣。kern.polling.burst的確會(huì)自動(dòng)變的非常小。導(dǎo)致性能上不去。
不過(guò)當(dāng)kern.polling.burst比較大（比方500），HZ=4000，這個(gè)時(shí)候按說(shuō)包速可以比較大，可是性能也不行。

非常希望大家能把問(wèn)題 ...

是呀,這個(gè)問(wèn)題的確很重要,要解決這個(gè)問(wèn)題必須有多位牛人共同努力.實(shí)際測(cè)試中還發(fā)現(xiàn)兩個(gè)問(wèn)題,把polling升級(jí)到最新,也沒(méi)有任何性能上的提高.6.0 6.1都有個(gè)打開polling在極限下假死機(jī)的現(xiàn)象,現(xiàn)象是打開polling,收受大量的小量,這時(shí)cpu 100%,然后減低小包數(shù)量,也自己恢復(fù)不過(guò)處于假死機(jī)狀態(tài).6.1RC1就不存在這個(gè)問(wèn)題,只要減小包的數(shù)量,自己馬上恢復(fù),不存在假死機(jī)狀態(tài).

作者: xie_minix 時(shí)間: 2006-05-26 17:05
www_ftp老弟.請(qǐng)貼出機(jī)器的配置情況.謝謝

作者: zjzf_2 時(shí)間: 2006-05-26 20:32
freebsd 6.0的 polling 的確沒(méi)有什么效果這個(gè)我進(jìn)行了反復(fù)的測(cè)試

82546網(wǎng)卡freebsd4.11 打開polling hz=1000 p42.8 64bytes的報(bào)轉(zhuǎn)發(fā)率可以到500m以上

而換了freebsd6.0 只能到250M
polling SMP AMD64 我都測(cè)試過(guò) 非常遺憾無(wú)法突破300m

順便告訴你我沒(méi)有用什么netbsd移植過(guò)來(lái)的if_bridge             也沒(méi)有用freebsd原有的的bridge  根本不是bridge的問(wèn)題

熱心的老大 Dennis2  幫我找了篇文章 New Networking Features in FreeBSD 6.0
文中提到
The first go on fine-grained network locking in
FreeBSD 5 has been greatly enhanced and
refined for excellent SMP scalability. For single
processor machines all performance regressions
due to locking overhead have been eleminated
and FreeBSD 6 reaches the same speed in heavy
duty network streaming as the FreeBSD 4 series.
但是實(shí)際上freebsd 6并不能帶給我們昔日強(qiáng)勁的包轉(zhuǎn)發(fā)性能

我也開始懷疑是過(guò)多的mutex降低了效率但是為了堅(jiān)守bsd陣營(yíng) 我嘗試了DragonFly
DragonFly自稱是freebsd4.9的延續(xù)
DragonFly的包轉(zhuǎn)發(fā)性能可以說(shuō)是強(qiáng)于freebsd6.x的我在相同的硬件上可以達(dá)到300m 但是較freebsd4.11還是相差太遠(yuǎn)

目前我個(gè)人認(rèn)為驅(qū)動(dòng)程序是一個(gè) 非常重要的因素因?yàn)閘inux也曾出現(xiàn)過(guò)新驅(qū)動(dòng)包轉(zhuǎn)發(fā)性能下降的問(wèn)題

我還在繼續(xù)關(guān)注并嘗試解決這個(gè)問(wèn)題

另外提醒大家類似問(wèn)題不要總想著高手能給你一個(gè)完美的答案

謝老師也在這里好久沒(méi)見您
Dennis2老大幫我找了些資料其中包括這個(gè)
http://proj.sunet.se/LSR3-s/ netbsd在萬(wàn)兆以太網(wǎng)創(chuàng)下的一個(gè)紀(jì)錄不過(guò)我想小包才能說(shuō)明問(wèn)題

另外netbsd 曾經(jīng)有人做過(guò)polling方面的工作希望能給您帶來(lái)幫助http://thir.org/thir/NetBSD/devicepolling.en.html

最后提議下  多處理器的工作大家都盯著對(duì)稱多處理在想我覺得解決包轉(zhuǎn)發(fā)這種對(duì)問(wèn)題應(yīng)該朝著非對(duì)稱多處理多想想當(dāng)然這個(gè)難度不小

[ 本帖最后由 zjzf_2 于 2006-5-26 20:46 編輯 ]

作者: www_ftp 時(shí)間: 2006-05-26 21:44

原帖由 xie_minix 于 2006-5-26 17:05 發(fā)表
www_ftp老弟.請(qǐng)貼出機(jī)器的配置情況.謝謝

Intel(R) Pentium(R) 4 CPU 3.00GHz

real memory = 1065287680 (1015 MB)

avail memory = 945688576 (901 MB)

Intel82547EI CSA

作者: xfsoul 時(shí)間: 2006-05-30 19:23
最新測(cè)試結(jié)果出爐，數(shù)據(jù)沒(méi)有經(jīng)過(guò)整理，太忙了，呵呵。
測(cè)試硬件平臺(tái)：
CPU：雙Opteron 250（運(yùn)行頻率2.4G）
內(nèi)存：DDR400 雙通道（ECC關(guān)閉）
網(wǎng)卡：Intel雙口千兆網(wǎng)卡
Smartbit千兆口兩個(gè)
Smartwindow 9.0

linux 2.6.9(redhat enterprise linux 4 update1)
包長(zhǎng) 帶寬       包速(pps)  字節(jié)速率(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)
包長(zhǎng) 帶寬       包速(pps)  字節(jié)速率(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)
包長(zhǎng) 帶寬       包速(pps)  字節(jié)速率(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)
包長(zhǎng) 帶寬       包速(pps)  字節(jié)速率(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 于 2006-5-31 08:58 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-30 19:24
先測(cè)了這么多，其他的明天繼續(xù)測(cè)。
FreeBSD 6.0終于翻身了，不開polling性能優(yōu)于linux。
但是開啟polling后，性能會(huì)飛速下降��！
我郁悶。
倒是FreeBSD 4.11的polling還可以！

作者: colddawn 時(shí)間: 2006-05-31 07:42
lz可以試試把7-CURRENT的em驅(qū)動(dòng)替換掉FB6的測(cè)試一下看看，據(jù)說(shuō)這方面對(duì)于SMP支持還在改進(jìn)中，并且可能替換后性能會(huì)有比較可觀的提升。

還有問(wèn)下就是為什么這個(gè)測(cè)試結(jié)果比你前面貼出來(lái)的大包性能有比較大的提升？軟硬件環(huán)境和某些配置做過(guò)改動(dòng)嗎？

[ 本帖最后由 colddawn 于 2006-5-31 07:45 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-31 08:59
硬件平臺(tái)根本就不一樣。
上次是P4 2.8B，這次是雙路Opteron。
當(dāng)然不一樣。

作者: xfsoul 時(shí)間: 2006-05-31 08:59

原帖由 colddawn 于 2006-5-31 07:42 發(fā)表
lz可以試試把7-CURRENT的em驅(qū)動(dòng)替換掉FB6的測(cè)試一下看看，據(jù)說(shuō)這方面對(duì)于SMP支持還在改進(jìn)中，并且可能替換后性能會(huì)有比較可觀的提升。

還有問(wèn)下就是為什么這個(gè)測(cè)試結(jié)果比你前面貼出來(lái)的大包性能有比較大的提升 ...

我這里沒(méi)有7-CURRENT啊，你能不能發(fā)一個(gè)給我？

作者: colddawn 時(shí)間: 2006-05-31 09:21
我這里也沒(méi)有，cvs就能拿到，替換現(xiàn)有的src然后編譯下內(nèi)核就可以了。
還有cvsweb也能找到http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/#dirlist

作者: xfsoul 時(shí)間: 2006-05-31 10:07

原帖由 colddawn 于 2006-5-31 09:21 發(fā)表
我這里也沒(méi)有，cvs就能拿到，替換現(xiàn)有的src然后編譯下內(nèi)核就可以了。
還有cvsweb也能找到http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/#dirlist

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/em/

里面只有一個(gè)makefile。

[ 本帖最后由 xfsoul 于 2006-5-31 10:15 編輯 ]

作者: xfsoul 時(shí)間: 2006-05-31 10:20
現(xiàn)在FreeBSD在雙路Opteron上，已經(jīng)到了雙向46萬(wàn)pps不丟包（參見第九頁(yè)測(cè)試記錄）。

不知道有無(wú)辦法突破記錄呵呵。

FreeBSD是不是對(duì)xeon平臺(tái)支持不好啊。
還有4Xeon平臺(tái)，每個(gè)Xeon都支持超線程。
CPU資源很強(qiáng)大啊。

作者: xfsoul 時(shí)間: 2006-05-31 15:07
我怎么看過(guò)去一段時(shí)間，兩個(gè)網(wǎng)卡各收到多少包呢？
我想測(cè)試一下沒(méi)有網(wǎng)橋時(shí)候 FreeBSD收包性能。
netstat -w 10 -i em0
看到的結(jié)果根本不對(duì)！我用smartbit發(fā)了大量的包，netstat都沒(méi)有統(tǒng)計(jì)到。

作者: 雨絲風(fēng)片 時(shí)間: 2006-05-31 16:29

原帖由 xfsoul 于 2006-5-31 15:07 發(fā)表
我怎么看過(guò)去一段時(shí)間，兩個(gè)網(wǎng)卡各收到多少包呢？
我想測(cè)試一下沒(méi)有網(wǎng)橋時(shí)候 FreeBSD收包性能。
netstat -w 10 -i em0
看到的結(jié)果根本不對(duì)！我用smartbit發(fā)了大量的包，netstat都沒(méi)有統(tǒng)計(jì)到。

是有網(wǎng)橋的時(shí)候不準(zhǔn)還是沒(méi)網(wǎng)橋的時(shí)候不準(zhǔn)？

作者: xfsoul 時(shí)間: 2006-05-31 17:24

原帖由 雨絲風(fēng)片 于 2006-5-31 16:29 發(fā)表

是有網(wǎng)橋的時(shí)候不準(zhǔn)還是沒(méi)網(wǎng)橋的時(shí)候不準(zhǔn)？

netstat在FreeBSD 4.11下統(tǒng)計(jì)的大約對(duì)頭，在FreeBSD 6.1上統(tǒng)計(jì)的根本不對(duì)。

我在FreeBSD 4.11下關(guān)了POLLING，開了SMP。測(cè)試了一下網(wǎng)橋轉(zhuǎn)發(fā)性能（無(wú)丟包時(shí)峰值吞吐率）。
發(fā)現(xiàn)性能比開polling差不多，硬件還是前述平臺(tái)：

FreeBSD 4.11(polling disabled，SMP enable)
包長(zhǎng) 帶寬       包速(pps)  字節(jié)速率(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%

另外請(qǐng)問(wèn)一下在FreeBSD下有沒(méi)有性能不錯(cuò)的pcap工具

歡迎光臨 Chinaunix (http://72891.cn/)