T********i
发帖数: 2416 | 1 我不管此人是谁。我就问你是否知道OpenOnLoad的用户多少？
我用OpenOnLoad 4年还从来没崩过。什么叫不稳定？
OpenOnLoad是hybrid，就是kernel-mode和user-mode都能用。不是pure user-mode。而
且OpenOnLoad是20m packets/s。达不到该blog号称的intel的80m packets/second。
这些都不是问题。问题是C10M即使不用OpenOnLoad，保持10M连接根本没问题。受影响
的是throughput。而且这个影响不大，顶多是一倍。
况且，Solarflare NIC顶多是2X10G的ethernet port。Intel号称的80G。
当然，和你说这些也没啥用。反正你牵狗就来喷。
呗。
of
stack |
|
S*A
发帖数: 7142 | 2 我是不了解 openonload, 没有玩过10G 的网卡。
openonload 没有提供更加底层的 API？
那就是说还有可以更加优化的地方。
如果是包接受的话，用 socket read 需要至少
memcpy 一次。网卡的数据包进来的时候不知道
是哪个socket的，所以要先收下来，然后 copy
到现成的用户 buffer。 这个不用新的 API 是没法
优化的。openonload 有更加优化的接受办法吗？
还有 openonload 应该兼容 epoll 吧？
连接数量少，epoll 不是最优，但是也差不到那里
去吧。关键是 epoll 时间不会随着和连接个数线性
增加，连接数目多了必然要用这种 API 的。
速。 |
|
S*A
发帖数: 7142 | 3 我是不了解 openonload, 没有玩过10G 的网卡。
openonload 没有提供更加底层的 API？
那就是说还有可以更加优化的地方。
如果是包接受的话，用 socket read 需要至少
memcpy 一次。网卡的数据包进来的时候不知道
是哪个socket的，所以要先收下来，然后 copy
到现成的用户 buffer。 这个不用新的 API 是没法
优化的。openonload 有更加优化的接受办法吗？
还有 openonload 应该兼容 epoll 吧？
连接数量少，epoll 不是最优，但是也差不到那里
去吧。关键是 epoll 时间不会随着和连接个数线性
增加，连接数目多了必然要用这种 API 的。
速。 |
|
T********i
发帖数: 2416 | 4 呵呵。你着什么急？
OpenOnLoad我用了4年了。每天真金白银在交易。懒得reboot机器，经常连续运行半年
多。稳定不稳定我自然心里有数。
C10M，就那个定义，10M connection，10G throughput，100M connection/s，用
OpenOnLoad足够了。就这么简单。
不是说OpenOnLoad没bug。bug一堆一堆的。发现后workaround就好了。我前几天的帖子
还提到一个我发现的bug，迄今没fix。这并代表不能24X7稳定运行。 |
|
S*A
发帖数: 7142 | 5 一个 client 不是很合适吧。
假设服务器只有一个 IP 和 一个端口，
在客户端，每个端口是 16 位，一个 IP 可以提供 65K 个连接.
也就是说，你需要客户端有至少有 10M/65K = 153 个不同的 IP 地址
（修改，原来的帖子计算错了，算成1526， 现在改过来了）
才能同时给一个服务器端口提供 10M 个连接。
linux 倒是支持在一个网卡上有那末多 ip alias。
如果50 行实现了，就说明你连 Linux epoll 都没有直接用，
那个正确实现最少要 200 行左右。如果能实现了，C10M 功
劳应该主要在是 OpenOnLoad 这类预先提供好的网络 stack 包。
那 50 行大概和 OpenOnLoad 的 demo 代码很类似。 |
|
T********i
发帖数: 2416 | 6 其实openonload之类的并不见得起决定作用。
维持住这些connection即使没有openonload也应该可以。
功劳主要在优化处理这方面。所以我看到那个号称VM 70%就知道那人的斤两了。
我曾经想如果有些现成的能用就先用着。本着这个目的和一个team沟通。开始几分钟还
好。然后那个人也讲了一个类似的cpu利用率的故事。然后就没有然后了。 |
|
T********i
发帖数: 2416 | 7 有底层API。但是限制挺多的。zero copy其实不是那么重要。
openonload能基本消除interrupt，这个提升更大。
Sandy bridge是PCI E直接读到LLC的。就这一点性能就提高好几倍了。zcp很不重要了。
openonload epoll现在优化的很好。前两年还不行。
C10M应用，要用epoll。 |
|
S*A
发帖数: 7142 | 8 这个用如果用普通的Linux，没有 OpenOnLoad 应该是做不出来的。
OpenOnLoad 的内存消耗多少不清楚，没有条件玩。
64G 内存维护 10M 连接在 kernel 的内存不够用。实验表明 2M socket
handle 就要 烧掉 8G 内存。开到10M 估计要 40G。剩下 24G
要保持连接估计是不够的。那个除了 sk_buff, tcp buffer,
还有其他的连接相关的数据结构。你一定要实验的话，可以放开
数据传输不管，测量一下是空的tcp 连接 4G 内存可以上到
多少，这个仅仅是 kernel 部分使用的内存。 所以 64G 应该没有戏。
欢迎实地测试。 |
|
S*A
发帖数: 7142 | 9 一个 client 不是很合适吧。
假设服务器只有一个 IP 和 一个端口，
在客户端，每个端口是 16 位，一个 IP 可以提供 65K 个连接.
也就是说，你需要客户端有至少有 10M/65K = 153 个不同的 IP 地址
（修改，原来的帖子计算错了，算成1526， 现在改过来了）
才能同时给一个服务器端口提供 10M 个连接。
linux 倒是支持在一个网卡上有那末多 ip alias。
如果50 行实现了，就说明你连 Linux epoll 都没有直接用，
那个正确实现最少要 200 行左右。如果能实现了，C10M 功
劳应该主要在是 OpenOnLoad 这类预先提供好的网络 stack 包。
那 50 行大概和 OpenOnLoad 的 demo 代码很类似。 |
|
T********i
发帖数: 2416 | 10 其实openonload之类的并不见得起决定作用。
维持住这些connection即使没有openonload也应该可以。
功劳主要在优化处理这方面。所以我看到那个号称VM 70%就知道那人的斤两了。
我曾经想如果有些现成的能用就先用着。本着这个目的和一个team沟通。开始几分钟还
好。然后那个人也讲了一个类似的cpu利用率的故事。然后就没有然后了。 |
|
T********i
发帖数: 2416 | 11 有底层API。但是限制挺多的。zero copy其实不是那么重要。
openonload能基本消除interrupt，这个提升更大。
Sandy bridge是PCI E直接读到LLC的。就这一点性能就提高好几倍了。zcp很不重要了。
openonload epoll现在优化的很好。前两年还不行。
C10M应用，要用epoll。 |
|
S*A
发帖数: 7142 | 12 这个用如果用普通的Linux，没有 OpenOnLoad 应该是做不出来的。
OpenOnLoad 的内存消耗多少不清楚，没有条件玩。
64G 内存维护 10M 连接在 kernel 的内存不够用。实验表明 2M socket
handle 就要 烧掉 8G 内存。开到10M 估计要 40G。剩下 24G
要保持连接估计是不够的。那个除了 sk_buff, tcp buffer,
还有其他的连接相关的数据结构。你一定要实验的话，可以放开
数据传输不管，测量一下是空的tcp 连接 4G 内存可以上到
多少，这个仅仅是 kernel 部分使用的内存。 所以 64G 应该没有戏。
欢迎实地测试。 |
|
|
T********i
发帖数: 2416 | 14 成天发贴的那帮，又不是有任务，也不是拿钱发贴的，那么激动地党同伐异为了啥？
有这功夫，好好修炼一下基本功好不好？
双CPU单机的性能，40G全双工没问题，Solarflare 7122F号称每秒2000万messages。我
用6122F每秒500万72 bytes的message，两年从来没丢过一次包。我用的是UDP包。当然
用TCP性能几乎一样，而且更靠谱。
Multicore concurrency，公开资料根本没有，知道的都不会说。
我这里可以透漏一些常识：
1. NIC的socket API是专用的，可以完全Kernel bypass，现有的使用socket IO的程序
甚至不用重编译。参见OpenOnLoad。
2. 系统的网卡不是越多越好，在最新的Sandy Bridge及以后的架构下，每个CPU挂一个
网卡最优。
3. Socket I/O用一个线程操作最优。一个线程的Socket I/O throughput是最大的。道
理是什么，自己去想。但是我可以肯定地讲，本版跳的最起劲那几个Java大牛根本没有
认清这个问题的基础知识。
4. 双CPU一共16个Core (8X... 阅读全帖 |
|
T********i
发帖数: 2416 | 15 Solarflare OpenOnLoad
Kernel by pass。 |
|
S*A
发帖数: 7142 | 16 那个 20 M OPS 估计是 UDP 盲发吧，如果是那样，
有 context 来回那种会低些。就算是 20M OPS，
用 5M TCP 带建立连接已经不够了。所以我很好奇
老老实实 TCP 建立连接可以做到多少 M。
我看了一下那个 OpenOnLoad 的演讲， 还挺有意思的。 |
|
S*A
发帖数: 7142 | 17 你现成的运行库使用 OpenOnLoad 或者 DKDP 吗？
还是直接用 Linux epoll 那样裸写？
epoll 裸写大概 200 行左右，这个我写过。 |
|
S*A
发帖数: 7142 | 18 C10M 的定义有好几个方面，不是 hold 住 10M 个连接没有神魔
流量就可以的。
这个是网上抄来的 C10M 定义：
Today (2013), $1200 will buy you a computer with 8 cores, 64 gigabytes of
RAM, 10-gbps Ethernet, and a solid state drive. Such systems should be able
to handle:
- 10 million concurrent connections
- 10 gigabits/second
- 10 million packets/second
- 10 microsecond latency
- 10 microsecond jitter
- 1 million connections/second
直接用 linux 做的网络处理上限大概在 1M packet/sec 左右。
所以没有 openonload/DPDK 包的数目就吃不消。 |
|
T********i
发帖数: 2416 | 19 看来你不了解openonload。
onload就是一个wrapper process。socket API挂钩。现有的程序不用重编译直接加速。
用不用onload你的写法可以一模一样。
其实，连接数量少，epoll不是最优的。 |
|
d*******r
发帖数: 3299 | 20 请教魏老师，那看结论就是在 Linux 上搞 openonload+epoll, 还是能上 C10M 了?
了。 |
|
d*******r
发帖数: 3299 | 21 http://www.mitbbs.com/article_t1/Programming/31331437_0_2.html
这种帖子确实让板上很受益呀！
我问个问题，我知道大家做的长连接都是针对 TCP/HTTP 应用的，因为那上面现成的应
用多。
如果自己在UDP上设计协议的话，应该就直接绕过很多问题了吧。比如client的message
/packet 都发到一个 UDP receiver 的话 (比如自己的协议里面有个 virtual sub
port number，用来复用这个 UDP receiver 的 server port number)，server上是不
是一个 UDP socket fd 就够用了，这样就不用折腾 max fd 的限制了。
不知道可不可以直接让 NIC 把 UDP 包扔给 user space app.
user space app 自己做 reliable transmission, flow/congestion control 的话 (
貌似也可以做成一个 user space modified TCP over UDP...)。这样上 C... 阅读全帖 |
|
S*A
发帖数: 7142 | 22 建议你看看 PF_RING. 类似的思路已经被搞过了。
你把发送的 TCP 搞好就有点类似 OpenOnLoad 了。
message
sub
fd |
|
S*A
发帖数: 7142 | 23 PF_RING 主要用在接受方。发送和 TCP 连接还不太行。
目前比较靠谱的是这个，至少可以看到源代码。
www.dpdk.org
OpenOnLoad 完全没有代码看，而且网卡比Intel 的贵。
Intel e1000 还是比较容易找到的。 |
|
T********i
发帖数: 2416 | 24 又是VM又是thread pool的，这个虽然连接数没有差数量级。但是最大throughput和
latency肯定要差数量级了。
这就是为什么node.js都能号称秒杀Java，而且响应更快。
估计你很快就会受到PA了。改协议和改协议栈的区别要是分不清楚，也就没啥可讨论的
了。
OpenOnLoad处理一个UDP或者IP包小于50ns。协议栈也没啥可做的了。 |
|
S*A
发帖数: 7142 | 25 你现成的运行库使用 OpenOnLoad 或者 DKDP 吗？
还是直接用 Linux epoll 那样裸写？
epoll 裸写大概 200 行左右，这个我写过。 |
|
S*A
发帖数: 7142 | 26 C10M 的定义有好几个方面，不是 hold 住 10M 个连接没有神魔
流量就可以的。
这个是网上抄来的 C10M 定义：
Today (2013), $1200 will buy you a computer with 8 cores, 64 gigabytes of
RAM, 10-gbps Ethernet, and a solid state drive. Such systems should be able
to handle:
- 10 million concurrent connections
- 10 gigabits/second
- 10 million packets/second
- 10 microsecond latency
- 10 microsecond jitter
- 1 million connections/second
直接用 linux 做的网络处理上限大概在 1M packet/sec 左右。
所以没有 openonload/DPDK 包的数目就吃不消。 |
|
T********i
发帖数: 2416 | 27 看来你不了解openonload。
onload就是一个wrapper process。socket API挂钩。现有的程序不用重编译直接加速。
用不用onload你的写法可以一模一样。
其实，连接数量少，epoll不是最优的。 |
|
d*******r
发帖数: 3299 | 28 请教魏老师，那看结论就是在 Linux 上搞 openonload+epoll, 还是能上 C10M 了?
了。 |
|
d*******r
发帖数: 3299 | 29 http://www.mitbbs.com/article_t1/Programming/31331437_0_2.html
这种帖子确实让板上很受益呀！
我问个问题，我知道大家做的长连接都是针对 TCP/HTTP 应用的，因为那上面现成的应
用多。
如果自己在UDP上设计协议的话，应该就直接绕过很多问题了吧。比如client的message
/packet 都发到一个 UDP server port 的话 (比如自己的协议里面有个 virtual sub
port number，用来复用这个 UDP server port)，server上是不是一个 UDP socket fd
就够用了，这样就不用折腾 max fd 的限制了。
不知道可不可以直接让 NIC 把 UDP 包扔给 user space app.
user space app 自己做 reliable transmission, flow/congestion control 的话 (
貌似也可以做成一个 user space modified TCP over UDP...)。这样上 C10M 是不是
也是一种思路?
... 阅读全帖 |
|
S*A
发帖数: 7142 | 30 建议你看看 PF_RING. 类似的思路已经被搞过了。
你把发送的 TCP 搞好就有点类似 OpenOnLoad 了。
message
sub
fd |
|
S*A
发帖数: 7142 | 31 PF_RING 主要用在接受方。发送和 TCP 连接还不太行。
目前比较靠谱的是这个，至少可以看到源代码。
www.dpdk.org
OpenOnLoad 完全没有代码看，而且网卡比Intel 的贵。
Intel e1000 还是比较容易找到的。 |
|
T********i
发帖数: 2416 | 32 又是VM又是thread pool的，这个虽然连接数没有差数量级。但是最大throughput和
latency肯定要差数量级了。
这就是为什么node.js都能号称秒杀Java，而且响应更快。
估计你很快就会受到PA了。改协议和改协议栈的区别要是分不清楚，也就没啥可讨论的
了。
OpenOnLoad处理一个UDP或者IP包小于50ns。协议栈也没啥可做的了。 |
|
S*A
发帖数: 7142 | 33 我懂，凡是 X 现在不存在就没意义。这个论证是错的，你自己知道
辨不过去，然后就抛出我不管。
总共就
这个 Robert 也就是先锋，探探路的。OpenOnLoad 这些是很特别的厂家
应用也没有得到开源的支持。Intel DPDK 就不一样了，代码都看得到。
里面又很多开发人员都是Linux 内核的常见 hacker。去年就又大概 8 个
thread 是关于 DPDK， 大家在改 kernel 的时候都注意不要 break 了 DPDK
的。而且 DPDK 支持不只一个种网卡。这个 DPDK 已经可以到 80G 了。
我还在琢磨做个工具自动把 kernel 的 stack port 到 DPDK 呢。
对了就对了，错了就错了，承认很难吗？你是随口说说吗， IPV8， 还贴了一大
篇引文，故意通过隐藏人家前提条件的限定语来引诱读者做错误的结论。这个
就是赤裸裸的有义误导。你贴引文的时候不会仔细看看吗？要不是我还真读
过 Robert 的东西，光看你说的误导还会真以为是那末回事了。
科学就是要严谨，一就是一，二就是二，没有什么误解。讨论起来多简单。
你要把一不严谨，就有 N 种不严谨... 阅读全帖 |
|
T********i
发帖数: 2416 | 34 你就别不要脸了。
low latency，high throughput的网络技术我也做了10来年了。还从来没崩过。无论什
么方案，指标就是throughput和latency。如果我的throughput秒你一个数量级，你做
的就是屎。
系统做的正确，连接数是100个，还是10M，throughput没有本质差别。robert那个网站
也说了，C10M的连接速度就是1m/s。openonload之类的stack用户成百上千万，这东西
都是commodity。
成天把大并发挂在嘴上，难道你不知道，并发数是10个还是10m，HA的要求是一样的？
同样的实现，人家既然性能能高你一个数量级，HA的性能自然也高你一个数量级。
这里面，唯一不能做技术的就是你。你顶多就是一搭积木的。
stack, |
|
T********i
发帖数: 2416 | 35 hohoho你又要撒泼。
Robert所说的就是Solarflare Openonload和Intel DPDK。都是commodity了。我都说了
几个月了。难道你还要再发明一把？到你那里就成了科幻外星科技了。
你还是寄希望于下次投胎智商高一点吧。 |
|
S*A
发帖数: 7142 | 36 你也好好休息吧，Robert 是做研究的，研究出来的成果，
很多已经被实现在 OpenOnLoad/DPDK 上面，你直接用就行了，
不需要自己写 custom driver/network stack。
就像你用 ngix 不需要自己写 http parser 一样。 |
|
S*A
发帖数: 7142 | 37 Sign, 我本来都想消停了。
最可笑的是，我本来是想做个实验帮你证否的老Wei 的 64G 1M
的。没想到我的实验最后做出来支持老Wei 的论断。然后我就变
成帮凶走狗了。
你想继续丢人显眼那我门就继续吧。反正你的笑点那末多。
你已经被证明了把 Robert 的文章读都读不懂，网络协议和实现都不能
分，不知道那里得出个改协议类比 IPV8 的结论。对于你读人家文章的
能力我们还能指望什么呢？
你连基本的逻辑理解能力，common sense 都没有，我还能如何说服你
呢？就剩下反复重复命题的论证法，多喊两遍，这个命题就证明了。
这个是不讲道理人用的招数。
跟你说了 OpenOnLoad/DPDK 是可以直接用的，当然说了你也不管，
因为你没有用过。我也没有，老wei 有用过，你应该听听老wei说用
这个要不要自己写 custom driver.
说什么实践是检验真理的唯一标准。
只不过实践不在你这边的时候，就不是检验标准了。
呗。
of
stack |
|
g*****g
发帖数: 34805 | 38 做人不要那么不要脸。你要提robert，又要选择性无视。Robert明明说了没有可靠的
user modde tcp/ip可用。也没听说哪个相似server产品用了OpenOnLoad，你还有脸谈
阅读能
力。
Your biggest problem is getting a user-mode TCP/IP stack. There are lots of
these stacks around as university research projects. I don’t know of any
open-source user-mode stack that is reliable. There is a closed-source stack
called “6windgate” which is used in a lot of appliances.
几个外行，成天意淫10M单机，实际上连一万单机都没做过。还是那句话，有种的跟我
说，没做过1万server并发的死全家好了。实践检验真理唯一标准，不是拿helloworld
来检验whatsapp。我产品里做过10M 用户... 阅读全帖 |
|
S*A
发帖数: 7142 | 39 不要被我呼悠了啊，我可不保证你的 server 可以上 10M 连接啊.
如果你真的要买，搞个 Intel 的网卡，可以玩 DKDP。 看上去
DKDP 比 OpenOnLoad 可玩性高。实用不一定啊。
建议还是先用的现有的机器把实验做了，把低端机器推到极致。
确定是内存限制了你的性能，然后再上高端的机器。 |
|
S*A
发帖数: 7142 | 40 不要被我呼悠了啊，我可不保证你的 server 可以上 10M 连接啊.
如果你真的要买，搞个 Intel 的网卡，可以玩 DKDP。 看上去
DKDP 比 OpenOnLoad 可玩性高。实用不一定啊。
建议还是先用的现有的机器把实验做了，把低端机器推到极致。
确定是内存限制了你的性能，然后再上高端的机器。 |
|
T********i
发帖数: 2416 | 41 TCP的设计确实够烂。几十年来一直没停的patch。
现实中人不可能不犯错误，大系统的可靠性足够让任何相关人士一直提心吊胆。
OpenOnLoad其实也是大路货。比如错误，就是connect不尊重SO_SNDTIMEO。表现就是
non-blocking connect不能timeout报错。最新版本也没解决。这些，没做过的不可能
知道。
其实，我一直都不担心C10M maintain connection的问题。我关心的是，系统
bandwidth能做到什么程度。这些，基本上和socket API无关了。但是和你的threading
model + I/O model有关。
SSA曾经问过我连接少的话，epoll即使不是最优的，性能也不会差对不对？其实，这要
结合应用去理解。我要求latency尽可能低。epoll两个选项，一个是spin，这样会占用
一个core，一个是kernel wait，这样会有context switch。我系统只有16个core呀。
这样就需要有创造性了。其实，技术离不开commen sense。
真正做C10M，其中的同步技巧，很多是conter int... 阅读全帖 |
|
b*******s
发帖数: 5216 | 42 快的自己做的居多，我们以前的老方案是openonload 加卡，不快，现在自己做，快四倍 |
|
b*******s
发帖数: 5216 | 43 看了一下mtcp,因为没有硬件支持，他们网站上那个benchmark比openonload的平均水平差 |
|
b*******s
发帖数: 5216 | 44 Openonload的测法一般是rtt,不只是发送速度，而且是各种包尺寸都测的 |
|
g****u
发帖数: 252 | 45 openonload虽然开源，但是只支持他们自己的硬件，那个硬件又卖得巨贵。我玩不起。 |
|
b*******s
发帖数: 5216 | 46 just my two cents
1) have you checked context switching of your program? how many threads are
you running? what if just keep one thread for actual sending operations?
2) have you ever tried a solarflare nic with openonload?
wdong mentioned dpdk but it is not as user friendly as solarflare nics.
3) have a tcpdump with ethernet frame info please, just in case there is
something bad happened at lower layers
4) websocket is less efficient than native tcp/ip, so just stay easy with
its performance
ch... 阅读全帖 |
|
