高手的经验：Linux网络通信程序中，最快的数据发送和接收速度能达到的多少？

it-rocket

因为最近在linux下调试A/D以100ksps采样率进行采样并将数据通过socket或者RPC两种不同的通信程序发送到windows客户端时，发觉采样出来的数据网络传输得很慢，导致板子上开辟的缓冲区溢出，数据丢失。但又不知道该怎样极大地提高网络速度才能更好地将数据传输过来。请大家提提意见。
每秒100k的采样率，其数据量有： 100k*4=400kByte=3.2Mbps

开发板的网卡速率为10M/100Mbps。
该程序只能使用TCP来传输。

   此外想请教大家通过setsockopt等设置socket之后，能达到的最快的数据发送、接收速率能达到多少？是怎么做到的？非常感谢。

ShadowStar

建议你将数据合并发送。

按照你的说法，100k×4＝400KByte。也就是说，每个采样只有4Byte。
也就是说，如果每个采样都发送一次报文的话，也就是需要100Kpps的发送速度。

一般的开发板子的处理器很难达到这个速度。

it-rocket

建议你将数据合并发送。

按照你的说法，100k×4＝400KByte。也就是说，每个采样只有4Byte。
也就是说， ...
ShadowStar 发表于 2010-06-03 17:02

    ShadowStar 理解错我的意思了。1秒钟能采样出100000即100k个点，每个点占4个字节大小，我在RPC机制下发送时，可以选择每次发送1024个或者4096个,异或8192个数据这几个不同的值。但是仍然出现板上缓冲区不断堆积数据，最后溢出。TCP socket程序的情况也差不多。所以我认为要提高网络传输速度，但不知道该如何入手。

ShadowStar

如您所述，我认为现象有点不太正常。

我建议您查看一下CPU负载，是不是100%了？
如果是的话，是不是都被采样程序占用了？

3.2Mbps的流量还是不大的，如果只有几个报文的话。

it-rocket

如您所述，我认为现象有点不太正常。

我建议您查看一下CPU负载，是不是100%了？
如果是的话，是不是都被 ...
ShadowStar 发表于 2010-06-03 19:34

    ShadowStar 不愧是Star啊！呵呵 非常感谢。
您的推测真的非常的到位，虽然该程序所占的CPU没有完全达到100%，但是该程序所构成的5个线程的CPU之和高达98%。其中
T1(应该是我的采集线程，优先级最高)为89.7%；
T2（怀疑是我的处理数据线程）占8.2%，
T3占了0.1%，
T4占了0.0%，
T5占了0.1%。
其中top命令占了1.7%。总的CPU几乎有99。
此外五个线程占得内存比例均为27.4%。

其实在我的程序中，我只开了3个线程(采集、数据处理、准备发送数据到发送缓冲区)，此外还有main线程，多出了的一个线程，我也不太清楚是怎么回事。采集线程只是按时准确地去采集获得一组数据，所以里边有一个usleep的休眠，有20.48ms（这个时间不精确，我也有些头疼），采集出来的数据放入FIFO1中，就不干其他活儿了。数据处理线程将FIFO1中的数据转换且经过数据处理后放入FIFO2中，用于发送。准备发送数据到发送缓冲区线程将数据填入发送缓冲区待发送，main线程完成数据发送的功能，这是RPC机制决定的。

据您这么一说，似乎我把采集线程的CPU使用量降下来就能有所改进？ 您能给我一些建议吗？采集线程很关键，不能够因为别的线程占用CPU的处理，而忽略采集，不然采集出来的数据可能会数据量不够或者造成硬件缓冲区满等严重问题。Thanks！

ShadowStar

不好意思，我是做内核开发的，对于应用层开发不是很熟。

不过如果你的需求放在内核态来做的话，应该说是很容易的。

it-rocket

回复 6# ShadowStar


    呵呵，没有关系的，你已经给了我很大的提示了，明天回公司改改采集线程的休眠时间，让它多让出些CPU的时间，估计效果会有所提高。CPU被占用了绝大部分，应该会影响到数据发送等操作的其他线程，我估计这里会是我的突破口！ 呵呵

放在内核态来做，你能谈谈思路吗？如果需要的话，我看是否需要改进这个东西，主要是自己对内核没有深入去研究过，呵呵 感激不尽！
我的需求很简单： 采集板卡的数据--->进行一些滤波等数据处理--->将数据一个都不能丢地网络传送到Windows系统的客户端。

ShadowStar

在内核态处理的大体流程就是，用一个定时器定时采集数据，然后封包丢出去，over。

当然，我说的是比较简单的流程，根据实际需求，可能还需要做一些队列等处理。

it-rocket

回复 8# ShadowStar


    恩，非常感谢。我还需要继续学习，对这内核态的操作不是很熟悉，呵呵！

据其他高手的分析，这个问题有两种：
第一种：
hzcpig:
“
采样线程中，usleep级别下的while(1) cpu占用是很恐怖的，不能改近下采集方式，通过select,poll之类比较友善的方式么。

如果采集数据的时间不确定，最好的方式不是去实时轮询，最好是在数据处设中断或回调，主动通知。”

我的问题：
   其实硬件提供了两个中断INT1和INT2，其中INT2用于告知FIFO硬件存储器半满，在中断程序中就可以取数。INT1用于其它按键中断，我在驱动中用kill_async发送SIGIO异步信号通知给我的APP，在APP中对按键用信号处理函数对SIGIO信号做了相应的处理。而对这个INT2半满中断，我在驱动中却没有利用，而用了上面的延时等待取数的方式，所以影响了整个程序的效率。

    由于我对这个异步信号通知不是很熟悉，是否我也应像处理INT1的那种信号通知APP的处理方式？发送给APP的信号为SIGURG或者说SIGUSR1等，会有问题吗？非常感谢。

第二种：
yanjinbin0
“
先停掉其他进程,用测试数据通过socket发送,看其是否支持3.2Mbps/s的速率发送.
如果行在慢慢优化,如果这样都行,那你的考虑压缩传输了.”

“建议先做下这个验证,因为这个验证顶多只要一天时间就完了,否则光靠想象,左改右改下,或许某些偶然的场合会解决问题,但大部分还是要回到原来的步骤,一个步骤一个步骤来验证.最好确定问题在来.”

  但是 由于目前时间比较急，我还没有进行验证，虽然我程序是RPC通信程序。

aaaaa5aa

好聪明，放在内核态来做的提法真的不错，等下验证