問題タブ [low-latency]

複数のトランスポートを処理できるサーバー イベントによって駆動されるリアルタイムの Web ブロードキャスト システムを作成する試みで socket.io/node.js と redis pub/sub を結合する場合、次の 3 つのアプローチがあるようです。

1. 'createClient' redis 接続を作成し、チャネルにサブスクライブします。socket.io クライアント接続で、クライアントを socket.io ルームに参加させます。redis.on("message", ...) イベントで、 io.sockets.in(room).emit("event", data) を呼び出して、関連するルーム内のすべてのクライアントに配信します。socket.ioでredis接続を再利用する方法は?

2. 'createClient' redis 接続。socket.io クライアント接続で、クライアントを socket.io ルームに参加させ、関連する redis チャネルにサブスクライブします。クライアント接続クロージャー内に redis.on("message", ...) を含め、メッセージの受信時に client.emit("event", data) を呼び出して、特定のクライアントでイベントを発生させます。socket.io で RedisStore を使用する例の回答のように

3. socket.io に焼き付けられた RedisStore を使用し、socketio-spec プロトコルに従って、Redis の単一の「ディスパッチ」チャネルから「ブロードキャスト」します。

番号 1 では、Redis サブと関連するイベントをすべてのクライアントに対して 1 回処理できます。2 番目は、Redis pub/sub へのより直接的なフックを提供します。番号 3 はより単純ですが、メッセージング イベントをほとんど制御できません。

ただし、私のテストでは、複数のクライアントが接続されていると、すべてが予想外に低いパフォーマンスを示します。問題のサーバー イベントは、1,000 個のメッセージが redis チャネルにできるだけ早く発行され、できるだけ早く配布されることです。パフォーマンスは、接続されたクライアント (分析のためにタイムスタンプを Redis リストに記録する socket.io-client ベース) でのタイミングによって測定されます。

オプション1では、サーバーがメッセージを受信し、接続されているすべてのクライアントに順次書き込みます。オプション 2 では、サーバーは各メッセージを複数回 (クライアント サブスクリプションごとに 1 回) 受信し、関連するクライアントに書き込みます。いずれの場合も、接続されているすべてのクライアントに通知されるまで、サーバーは 2 番目のメッセージ イベントに到達しません。同時実行数の増加に伴い、状況が明らかに悪化しました。

これは、スタック機能の認識された知恵と矛盾しているようです。信じたいけど難しい。

このシナリオ (大量のメッセージの低遅延配信) は、これらのツールのオプションではないのでしょうか (まだ?)、それともトリックを見逃しているのでしょうか?

生の半構造化されたスキーマのないビッグデータ入力 (HDFS や S3 など) を取得し、ほぼリアルタイムの計算を実行し、BI ツールにクエリまたはプラグインできる出力を生成できるテクノロジはありますか?

そうでない場合、少なくとも来年か 2 年以内のリリースに向けて取り組んでいる人はいますか?

Core Audio を使用してサブミリ秒のレイテンシーでサウンドを再生することは可能ですか?

さまざまなサイズと数のバッファーで AudioQueues を使用してみました。また、AudioUnits を使用してみましたが、30 ミリ秒未満のレイテンシーを実現できませんでした。

オシロスコープを使用して、Arduino のプッシュボタンが押されてからオーディオ ジャックから音が出るまでの時間を測定しています。Arduino 通信が 1 ミリ秒を超える遅延を引き起こすことはありません。

アクティブ/パッシブフェイルオーバーを処理するフレームワーク/ライブラリはありますか？理想的には、高速で軽量で埋め込み可能である必要があります。いくつか見つけましたが、基準に完全には適合していません...

• http://zookeeper.apache.org/
• http://sourceforge.net/projects/jheartbeat/
• http://www.javaworld.com/javaworld/jw-03-2002/jw-0315-heart.html

誰でも始められる簡単な質問:

1. これを行うには、特別なネットワーク インターフェイス カード (nic) が必要であることはわかっています。私はそれがSolarFlareが作るものでなければならないと仮定しています. カーネルバイパスの実装とテストを可能にする、入手できる最も安価なものは何ですか?

2. ネットワーク スタックとしてOpenOnLoadを使用しているようです。ネットワーク アプリケーションで OpenOnLoad を使用する方法のサンプル コードと例はどこにありますか? 私のプログラムがこの技術を利用するのがどれほど簡単か、または複雑かを知りたいです。

この他の質問から生まれた質問: Java でのカーネル バイパスによるネットワーキング

私は信号を生成する STM32F4 CPU のプロジェクトに取り組んでいます。

STM32 の CPU クロック (プリスケーラなし) に汎用タイマーを使用して、オーバーフロー時に割り込みをトリガーし、その後 GPIO で定期的な信号を生成します。

非常に正確な時間 (基本的には 1 CPU サイクルの精度まで) に GPIO をトリガーする必要があります。優先度 & al を設定することで、このジッターを +-5 サイクルに減らすことができましたが、CPU の動作によっては、このジッターが存在します。

この数サイクルのジッターを補正する必要があります。正確なタイミングで GPIO を切り替える限り、数サイクルの遅延を追加しても問題はありません。

私の考えは、カウンターの現在の値を読み取り、FIXED_NUMBER-CURRENT_VALUE 時間のアクティブなループを作成して、正確な時間にループを終了できるようにすることでした。

ただし、C で単純なループを実行する - FOR ループ、または while(counter->value < TARGET) は、ジッターを減らす代わりに追加するため、機能しません。

私は何か間違ったこと/素朴なことをしていますか? アセンブリで行う必要がありますか？それはCとどのように違うでしょうか（GCCで逆アセンブリをチェックして、ループが最適化されていないか、メモリにヒットしていないかを確認しましたか？）

（私は空の、最適化されていないがメモリループ本体に当たらないことを保証しました）

編集: AVRでこの例を参照してください (私が知っているより安定しています)

edit2 : 次のようなアセンブリで単純なループを試しました (r0 は私のカウンター、待機するサイクル数、レジスター内)

繰り返しますが、ジッタはそれがない方が優れています。

要するに、私はどれだけ遅らせるべきかをすでに知っています。コードのブランチが確実にNサイクルを消費し、別のケースではMサイクルを消費する方法が必要です。残念ながら、パイプラインのリフィルには信頼できるサイクル数がかかるように見えないため、分岐だけでは機能しないようです。また、条件式も常に同じサイクル数を取るため (何もしない場合もあります)、そうではありません。

フラッシュの代わりに RAM から実行すると、一貫性が向上しますか? (NB stm32f4 にはフラッシュ プリフェッチがあります。)

簡単な Producer/Consumer プログラムを作成する実験を試みました。それらは別々のスレッドで実行されます。プロデューサはいくつかのデータを生成し、コンシューマは別のスレッドでそれを取得します。私が達成したメッセージング遅延は、約 100 ナノ秒です。これが合理的かどうか、またははるかに高速な実装があるかどうか、誰か教えてもらえますか?

私はロックを使用していません...単純なメモリカウンターです。私の実験はここで説明されています：

http://tradexoft.wordpress.com/2012/10/22/how-to-move-data-between-threads-in-100-nanoseconds/

基本的に、消費者はカウンターがインクリメントされるのを待ってから、ハンドラー関数を呼び出します。したがって、実際には多くのコードはありません。それでも100nsかかるのには驚きました。

コンシューマーは次のようになります。

プロデューサは、利用可能なデータがある場合、単純に w_cnt をインクリメントします。

もっと速い方法はありますか？

Windows 上の ffmpeg によって (DirectShow を使用して) キャプチャされたシステム オーディオを、ストリーミング MP3 ファイルとしてブラウザーに出力する小さな nodeJS サーバーを作成しました。オーディオは、バッファリングを最小限に抑えて、またはバッファリングなしで、可能な限りライブである必要があり、オーディオの「スキップ」効果は完全に許容されます。

HTML5 オーディオ タグを使用して Chrome でオーディオを再生すると、低遅延の LAN 接続で約 8 ～ 10 秒の遅延が発生します。これはクライアント側のバッファではないかと考え、クライアント側で Flash MP3 プレーヤーを使用したところ、遅延が 2 ～ 3 秒に短縮されました。

現在、バッファリングはサーバー側で行われているようです。NodeJS の response.write のドキュメントには、データがカーネル バッファーに書き込まれることが記載されています。クライアントが常に最新の音声データを取得できるように、バッファリングを完全に回避するか、少なくともバッファリングを回避するにはどうすればよいですか? 「ドレイン」イベントを処理して常にライブデータをプッシュするための戦略は?

request オブジェクトでは、setNoDelay(true)を使用して Nagle のアルゴリズムの使用を回避しました。以下は、生成された ffmpeg プロセスがデータを発行するときにデータがどのように書き込まれるかのスニペットです。

Linux でシリアル ポート経由のプロトコルを実装しています。このプロトコルは要求応答スキームに基づいているため、スループットは、デバイスにパケットを送信して応答を取得するのにかかる時間によって制限されます。デバイスはほとんどが Arm ベースで、Linux >= 3.0 を実行します。往復時間を 10 ミリ秒未満に短縮するのに問題があります (115200 ボー、8 データ ビット、パリティなし、メッセージあたり 7 バイト)。

select、poll、epoll、または ioctl を使用した手動のポーリングのうち、どの IO インターフェースが最小のレイテンシーを提供してくれるでしょうか? ブロッキング IO または非ブロッキング IO はレイテンシに影響しますか?

setserial で low_latency フラグを設定してみました。でも効果は無かったようです。

レイテンシーを減らすために他にできることはありますか? 私はすべてのデバイスを制御しているため、カーネルにパッチを適用することもできますが、そうしないことをお勧めします。

- - 編集 - -

シリアル コントローラーは 16550A を使用します。

非常に低いレイテンシ レベルで、リアルタイムの優先処理とフラッシュでのキューイングを実行することは可能ですか? クライアントホストでリアルタイムの優先度を受け取り、低遅延ストリームで転送する必要がある、かなり大きなデータストリーム (生のオーディオであり、おそらくオーバーヘッドをほとんど追加しない効率的な圧縮アルゴリズムで圧縮する必要があります) があります。可能な限り受信側に。Flash を使用して、リアルタイムで非常に低遅延の接続を実行することは可能ですか?

これらの要件を考えると、ギアを Java または C / C# にシフトする必要があるように思えます... しかし、まだ見たことのない何かを発見できることを期待しています。