都有可能吧 要看是什麼device

switch chip也有可能有對multicast作處理

用smartbit打 然後在driver那裡加個counter這樣應該就知道了

不過這個問題應該要請專業的來解答才對 jeason還不出來

叫我幹嘛啦 我不做網路很久了ㄟ

不會對 multicast 特別處理的網卡一定是會很慢的啦 我還沒看過有哪個網卡 chip 有對 multicast 特別做啥鬼功夫的 一般都是 switch 會做掉 網卡只純粹收發他要的 packets...

我也很久不做網路了... 就算有做，每次遇到問題時都覺得自己一點兒都不熟.. ^^; 總之..我只是在喃喃自語而已...

還好 我是封閉網路。研究一下，可以的話，就改一下driver好了。

至於兩台對接 performance 低我反而會覺得是正常的 multicast group 如果設一樣的話一個 packet 出去兩個都會拿到 這樣應該是會有比較低的performance 沒錯

有 support multicast/IGMP 的 switch 就是在幫忙做分流動作 不相關的 group 就不把packet 往那個 port 送

即然聊起來了，那我就請教一下好了。我是兩個embedded system對接。ARM的CPU跑312MHz。基本上就是一個MAC送multicast封包直接給另一個MAC。我用iperf測，UDP可在90~100Mbps不太掉包。而multicast就只能在30~50Mbps了。

我不覺得會差這麼多耶，可以解釋一下嗎?! 還是something wrong?

我不覺得會差這麼多耶，可以解釋一下嗎?! 還是something wrong?

這樣的確是差蠻多的... 如果是 A->B 的話, 你試著看看把 A 的 ethernet driver 裡面 accept multicast 的 control bit 拿掉看看有沒有比較高? ... Kernel 哪一版的? 2.6.x or 2.4.x?

Kernel是2.6.15... A本身如果沒有Join這個multicast group的話,accept multicast會有差嗎?

"理論上"沒差 但還是要試試看 以前 AN983B 某一版的就都收... 5120 跟 8668 上面的 phy 才有 fix...

哇...你把老瘡疤都拿出來說了....

初步的實驗結果是接收端的CPU不夠力。如果送的packet size是小小的但一直送,收端的CPU會被吃光而開始掉包。怎麼解?! 先加大UDP收的socket buffer size,然後再想辦法讓送的packet size一次送大一點.... 這是我目前的plan.....

喔 small packet 的問題喔... 那就頭大囉...