アカウント名:
パスワード:
バルクな帯域性能がガッツリ上がって5Gbpsまでイケるようになったのは他のニュースなんかでも取り上げられてるけど、リアルタイム方面はどーなってるんでしょうか。
そもそも汎用バスにリアルタイム機器を繋ぐのが間違ってるのは承知ながら、実際USB接続の機器（具体的にはオーディオ入出力機器）があるので。2.0でマイクロフレームが導入されてかなりマシになったところまでは把握してるんですが、3.0でどうなったかなと。
Isochronous転送は継続的に一定レートのデータを流すことを目的にしているので，不定期に（突発的に）発生したデータを一定以下の遅延で伝送したいというリアルタイムアプリケーションの要求とはまた違うのかもしれませんね．帯域，ジッタ，遅延，どの人つまたは複数を重視するか．
Isochronousだと再送要求できないのがアレな気がしますが、エラーを検出してから再送要求するより、最初から複数回送って必要なかったら捨てる方が実用的なんですかね。同じデータ3回送って多数決とか。
現在もエラー訂正信号は入ってるでしょうが、バッファが許容してくれる範囲内で時間差をつけて送信した方がバーストエラーに強くなりそうな気がします。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
3.0について質問 (スコア:0)
バルクな帯域性能がガッツリ上がって5Gbpsまでイケるようになったのは
他のニュースなんかでも取り上げられてるけど、リアルタイム方面は
どーなってるんでしょうか。
そもそも汎用バスにリアルタイム機器を繋ぐのが間違ってるのは承知ながら、
実際USB接続の機器（具体的にはオーディオ入出力機器）があるので。
2.0でマイクロフレームが導入されてかなりマシになったところまでは
把握してるんですが、3.0でどうなったかなと。
Re:3.0について質問 (スコア:1)
それも不足ですか？
リアルタイム≠帯域予約 (スコア:1)
Isochronous転送は継続的に一定レートのデータを流すことを目的にしているので，
不定期に（突発的に）発生したデータを一定以下の遅延で伝送したいという
リアルタイムアプリケーションの要求とはまた違うのかもしれませんね．
帯域，ジッタ，遅延，どの人つまたは複数を重視するか．
屍体メモ [windy.cx]
Re: (スコア:0)
Isochronousだと再送要求できないのがアレな気がしますが、
エラーを検出してから再送要求するより、
最初から複数回送って必要なかったら捨てる方が実用的なんですかね。
同じデータ3回送って多数決とか。
現在もエラー訂正信号は入ってるでしょうが、
バッファが許容してくれる範囲内で時間差をつけて送信した方が
バーストエラーに強くなりそうな気がします。