ネットワーク関連のパーフォマンスの問題？まず、低レベルのイーサネットの問題をチェックしてください。

TCP パフォーマンスの問題に対処する際に最初に探すべきものは、低レベルのイーサネットの問題であり、最も一般的な問題は二重の不一致です。イーサネットは全二重または半二重モードで動作します。全二重モードでは、モジュールのアダプタと接続されているデバイス（通常はスイッチですが、必ずしもそうとは限りません）の両方が同時に送信できます。半二重モードでは、片側のみが送信できます。双方が送信しても問題ないと考えることができる時間のウィンドウがあり、それが起こると衝突が宣言され、双方の送信を停止し、ランダムな時間の量を待って、再度試してみます。双方が半二重モードの場合、これらの衝突はネットワークのスループットを大幅に低下させないことを理解することが重要です。

二重ミスマッチでは、一方の側が全二重モードで、そのリンクピアが半二重モードになっています。半二重モードの側では、遅延コリジョンや過剰なコリジョンが発生する可能性があり、これらのタイプのエラーはスループットを大幅に低下させます。 遅延または過剰なコリジョンは、問題の兆候です。なぜなら、全二重モードではリンクピアはコリジョンを認識しないため、リンクピアはフレームを再送信しないため、二重不一致状態では通常のコリジョンでさえもスループットを低下させるからです。

では、それが自分の身に起こっているかどうか、どうやって見分けるのでしょうか？ということですが、"netstat -interface"コマンドを使用すると、統計情報が表示され、二重の不一致が発生しているかどうかを判断することができます。のアクティブなアダプタの統計情報が表示されます。 #sdlmux.m16.11-3 インターフェースが表示されます。スペースを節約するために待機アダプタの統計情報を削除し、回線番号を追加してみました。

アダプタが半二重モードの場合、25 行目（送信フレームが延期された）、26 行目（1 回のリトライ後の送信フレーム）、27 行目（複数回のリトライ後の送信フレーム）に正のカウントが表示されます。これらは通常のコリジョンカウンタです。24 行目（送信フレームが破棄された、遅延コリジョン）および/または 28 行目（送信フレームが破棄された、過剰なリトライ）に正のカウントが表示された場合は、おそらくデュプレックスの不整合があるか、または発生している可能性があります。これらのカウンタは、アダプタがリセットされたときにのみリセットされるので、正の値は問題があったことを示していますが、カウンタが上昇し続ける場合は、まだ問題があることを示しています。アダプタが全二重モードで、32 行目に正の値が表示された場合 (受信フレームが破棄された、CRC が悪い)、リンク・ピアは半二重モードになっている可能性があります。

どのようにしてこのデュプレックスミスマッチのシナリオに入ったのですか？もちろん、1つのデバイスを全二重モードで動作するように設定し、リンクピアを半二重モードで動作するように設定することは可能ですが、最も一般的なシナリオは、1つのデバイスを全二重に設定し、リンクピアをオートネゴシエーションに設定することです。全二重に設定されたほとんどのデバイスは自動ネゴシエーションを行いません。自動ネゴシエーション仕様によると、リンクピアからの自動ネゴシエーションプロトコルが表示されない場合、自動ネゴシエーションを行う側は半二重モードにフォールバックしなければなりません。

デフォルトでは、OpenVOS が使用するイーサネットアダプタは自動ネゴシエーションを行いますので、リンクピアが自動ネゴシエーションまたは半二重モードに設定されていない限り、二重の不一致が発生します。特定の二重モード用のアダプタを設定するには “-duplex full” 或いは “-duplex half” 文字列をアダプタの devices.tin エントリのパラメータフィールドに追加します。速度も設定する必要があります。OpenVOS Streams TCP/IP 管理者ガイド (R419) に詳細が記載されています。

最後の注意点として、アダプタが1ギガビットで動作している場合は、全二重モードでも動作していることになります。半二重のギガビットはサポートしていません。