問題タブ [low-latency]

特定のPythonスクリプトのいくつかのインスタンスをWindowsマシンで実行しています。それぞれが異なるディレクトリから、別々のシェルウィンドウを使用しています。残念ながら、Windowsはこれらの各シェルウィンドウに同じ名前を付けています。

Pythonコマンドを使用してこの名前を別の名前に設定することは可能ですか？

C++ マルチスレッドでネットワーク フローの問題を解決しようとしています。

与えられたネットワーク (すべてのノードがアークで接続され、各アークは 2 つだけの終了ノードに接続され、1 つは入力ノードで、もう 1 つは出力ノードであり、各ノードは複数の入力アークと出力アークを持つことができます)、各ノードは次のことを行う必要があります。いくつかの計算を行い、計算結果データを接続された入力ノードと出力ノードに交換します。

複数のノードを 1 つのスレッドで実行される 1 つのタスクにグループ化できます。このようにして、ネットワーク コンピューティングのワークロード全体を複数のタスクに分割できます。これらのタスクはすべてブースト スレッド プールにプッシュされ、すべてのスレッドが同時にタスクを実行できるようになります。

ただし、ノード (スレッド タスク内) が別のノード (別のスレッド タスク内) とデータ交換を行う必要がある場合、同期の問題があります。データ受信者は、データ送信者のデータ バッファーでデータが使用可能になるまで待機する必要があります。

私のプログラムは、各スレッドのタスク ワークロードができるだけ均等に割り当てられるように、ネットワークを分割する必要があります。すべてのスレッドがワンラージ データ バッファー構造を共有する場合、クリティカル セクションが大きすぎるため、プログラムの並列処理は適切ではありません。一部のスレッドは、データ構造の一部 (スレッドにとって有用) が読み取りまたは書き込みに使用可能になったとしても、1 つの大きなデータ バッファー構造がロック解除されるのを待機する必要があります。

たとえば、ワンラージ データ バッファー構造には、 cell1 、 cell2 、 cell3 、 cell4 のバッファー セルがあります。

スレッド 1 がセル 1 に書き込もうとするとき、スレッド 2 がセル 2 を読み書きできないように、データ バッファ構造全体をロックする必要があります。

そのため、1 つの大きなデータ バッファー構造を、スレッド番号に応じて複数の異なるデータ セルに分割し、各セルが 1 つのスレッド タスクにのみ必要なデータを保持するようにします。

たとえば、2 つのスレッドがある場合、4 つのスレッドが必要とするデータを別々に保持する 2 つのデータ セルを作成します。4 つのスレッドがある場合、4 つのスレッドが必要とするデータを個別に保持する 4 つのデータ セルを作成します。等々。

私の質問は次のとおりです。

(1) データセルの設計方法は? そのサイズはスレッド数に基づいていることがわかります。

(2) 同期のオーバーヘッドを減らすには? クリティカル セクションは小さいですが、ノード間のデータ交換頻度が高い場合、mutex の取得と解放のオーバーヘッドが非常に高くなる可能性があります。

(3) ノードの計算が完了し、データがそのセルに書き込まれるとき、受信ノードの計算タスクを実行する待機中のスレッドによってのみ通知メッセージが受信されるように、データ受信ノードに通知する方法。他のすべての無関係なノードとスレッドは影響を受けません。

このプログラムは非常に時間に敏感であり、メッセージ交換の待ち時間は非常に厳しく制御され、可能な限り短縮される必要があります。

どんな助けでも本当に感謝しています。

ありがとう

すべての主要な投資銀行は、低遅延/高頻度のサーバーアプリケーションにUnix（Linux、Solaris）でC++を使用しているようです。高頻度株式の取引において、人々はどのようにして低レイテンシーを達成するのでしょうか？これを達成する方法を教えている本はありますか？

高精度のタッチ処理が必要なアプリに取り組んでいます。OnTouchListenerにできるだけ多くのonTouchイベントを受信させて、指がどこに行ったかを正確に確認できるようにします。これらのイベントを受け取る頻度を上げる方法はありますか？

低遅延を必要とする高頻度取引 (HFT) システムでは、UDP よりも TCP が使用されると言われました。TCPではポイントツーポイント接続を作成できるのに対し、UDPではできないと言われましたが、私の理解では、UDPパケットを特定のIP /ポートに送信できます。

この記事では、ゲームで UDP > TCP を使用する理由についていくつかの議論が行われていますが、HFT との関連性は理解できます。

TCP が HFT に使用するのに適したプロトコルである理由は何ですか?

(管理者: この質問の以前の投稿は、説明なしで黙って削除されました。使用条件に違反している場合は、黙って質問を削除するのではなく、これについて警告してください)

共有メモリにあるデータを操作するプログラムを開発しています。プログラムはレイテンシーを要求し、膨大な量のデータを処理します。

プログラムが失敗した場合、最後の作業状態にすばやく戻らなければなりません。

1 つの方法は、その日の開始からのトランザクションを含むトランザクション ログからデータを読み取って処理することです。しかし、トランザクション ログのサイズ (数百ギガバイト) を考慮すると、これはまったく高速ではありません。

現在、プログラムが失敗した場合にディスクに書き込み、非常に高速に読み取ることができるデータのスナップショットを作成する方法を探しています。ただし、スナップショットの作成によってプログラムの実行がロックされてはならず、そのスナップショット内のデータは一貫している必要があります。

共有メモリの代わりにデータを保持するためにローカル メモリを使用していた場合、解決策は簡単です。

1. フォーク（）
2. データをディスクに書き込む

Linuxのコピーオンライトにより、変更されたデータのみがコピーされるため、非常に高速です。

ただし、posix 共有メモリを使用しています。

速度と一貫性を念頭に置いてそれを行う方法はありますか?

私は現在、反応時間の実験で誰かを助けています。この実験では、キーボードの反応時間が測定されます。この実験では、キーを押してからソフトウェアで処理するまでの遅延が原因で、どの程度のエラーが発生する可能性があるかを知ることが重要な場合があります。

これが私がすでにグーグルを使って見つけたいくつかの要因です：

• USBバスは、最小で125Hz、最大で1000Hzでポーリングされます（設定によって異なります。このリンクを参照してください）。
• Windowsには、キーの押下をさらに遅らせる可能性のある追加のキーボードバッファーがいくつかある可能性がありますが、その背後にあるロジックについてはわかりません。

残念ながら、実験の低レベルのロジックを制御することはできません。実験は、この種の実験によく使用されるソフトウェアであるE-Primeで記述されています。ただし、E-Primeを提供する会社は、正確な反応タイミングを宣伝する追加のハードウェアも提供しています。したがって、彼らはこの効果を認識しているようです（ただし、その大きさはわかりません）。

残念ながら、標準のキーボードを使用する必要があるので、レイテンシーを減らす方法を提供する必要があります。

私は、ソケットを介してtcpデータを受信する低遅延の金融アプリケーションに取り組んでいます。
これが私がソケット接続を確立してバイトを受信する方法です：

Receive()Streamソケットを呼び出すと、呼び出し元のスレッドがスリープ状態になり、データを受信するとウェイクアップすると聞きました。スレッドをフルスピードで実行したい（CPU容量を使用）。

Streamソケットを使用してこれを行う方法はありますか？唯一の方法がRawソケットを使用する場合、例を挙げていただけますか？

私は、テキストプロトコルを使用して接続を受け入れ、メッセージ（〜100バイト）を攻撃するサーバーを作成しました。私の実装では、サードパーティクライアントとのループバック400K/秒メッセージを送信できます。このタスクにはNetty、SUSE 11 RealTime、JRockitRTSを選びました。しかし、Nettyに基づいて独自のクライアントを開発し始めたとき、スループットが大幅に低下しました（400Kから1.3K msg /秒に減少）。クライアントのコードは非常に単純です。より効果的なクライアントを作成する方法について、アドバイスや例を示していただけませんか。実際、私はレイテンシーにもっと関心がありますが、スループットテストから始めており、ループバックで1.5Kmsg/秒になるのは正常ではないと思います。PSクライアントの目的は、サーバーからメッセージを受信することだけであり、ハートビットを送信することはめったにありません。

アップデート。サーバー側には、受け入れられたクライアントチャネルに書き込む定期的なスレッドがあります。そして、チャンネルはすぐに書き込み不能になります。N2を更新します。パイプラインにOrderedMemoryAwareExecutorを追加しましたが、スループットは非常に低くなっています（約4k msg / sec）

修理済み。パイプラインスタック全体の前にエグゼキュータを配置しましたが、うまくいきました。

私はPythonで音楽アプリケーションに取り組んでいます。低遅延のオーディオ再生にPyAudiereを使用していますが、Mac OSX で作業するのは非常に簡単ではないことがわかりました (指示に従ってコンパイルできませんでした。メッセージが表示されますDeviceFrame.cpp:60: error: call of overloaded ‘wxString(const char*)’ is ambiguous)。Mac で動作する別の優れた Python オーディオ フレームワークはありますか? ピッチとボリュームを動的に調整する機能と、低レイテンシーが必要です。PyPy との互換性は良好ですが、必須ではありません。