• Replies 21 replies
  • Subscribers 458 subscribers
  • Views 13025 views
  • Users 0 members are here
Options
Related

ＬＡＮの速度が遅い

eagle

ＲＭ６４でＫＡＥＤＥのライブラリーを使用して、Ｅｔｈｅｒｎｅｔサーバを作っています。（ＴＣＰ／ＩＰ）

サーバーから画像データ（１５０ＫＢ）を送るのですが、１秒間に１０数回しか送れません。

２０から３０回ぐらい送りたいのですが、何か方法はないでしょうか？

下記のように送っています。

１．接続確認

    client = server.available();
    if (client) {   //

２．送信

     client.write((uint8_t*)&m_respHead,sizeof(m_respHead));

Parents Reply Children
  • in reply to @chobichan

    @chobichan様 wrote: said:
    仮に1秒間に10回送信したとして、150kByte×10×8(bit)だと12Mbpsですね。遅いですか？
    これを3倍にすると36Mbpsですが、100M Ethernetで出せる数字でしょうか？ 引用終わり

    以前、シェルティ様の投稿で『RX62N@100MHz では30Mbps程度確認』というのを見掛けたことがあります。ですので、出せない数字では無い様な気がします。RX62Nなので100M Ethernetだと思います。(個人的には、シェルティ様のEthernetに関する投稿は『シェルティ様』というタグで検索出来るようになっていて欲しいぐらいです。) (ひょっとして、投稿者名での検索が出来たりするかな、、、)

    http://japan.renesasrulz.com/cafe_rene/f/forum15/2089/uip-tcp-ip/8941#8941

  • in reply to NoMaY
    ああ、RX62Nでは30Mbps出せているんですか？しかしどうやって出せたとか、試験環境とかさっぱり判らずですね。
    他にもネットワーク機器が存在していた場合、一つの機器が30％も帯域を占有する事を期待できるのだろうか？1対1で接続？
    本当にボトルネックはプロトコル？

    スレ主さんはTCPでやったのか？UDPでやったのか？どっちなのでしょう？
    TCPでやった場合、転送速度はベストエフォートじゃないでしょうか？相手先が有る事だし。

    リンク先には遅延ACKの事が書かれていますが、遅延ACKの定義って何かありましたっけ？2回パケットを受信したらACKを送信しなければならないとか？
  • in reply to @chobichan

    そういうことを、出来れば時々シェルティ様にも意見を伺いながら、これから技術的に客観的に冷静に(たまに間違えたり勘違いしたりしながら)情報交換していって落とし所を見付ければ良いのでしょうね。

    @chobichan様wrote: said:
    ああ、RX62Nでは30Mbps出せているんですか？しかしどうやって出せたとか、試験環境とかさっぱり判らずですね。
    他にもネットワーク機器が存在していた場合、一つの機器が30％も帯域を占有する事を期待できるのだろうか？1対1で接続？
    本当にボトルネックはプロトコル？

    スレ主さんはTCPでやったのか？UDPでやったのか？どっちなのでしょう？
    TCPでやった場合、転送速度はベストエフォートじゃないでしょうか？相手先が有る事だし。

    リンク先には遅延ACKの事が書かれていますが、遅延ACKの定義って何かありましたっけ？2回パケットを受信したらACKを送信しなければならないとか？ 引用終わり
  • in reply to @chobichan
    ありがとうございます。ちょっと何とも言えないところですね。。。
  • in reply to NoMaY
    NoMaYさん、参考になる投稿を教えていただきありがとうございました。
  • in reply to eagle

    eagleさん、こんにちは。

    150KBの画像データということはQVGA(320×240) RGB565といったところでしょうか？ これをRAWデータで(つまりブラウザで見られるようにする為にわざわざJPEGエンコードするなどということはせずに)どんどんサーバーにアップロードするシステムを開発されているところですか？

    何かヒントになる情報はないものかと思い、CQ出版社のInterface誌2014年11月号に掲載されていた、GR-KAEDEで同じ画像サイズでネットワークカメラを実装した人のチューニング記事を読み直していたところ、処理時間を示すオシロの画面コピー(同誌104P 図9)で画像キャプチャ時間が(RX64M内蔵PDCユニットを使っていても)50msになっていることに気付きました。ひょっとすると、ネットワーク周りをどう頑張ってみてもアップロード性能は20回/秒が限界かも知れません。また、この20回/秒という数値も、画像データのキャプチャとサーバーへのアップロードを同時に行うような仕組み(例えば、画像データ領域を2画面分確保してキャプチャとアップロードを交互に同時に行うとか、キャプチャの進行状況を監視しながらキャプチャ済みになった部分から随時アップロードするとか)にして、ようやく実現出来る性能というところかも知れません。

    そのことを踏まえつつネットワーク周りに話を戻すと、キャプチャ済みの同じ画像データをひたすら繰り返しサーバーにアップロードするようなことをしたら、どれくらいの回数アップロード出来るか確認してみてはどうでしょうか？ これで20回/秒を超えることが出来ていれば、(楽観主義な私の目から見ると)まずまず悪くない状況のような気がします、、、

    参考リンク

    CQ出版社 Intarface誌 2014年11月号 目次
    特集
    徹底研究！指先サイズ スーパーカメラ
    http://www.kumikomi.net/interface/contents/201411.php

    第9章
    27MHz画像キャプチャOKのカメラ向きワンチップでJPEG圧縮も
    512KバイトRAM内蔵！最新RX64Mで最小ネットワーク・カメラ
    記事見本(記事の最初の頁のみ)
    http://www.kumikomi.net/interface/sample/201411/if11_097.pdf

    なお、同記事では、GR-KAEDEをウェブサーバーにしてブラウザから見られるようにする為にJPEGエンコードを行っていて、この処理がボトルネックになって5回/秒のフレームレートになっているようです。(ちなみに、記事中(同誌98P)には、JPEGエンコードせずにRAWデータのままなら15回/秒以上のフレームレートも可能、と読み取れる文面もありました、、、)

  • in reply to NoMaY
    eagleさん

    こんにちは、シェルティです。

    RX64Mですね。150KBを10枚/秒であれば、@chobichanさんが
    仰る通り12Mbpsということでソコソコの速度と思います。
    NoMaYさんが参照されているInterface誌2014年11月号を読んでみたのですが
    たしかに、QVGAの画像データの転送に50msかかっているので、
    ネットワーク転送しなくても1秒間に20枚が限界となりますね。

    私が最近測定したEther性能情報(転送速度Mbps(CPU負荷率%))を
    書き出してみます。参考になりましたら幸いです。

    TCP送 TCP受 UDP送 UDP受
    RX71M@240MHz 53(18) 71(27) 72(15) --(--)
    RX65N@120MHz 46(28) 65(54) 60(27) --(--)
    RX64M@120MHz 45(28) 66(47) 62(25) --(--)
    RX63N@96MHz 40(36) 65(62) 54(33) --(--)

    ()外は転送速度(Mbps)
    ()内はCPU負荷率(%)
    データ転送元、データ転送先共に内蔵RAM

    測定方法は、マイコンボードとパソコンをハブ経由で接続し、
    マイコン上、および、パソコン上で性能測定用のアプリを起動し通信、
    10回測定した平均値を記載、としています。
    CPU負荷率はEther関連の割り込みハンドラ(timer_interrupt()とlan_inthdr())の
    入口・出口で汎用ポートを"H"/"L"させて、その比率をCPU負荷率としています。
    UDP受信はうまく測れてません。

    マイコン側のソフトは以下を使用しております。

    r_bsp 3.40
    r_cmt_rx 3.00
    r_ether_rx 1.12
    r_sys_time_rx 1.00
    r_t4_driver_rx 1.06
    r_t4_rx 2.06

    以上です
  • in reply to シェルティ
    eagleさん

    こんにちは、シェルティです。

    Arduinoラッパー層の上からできるかは試したことないので確証がないですが、
    送信API呼び出し後にTCP/IPのプロセス関数の_process_tcpip()を続けて呼んでみてはどうでしょうか。
    このソフトはAPI呼び出しを10msタイマ周期起動でキャッチしており、
    API呼び出しタイミングにより最大10msの待ち時間が発生するのでこれが全体のパフォーマンスに
    影響しているのではないかと思います。

    あとはeagleさんの環境でオシロを使ってカメラの転送処理の時間、ネットワークの送信時間を
    マッピングしていってボトルネックの割り出し、またはCPUが遊んでいる時間を割り出すと
    良いと思います。いよいよもってボトルネックも遊んでいる時間もない場合は、
    それがシステムの限界ですね。

    あとなんとなくですが、カメラからの転送で50ms待ちしている時間に
    1個前のデータを送るなどとして、カメラと通信の処理を重畳させれば
    限界の20枚/秒に近づく可能性があるのでは、と思います。

    以上です
  • in reply to NoMaY
    GR-KAEDE のカメラモジュール
    akizukidenshi.com/.../

    であれば仕様として

    > ・画像サイズ：ＶＧＡ（６４０ｘ４８０）／ＱＶＧＡ（３２０ｘ２４０）
    > ・フレームレート：最大３０ｆｐｓ（ＶＧＡ）／最大６０ｆｐｓ（ＱＶＧＡ

    ということになってるので、320x240 のキャプチャで 20回/秒 しか出ないということはないと思います。
  • in reply to シェルティ
    すみません、最後のほうの重畳の話ですが、忘れてください。
    よくわかってない状態で書いてしまいました。