高手的經(jīng)驗(yàn)：Linux網(wǎng)絡(luò)通信程序中，最快的數(shù)據(jù)發(fā)送和接收速度能達(dá)到的多少？

it-rocket

因?yàn)樽罱�在linux下調(diào)試A/D以100ksps采樣率進(jìn)行采樣并將數(shù)據(jù)通過socket或者RPC兩種不同的通信程序發(fā)送到windows客戶端時(shí)，發(fā)覺采樣出來的數(shù)據(jù)網(wǎng)絡(luò)傳輸?shù)煤苈�，�?dǎo)致板子上開辟的緩沖區(qū)溢出，數(shù)據(jù)丟失。但又不知道該怎樣極大地提高網(wǎng)絡(luò)速度才能更好地將數(shù)據(jù)傳輸過來。請大家提提意見。
每秒100k的采樣率，其數(shù)據(jù)量有： 100k*4=400kByte=3.2Mbps

開發(fā)板的網(wǎng)卡速率為10M/100Mbps。
該程序只能使用TCP來傳輸。

   此外想請教大家通過setsockopt等設(shè)置socket之后，能達(dá)到的最快的數(shù)據(jù)發(fā)送、接收速率能達(dá)到多少？是怎么做到的？非常感謝。

ShadowStar

建議你將數(shù)據(jù)合并發(fā)送。

按照你的說法，100k×4＝400KByte。也就是說，每個(gè)采樣只有4Byte。
也就是說，如果每個(gè)采樣都發(fā)送一次報(bào)文的話，也就是需要100Kpps的發(fā)送速度。

一般的開發(fā)板子的處理器很難達(dá)到這個(gè)速度。

it-rocket

建議你將數(shù)據(jù)合并發(fā)送。

按照你的說法，100k×4＝400KByte。也就是說，每個(gè)采樣只有4Byte。
也就是說， ...
ShadowStar 發(fā)表于 2010-06-03 17:02

    ShadowStar 理解錯(cuò)我的意思了。1秒鐘能采樣出100000即100k個(gè)點(diǎn)，每個(gè)點(diǎn)占4個(gè)字節(jié)大小，我在RPC機(jī)制下發(fā)送時(shí)，可以選擇每次發(fā)送1024個(gè)或者4096個(gè),異或8192個(gè)數(shù)據(jù)這幾個(gè)不同的值。但是仍然出現(xiàn)板上緩沖區(qū)不斷堆積數(shù)據(jù)，最后溢出。TCP socket程序的情況也差不多。所以我認(rèn)為要提高網(wǎng)絡(luò)傳輸速度，但不知道該如何入手。

ShadowStar

如您所述，我認(rèn)為現(xiàn)象有點(diǎn)不太正常。

我建議您查看一下CPU負(fù)載，是不是100%了？
如果是的話，是不是都被采樣程序占用了？

3.2Mbps的流量還是不大的，如果只有幾個(gè)報(bào)文的話。

it-rocket

如您所述，我認(rèn)為現(xiàn)象有點(diǎn)不太正常。

我建議您查看一下CPU負(fù)載，是不是100%了？
如果是的話，是不是都被 ...
ShadowStar 發(fā)表于 2010-06-03 19:34

    ShadowStar 不愧是Star�。『呛� 非常感謝。
您的推測真的非常的到位，雖然該程序所占的CPU沒有完全達(dá)到100%，但是該程序所構(gòu)成的5個(gè)線程的CPU之和高達(dá)98%。其中
T1(應(yīng)該是我的采集線程，優(yōu)先級最高)為89.7%；
T2（懷疑是我的處理數(shù)據(jù)線程）占8.2%，
T3占了0.1%，
T4占了0.0%，
T5占了0.1%。
其中top命令占了1.7%。總的CPU幾乎有99。
此外五個(gè)線程占得內(nèi)存比例均為27.4%。

其實(shí)在我的程序中，我只開了3個(gè)線程(采集、數(shù)據(jù)處理、準(zhǔn)備發(fā)送數(shù)據(jù)到發(fā)送緩沖區(qū))，此外還有main線程，多出了的一個(gè)線程，我也不太清楚是怎么回事。采集線程只是按時(shí)準(zhǔn)確地去采集獲得一組數(shù)據(jù)，所以里邊有一個(gè)usleep的休眠，有20.48ms（這個(gè)時(shí)間不精確，我也有些頭疼），采集出來的數(shù)據(jù)放入FIFO1中，就不干其他活兒了。數(shù)據(jù)處理線程將FIFO1中的數(shù)據(jù)轉(zhuǎn)換且經(jīng)過數(shù)據(jù)處理后放入FIFO2中，用于發(fā)送。準(zhǔn)備發(fā)送數(shù)據(jù)到發(fā)送緩沖區(qū)線程將數(shù)據(jù)填入發(fā)送緩沖區(qū)待發(fā)送，main線程完成數(shù)據(jù)發(fā)送的功能，這是RPC機(jī)制決定的。

據(jù)您這么一說，似乎我把采集線程的CPU使用量降下來就能有所改進(jìn)？ 您能給我一些建議嗎？采集線程很關(guān)鍵，不能夠因?yàn)閯e的線程占用CPU的處理，而忽略采集，不然采集出來的數(shù)據(jù)可能會(huì)數(shù)據(jù)量不夠或者造成硬件緩沖區(qū)滿等嚴(yán)重問題。Thanks！

ShadowStar

不好意思，我是做內(nèi)核開發(fā)的，對于應(yīng)用層開發(fā)不是很熟。

不過如果你的需求放在內(nèi)核態(tài)來做的話，應(yīng)該說是很容易的。

it-rocket

回復(fù) 6# ShadowStar


    呵呵，沒有關(guān)系的，你已經(jīng)給了我很大的提示了，明天回公司改改采集線程的休眠時(shí)間，讓它多讓出些CPU的時(shí)間，估計(jì)效果會(huì)有所提高。CPU被占用了絕大部分，應(yīng)該會(huì)影響到數(shù)據(jù)發(fā)送等操作的其他線程，我估計(jì)這里會(huì)是我的突破口！ 呵呵

放在內(nèi)核態(tài)來做，你能談?wù)勊悸穯�？如果需要的話，我看是否需要改進(jìn)這個(gè)東西，主要是自己對內(nèi)核沒有深入去研究過，呵呵 感激不盡！
我的需求很簡單： 采集板卡的數(shù)據(jù)--->進(jìn)行一些濾波等數(shù)據(jù)處理--->將數(shù)據(jù)一個(gè)都不能丟地網(wǎng)絡(luò)傳送到Windows系統(tǒng)的客戶端。

ShadowStar

在內(nèi)核態(tài)處理的大體流程就是，用一個(gè)定時(shí)器定時(shí)采集數(shù)據(jù)，然后封包丟出去，over。

當(dāng)然，我說的是比較簡單的流程，根據(jù)實(shí)際需求，可能還需要做一些隊(duì)列等處理。

it-rocket

回復(fù) 8# ShadowStar


    恩，非常感謝。我還需要繼續(xù)學(xué)習(xí)，對這內(nèi)核態(tài)的操作不是很熟悉，呵呵！

據(jù)其他高手的分析，這個(gè)問題有兩種：
第一種：
hzcpig:
“
采樣線程中，usleep級別下的while(1) cpu占用是很恐怖的，不能改近下采集方式，通過select,poll之類比較友善的方式么。

如果采集數(shù)據(jù)的時(shí)間不確定，最好的方式不是去實(shí)時(shí)輪詢，最好是在數(shù)據(jù)處設(shè)中斷或回調(diào)，主動(dòng)通知�！�

我的問題：
   其實(shí)硬件提供了兩個(gè)中斷INT1和INT2，其中INT2用于告知FIFO硬件存儲(chǔ)器半滿，在中斷程序中就可以取數(shù)。INT1用于其它按鍵中斷，我在驅(qū)動(dòng)中用kill_async發(fā)送SIGIO異步信號(hào)通知給我的APP，在APP中對按鍵用信號(hào)處理函數(shù)對SIGIO信號(hào)做了相應(yīng)的處理。而對這個(gè)INT2半滿中斷，我在驅(qū)動(dòng)中卻沒有利用，而用了上面的延時(shí)等待取數(shù)的方式，所以影響了整個(gè)程序的效率。

    由于我對這個(gè)異步信號(hào)通知不是很熟悉，是否我也應(yīng)像處理INT1的那種信號(hào)通知APP的處理方式？發(fā)送給APP的信號(hào)為SIGURG或者說SIGUSR1等，會(huì)有問題嗎？非常感謝。

第二種：
yanjinbin0
“
先停掉其他進(jìn)程,用測試數(shù)據(jù)通過socket發(fā)送,看其是否支持3.2Mbps/s的速率發(fā)送.
如果行在慢慢優(yōu)化,如果這樣都行,那你的考慮壓縮傳輸了.”

“建議先做下這個(gè)驗(yàn)證,因?yàn)檫@個(gè)驗(yàn)證頂多只要一天時(shí)間就完了,否則光靠想象,左改右改下,或許某些偶然的場合會(huì)解決問題,但大部分還是要回到原來的步驟,一個(gè)步驟一個(gè)步驟來驗(yàn)證.最好確定問題在來.”

  但是 由于目前時(shí)間比較急，我還沒有進(jìn)行驗(yàn)證，雖然我程序是RPC通信程序。

aaaaa5aa

好聰明，放在內(nèi)核態(tài)來做的提法真的不錯(cuò)，等下驗(yàn)證