- PR -

1msの分解能を得る方法について

«前のページへ 1|2|3|4 次のページへ»
投稿者投稿内容
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2005-12-29 02:58
引用:

送信側で送信間隔(ここでは待機時間)をとることで、パケットを受信側に確実に送信できるのではないかと思ったからです。


出来ないと思いますが。。。
どういう見立てからそういう理論が導かれたのでしょう？
ばーど
常連さん
会議室デビュー日: 2005/08/03
投稿数: 32
投稿日時: 2005-12-29 14:03
引用:

渋木宏明(ひどり)さんの書き込み (2005-12-29 02:58) より:

出来ないと思いますが。。。
どういう見立てからそういう理論が導かれたのでしょう？



なちゃさん、渋木宏明さん、書き込みありがとうございます。

私は、いまワイヤレス環境でUDPソケットを使っています。ここで言いますのを忘れておりました。申し訳ありません。
UDPの場合、おかまいなしに下位レベルにデータを出すので、送信キューがあふれたり
受信キューがあふれたりすることによって、パケットロスが頻繁に発生してしまうらしいです。

そこで送信間隔を入れることによって、パケットロスを改善できないかと考えたからです。

また、話は戻ってしまうのですが、プログラミングの世界(開発現場など)で待機時間を得たい場合は、どのような方法をとっているのでしょうか？

[ メッセージ編集済み 編集者: ばーど 編集日時 2005-12-29 14:30 ]
MMX
ぬし
会議室デビュー日: 2001/10/26
投稿数: 861
投稿日時: 2005-12-29 15:39
入門の検索語
リアルタイム処理機能
http://www.atmarkit.co.jp/fembedded/rtos01/rtos01a.html
ー---------------
ミサイルの誘導には Windowsは使わないでしょう、結果の表示には使えるが

[ メッセージ編集済み 編集者: MMX 編集日時 2005-12-29 15:45 ]
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2005-12-29 16:58
引用:

そこで送信間隔を入れることによって、パケットロスを改善できないかと考えたからです。


出来る場合もあるし、出来ない場合もあります。

出来るか出来ないかは、通信に課せられた要件や条件によってり決まります。

データ欠損があってはならないのか、それともある程度の欠損は許容されるのか。

通信量に対して受信側の処理性能にどこまで余裕があるのか。。。などなどです。

基本的に、データ欠損が許されないのであれば送達確認が必須で、往々にして回復手順も必要です。

引用:

また、話は戻ってしまうのですが、プログラミングの世界(開発現場など)で待機時間を得たい場合は、どのような方法をとっているのでしょうか？


もちろんタイマやカウンタを使いますが、1ms の精度のタイマが必要になるというのは珍しい話だと思います。
未記入
大ベテラン
会議室デビュー日: 2005/03/12
投稿数: 148
投稿日時: 2005-12-29 21:08
実験としては面白いかもしれないね。
でもCPU負荷が高いから別の害を生み出しそう。
そのときのネットワークの状況や、相手、自分のパソコンの性能や
そのときのたまたまの負荷で変化するから役に立たないな。

いい方法が現れるのを期待してますよ。

多少のパケットロスが発生するのは通信である限り当たり前のことなので
あきらめるとして、
受信側から数秒間隔でパケットロス発生率を送信側に伝達して速度調節するとか。
てかRTCPがそうしているらしいが、RTCPはよく判らん。
あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2005-12-29 22:22
引用:

ばーどさんの書き込み (2005-12-28 17:17) より:
そこで、送信側で送信間隔(ここでは待機時間)をとることで、パケットを受信側に確実に送信できるのではないかと思ったからです。UDPではなくTCPを使用すべきだとおっしゃるかもしれませんが・・・、ためしにUDPで試作したので行っているしだいです。


すでに正解が出ていますよ。UDPではなくTCPを使えば解決します。
TCPにはパケット再送等の数十年分の研究の成果が備わっています。
それをご自分で再実装したいというのならば止めませんが。

ストリーミング系でUDPを使う場合は、サーバーは適度にウェイトを
入れつつ送信して、クライアント側で多少バッファを持たせていれば
送受信タイミングに極端な精度は要求されなくなります。

IP電話等のリアルタイムな場合はバッファできる時間が短いので
そのあたりのタイミングがかなりシビアになるはずですけど。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-12-29 23:30
引用:

ばーどさんの書き込み (2005-12-29 14:03) より:
UDPの場合、おかまいなしに下位レベルにデータを出すので、送信キューがあふれたり
受信キューがあふれたりすることによって、パケットロスが頻繁に発生してしまうらしいです。

幻想です。お構いなしに下位レイヤーにデータを渡すようなことはありません。送信キューが溢れた場合には、Send関数は通常エラーを返します。送信キューが溢れるのが問題なら、エラーが発生した時点で再送すれば良いはずです。
受信キューが溢れることは確かにあるでしょう。ですが、溢れる原因は受信側の処理能力を超える量のデータを送信して居ることにあります。根本的な解決のためには受信側PCのスペックを改善するか、そもそも設計を見直す必要があるでしょう。

引用:

そこで送信間隔を入れることによって、パケットロスを改善できないかと考えたからです。

その改善手法は進められるものではありません。受信側のスペックや通信経路の状態は予測不可能です。固定で入れたDelayなど、別の環境ではまったく意味を成さないかもしれません。

UDPを使うのであればパケットロスが発生することを前提に、パケットを失っても問題の無いプロトコルを設計するのが普通です。

もしくはパケットをロストしても、リカバリーできるように設計します。もし後者なら再発明などせずに、既存の仕組みであるTCPを使うのが最善策でしょう。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-12-30 00:10
引用:

ばーどさんの書き込み（2005-12-28 17:17）より：

そこで、送信側で送信間隔(ここでは待機時間)をとることで、パケットを受信側に確実に送信できるのではないかと思ったからです。UDPではなくTCPを使用すべきだとおっしゃるかもしれませんが・・・、ためしにUDPで試作したので行っているしだいです。

「遅延によって届ける」なら、「1msec 以上空けばよい」とも、言えるのでは？
«前のページへ 1|2|3|4 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）