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

TCPパフォーマンス問題に対処する際、最初に確認すべきは低レベルなイーサネットの問題であり、圧倒的に最も一般的な問題はデュプレックスの不一致です。イーサネットは全二重モードまたは半二重モードで動作します。全二重モードでは、モジュールのアダプタと接続先デバイス（リンク相手、通常はスイッチですが必ずしもそうとは限りません）の両方が同時に送信できます。半二重モードでは片側のみが送信可能です。 双方が送信可能と判断して同時に送信を試みる時間的窓が存在します。この衝突が発生すると、双方は送信を停止し、ランダムな待機時間後に再試行します。重要なのは、双方が半二重モードの場合、こうした衝突がネットワークスループットを著しく低下させない点です。

デュプレックス不一致では、一方が全二重モードで動作しているのに対し、そのリンク相手は半二重モードで動作しています。半二重モード側の端末では遅延衝突や過剰衝突が発生する可能性があり、これらのエラーはスループットを著しく低下させます。  遅延衝突や過剰衝突は問題の兆候です。ネットワークの速度低下は、遅延衝突や過剰衝突の数に対して不釣り合いに見える場合があります。これは、デュプレックス不一致状態では、通常の衝突でさえスループットを低下させるためです。フルデュプレックスモードでは衝突を認識しないため、リンク相手側がフレームを再送信しないからです。

では、それが自分に起きているかどうかはどう見分ければよいのでしょうか？その「netstat -interface”コマンドは、デュプレックスの不一致が発生しているかどうかを判断できる統計情報を表示します。次の例では、アクティブアダプタの統計情報が表示されます。 #sdlmux.m16.11-3 インターフェースが表示されます。スペース節約のためスタンバイアダプターの統計情報を削除し、行番号を追加しました。

アダプタが半二重モードの場合、行25（送信フレーム遅延）、26（単一再試行後の送信フレーム）、27（複数再試行後の送信フレーム）に正のカウントが表示されます。これらは通常の衝突カウンターです。 行24（送信フレーム破棄、遅延衝突）および/または行28（送信フレーム破棄、過剰リトライ）に正の値が表示される場合、デュプレックス不一致が発生している（または発生していた）可能性があります。これらのカウンタはアダプタのリセット時にのみリセットされるため、正の値は問題があったことを示し、増加し続けるカウンタは問題が継続していることを示します。 アダプタが全二重モードの場合、32行目（受信フレーム破棄、CRCエラー）に正の値が表示される場合、リンク相手側が半二重モードである可能性が高いです。

この全二重モードの不一致状態はどうして発生したのですか？もちろん、一方のデバイスを全二重モードで動作させ、リンク相手を半二重モードに設定することは可能です。しかし、最も一般的なシナリオは、一方のデバイスを全二重モードに設定し、リンク相手を自動ネゴシエーションに設定することです。 ほとんどのデバイスは全二重モードで設定されている場合、自動ネゴシエーションを行いません。自動ネゴシエーション仕様によれば、自動ネゴシエーションを試みる側は、リンク相手から自動ネゴシエーションプロトコルを検知できない場合、半二重モードにフォールバックする必要があります。

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

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