ＬＡＮの速度が遅い

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

@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

@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

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

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

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

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

以上です

eagleさん

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

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

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

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

以上です

GR-KAEDE のカメラモジュール
akizukidenshi.com/.../

であれば仕様として

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

ということになってるので、320x240 のキャプチャで 20回/秒 しか出ないということはないと思います。

すみません、最後のほうの重畳の話ですが、忘れてください。
よくわかってない状態で書いてしまいました。

fujita nozomu様wrote: said:

GR-KAEDE のカメラモジュール
akizukidenshi.com/.../

であれば仕様として

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

ということになってるので、320x240 のキャプチャで 20回/秒 しか出ないということはないと思います。 引用終わり

藤田様も実は予想していることではないかと思うのですが、秋月電子さんのウェブページに記載されているのは『CMOSカメラ』の最大スペックであって、カメラモジュールとカメラアダプタとGR-KAEDEを組み合わせた時に安定動作する最大スペックを示すものではない、ということではないでしょうか。更に、ルネサスさんが提供しているArduino互換ライブラリ内で使用されている設定でもない、ということではないでしょうか。

[追記: すみません、自信が無くなって来ました→]マニュアルやソースを読んでみたのですが、GR-KAEDEで使用されている画像フォーマットはYUV:422という形式で、この場合、60fps(QVGA)でカメラからデータを出力させるにはPIXELクロックというものとして24MHzを供給する必要があるようなのですが、GR-KAEDE(確か96MHz動作でしたよね)では8MHzを供給するようになっているようです。(なお、RX64M内蔵PDCユニットの設定を変更することで12MHzや24MHzも供給することは出来るようですが、パソコンのオーバークロック設定のように動けばラッキーというようなものかも知れません。)[←ここまで]

ちなみに、150KBの画像データのキャプチャで50ms掛かるとすると3byte/us(単純に周波数換算すると3MHz)になってしまって、HSYNCとかVSYNCとかカメラからデータが出力されない期間があるということであっても、ちょっとデータ量が少ないような気もしなくもなくて、もう少しInterface誌で勉強しなくては、とも思っていたりします。

あと、ものは試しで、シェルティ様のRX64M 120MHz TCP送信の性能情報として得られた45Mbpsという値から150KBを送信するのに掛かる時間を概算してみると、(150K×8bit) / 45Mbps ≒ 27ms になります。ひとまずキャプチャ時間を 50ms とすると、キャプチャとアップロードを重畳させないのであれば、掛かる時間は 50ms + 27 ms = 77ms となります。ですので、どう頑張っても送信することが出来る画像データは、高々 1s / 77ms ≒ 13枚 ほどということになりそうです。

ですので、それ以上を求めるのであれば、少々危ないかも知れませんがPIXELクロックを上げるか、若干ソフトが複雑になりますがキャプチャとアップロードを重畳させるようにするか、かと思います。

[追記: (2017/2/24 18:42) 離れた所よりも近い所の方が良さそうなので、ここに書き加えました→]ふと気になって、仮に60fpsの速さでキャプチャ出来たらどうなるか概算してみました。キャプチャ時間は 1s / 60 ≒ 17ms ですので、キャプチャとアップロードを重畳させないのであれば、掛かる時間は 17ms + 27 ms = 44ms となります。ですので、この場合、どう頑張っても送信することが出来る画像データは、高々 1s / 44ms ≒ 23枚 ほどということになりそうです。[← ここまで]

なお、画像データ領域を2画面分確保出来るのであれば、あくまで私の直感でしかないですが、10行に満たない改造で済むような気がします。なぜなら、今回、画像データのキャプチャはPDCユニットのキャプチャスタートビッﾄをセットしてしまえば後は特に何もすることは無いので、キャプチャスタートビットをセットした後、1つ前にキャプチャした画像データ領域へのポインタを引数にしてclient.write関数を呼び出すだけで良いと思われるからです。そして、client.write関数から戻って来たら、キャプチャ完了フラグが立つのを待ち、フラグが立ったら画像データ領域へのポインタを交換して、同じことを繰り返すようにして行けば良いような気がするからです。

[追記: (2017/2/24 18:42) ここから→]すみません、正直なところ直感頼りでしかなくて、マニュアルを読んで感触を得た上でのことではないです。それで、よくよく考えてみると、キャプチャスタートさせた後に、何かしらカメラにデータ出力を開始させる指示をしないといけないような気がします。それともカメラからは、カメラの初期設定完了以後ずっと、データが垂れ流し状態になっていたりするものなのだろうか？[← ここまで]
[追記: (2017/2/25 20:17) ここから→]データが垂れ流しになるのであれば、1フレームのデータの途中でキャプチャスタートさせてしまうとフレームの区切りが来るまで(つまり次の1フレームの最初のデータが来るまで)のデータは読み捨てられてフレームレート低下の要因になるような気がしたのですが、以前の投稿に書いたInterface誌の特集の別の記事(別のマイコン/別のカメラ)を読んでいたところ、実際にそういうものであることが分かりました(同誌 39P 表1)。ですので、処理時間をきちんと把握した上でコーディングすることも重要なようです。(更に、下の段落の話はちょっと怪しい気もして来ました、、、)[← ここまで]

[追記: (2017/2/25 2:25) ここから→]RX64Mグループ ユーザーズマニュアル ハードウェア編 2.8.1 命令とサイクル数 を参照しながら150KBのデータをSMOVF命令でコピーする時間を計算したところ 1.2ms(＠98MHz) でコピー出来ることが分かりました。ですので、2つ上の段落で書いた画像データ領域のポインタを交換、という方法でなくても、キャプチャした画像データ領域の内容をSMOVF命令で力任せにもうひとつの画像データ領域にコピーして、そちらの内容をclient.write関数でサーバーにアップロードするという方法でも、まずまずの効果が期待出来そうな気がします。[← ここまで]

カメラのクロックは、データシートをみると

www.dragonwake.com/.../OV7740_CSP.pdf
> input clock frequency: 6 ~ 27 MHz

> maximum image transfer rate:
> 　VGA (640x480): 60 fps for VGA
> 　QVGA (320x240): 120 fps for QVGA

とあり、RX64M の PCKO 出力は仕様上 PCKDIV で PCLKB の 2分周も設定可能なので 24MHz 動作も可能ということで、製品のスペック上限に近い使い方はできそうな感じですね。
GR-KAEDE のライブラリ で PCKDIV に 6分周を使用してる理由はわかりませんが。