- 论坛徽章:
- 0
|
原帖由 zjzf_1 于 2006-3-9 14:31 发表
1、
"上次有个千兆转发40万包的讨论,我没有千兆卡,只能测Intel百兆的82559芯片,但我想不会有人比我的性能更高了"
如果单纯的包转发 你这套东西绝对不够我80元买的 6口交换机快 你要是做防火墙或者抗 ...
现在回这个最长的贴子,呼呼....
1、
"上次有个千兆转发40万包的讨论,我没有千兆卡,只能测Intel百兆的82559芯片,但我想不会有人比我的性能更高了"如果单纯的包转发 你这套东西绝对不够我80元买的 6口交换机快 你要是做防火墙或者抗拒绝服务设备的话应该在实现你的基本功能后 再拿包转发能力来说事
答:上次的贴子就是说的转发,没什么前提,没说是路由还是桥,也没说网卡类型与芯片,我的贴子就是和82559芯片的性能叫板,你叫我和交换机比什么呀,那我可不可以说,你80元买的6口交换器还没有我3元买的网线快呢.你如果有百兆下的优良吐吞可以show一下,也好叫我知道我的转发还可以提高,说的再明白一点,我了解了多核和NP后想再回到X86上做点成绩.
2、
"现在这个桥，TCP/IP协议栈其实被跳过去了"
etherbridge 本来TCP/IP就应该被跳过去的。bsd linux 相信也不会把local以外包交给ip_input
如果是跳过系统提供的etherbridge 实现一个 规定nic到规定nic的bridge 的确是非常简单的一件事情 因为我自己也做了一个这样的东西 如果考虑多nic 比较要考虑 以太网广播 和 以太网路由的问题 最起码 还要多一个
MAC TABLE 记录 MAC 对应的nic
答:是啊,很容易啊,说起来是很容易啊,给我看一下你的性能啊.硬件上如果有bypass功能,我还知道可以到线速呢,你以为62M的吐吞是这么一件容易的事吗?看看我在3com上测的记录吧.
RFC 2544 Throughput Test - Per Port Binary Search - IP --> Framesize: 64
TX RX TxTput(fps) %TxTput
*************************************************
1.1.2 1.1.1 27174 18.26
*************************************************
AvgRate(fps) = 27174
Tolerance(%) = 0
RFC 2544 Throughput Test - Per Port Binary Search - IP --> Framesize: 64
TX RX TxTput(fps) %TxTput
*************************************************
1.1.1 1.1.2 29240 19.65
*************************************************
AvgRate(fps) = 29240
Tolerance(%) = 0
RFC 2544 Throughput Test - Per Port Binary Search - IP --> Framesize: 64
TX RX TxTput(fps) %TxTput
*************************************************
1.1.1 1.1.2 5844 3.93
1.1.2 1.1.1 5862 3.94
*************************************************
AvgRate(fps) = 5853
Tolerance(%) = 0
还想不想看对e100.c各版驱动的测试记录?3Com的驱动程序写的就是差...
3、
"正在考虑，目前有两种解决方法
1)需要radij之类的数据结构以提高性能
2)用cookie的方法，比如一个ping包从内网出去时，我们记下他的cookie值，利用cookie来判断回来的是否合法。记五元组状态占内存太大，这个方法是可行的，我试过。但大负载下没测过。这个算法还要避开cookie攻击。也算是另类的一种conntrack吧 "
"syncookie 的效率就是很低的，尤其是大负载的时候
虽然我不知道他的算法，但是我想如果不用 netfilter 的 conntrack 的话，应该避免出现 syncookie 的错误才对，否则效率上不去"
两个人说的两码事"platinum "如果你对syncookies不了解的话 请记住别人说"ping"的时候你要明白他说的是ICMP syncookies 是用来解决 syn flood 一类tcp攻击的
而且linux和bsd 实现的syncookies效率低 但是我觉得syncookies在某种情况下是解决synflood的最佳办法 而且我实现的synproxy 可以解决针对游戏服务器400M左右的synflood 如果结合上层的filter可以将400m这个数字提升很多
答:版主没有说错,cookies的应用有很多,你的IE里也有cookie.可能你做了个产品,冲晕头了.最佳是cookie?你说的?BAM技术了解吗?400M,你也要告诉我硬件环境啊.12核,每核1G,64字节吞吐550M,至少要像我这么给描述一下吧?synflood都400M了,说明synflood就己经是千兆的瓶颈了,再结合上层的filter反而提升很多?矛盾不?
3、
"我期待的结果是比hash表快三倍" 什么样一个hash ???
hash的size <10 ? 还是一一对应hash ??
我用的hash 保存连接状态 我们也尝试 树型结构 (b+ avl redblack ) 在内存充足的情况下 hash 的整体性能要优于任何的tree
答:size < 10,大哥,你纯就是叫板来了,如果没改过内核,hash入口是内存的16K分之一(conntrack表),内存充足时hash的整体性能就要优于任何tree?大哥,做过测试吗?为什么hash要有冲突表?你要有专本的hash硬件芯片,才可以说这句话,另外TCP/IP卷二长篇的radij树介召就是在放屁吗?看看那章作者的总结.
4、
"百兆网卡的王者我想应该是Intel82559芯片，82550gy芯片虽是该系统中最好的，但核心层和82559一样，所以转发性能是一样的。"
这句话只是怀疑 我也没验证过 因为我的也没有测试过所有型号的100m网卡 550较559多了IPsec的硬件支持 不知道你有没有听说过intel 82562 是跑LCI 的 我最近用过一款msi 915GM 用的是 82562 因为我的freebsd4.11对这种总线还不支持 所以我也没搞 顺便说一下CSA总线试过没有 的确强很多 不过好像没有100m的产品
答:不好意思,82562我在Intel的百兆系列中没有见过,中关村也只是见过82550ey.王者的定义其中还包括价格与产量,解疑一下:Intel第一代网卡82597,主芯片核心的代号定为D100，物理层芯片代号为Phy-Tx.以后虽然出过很多类型,但核心都是D100.纵观intel百兆网络芯片的发展，所有网络芯片都采用了D100内核（在proset的诊断信息里可以看到），也就是说，intel各个版本网卡的网络传输性能变化不大，但是功能越来越多，发热量越来越小，越来越稳定，也就是说整体性能在提高。
购买推荐：82550gy>82550ey>82559>pro100 ve>82558>82557 如果是服务器版的就再升一级,比如如果有82559server,就不考虑82550ey了.
5、
对zhangjiakouzf 的问题
我来回答一下 "Linux 网络转发的SMP 扩展性不好,主要原因在于同步引入的开销太大"(引用<<Linux 的网络转发性能研究>>西安交通大学学报作者:郑卫斌等)
按我个人的测试 POLLING(linux叫NAPI)会对小包转发提升明显 但是bsd的polling不支持SMP 据<<Linux 的网络转发性能研究>> linux开了SMP的NAPI性能还会下降 <<Linux 的网络转发性能研究>>提出了SMP NAPI改进方法(效果不明显)
答:这本书,以前好像只是一份学报,页眉好像还是同方的logo?看过.但不认为写得很好.这东西只有实验了才知道. |
|
免费注册
楼主: skipjack
发表于 2006-03-09 22:42
