送受信データのドロップ

いくつかの理由により送受信データがドロップすることがあります。
ドロップの発生箇所と対処方法は以下のとおりです。

1. データ送信

                    s1               s2                 s3                   s4                    program
Tera Term ---> Tera Term内  ---> OS,driver  ---> (sshd,telnet,pipe) ---> UARTチップ ---> 擬似端末(pty) + シェル,コマンド
               送信バッファ      UARTチップ      (serial          )      driver,OS       組込プログラム等
s1. Tera Term内の送信バッファ
可能性は低いでしょう。
送信バッファ OutBuff[](16KB) の空きサイズを見ながらデータを詰めていきます。
s2. OS(送信側),UARTチップ
可能性は低いでしょう。
使用するハードウェア、ドライバのバージョンによっては BSoD を含めて様々な不具合が発生することがあります。
Tera Term のシリアルポート設定でドライバの詳細を見ることができます。
Tera Termは SetupComm()で通信デバイスに送信バッファーの推奨サイズとして4KBを提案します。
s3. 送信路
ケーブルの品質、ケーブル長、クロストークや信号干渉等によりエラーが発生し、ドロップすることがあります。
シリアルの場合エラー時の再送処理はありません。
TCP/IP、pipe の場合は可能性は低いと思われます。
s4. UARTチップ,OS(受信側)
対向機器の処理能力を超えたデータの受信(program が OS やチップから受信データを引き取らない場合)等で、 OS(ドライバ)、UART チップの受信バッファがオーバーフローしてドロップします。
フロー制御等は OS(ドライバ)が行うか program が行うかは実装によります。
TCP/IP ではフロー制御、エラー時の再送が行われ、多くの場合 OS 内のプロトコルスタックがこれらの処理を行います。
シリアルではフロー制御の有無はユーザーが決めることができ、オーバーフロー等エラー時の再送は自動で行われません。
program
プログラム内の受信バッファのオーバーフロー等でドロップします。
仮想端末(pty)ではバッファが溢れそうになると 0x07(BEL) が送られ、Tera Term でベルがなります。

2. データ受信

                    r1               r2                 r3                   r4                    program
Tera Term <--- Tera Term内  <--- UARTチップ <--- (sshd,telnet,pipe) <--- OS,driver  <--- 擬似端末(pty) + シェル,コマンド
               受信バッファ      driver,OS       (serial          )      UARTチップ      組込プログラム等
program
可能性は低いでしょう。
プログラム内の送信バッファのオーバーフロー等でドロップします。
r4. OS(送信側),UARTチップ
可能性は低いでしょう。
使用するハードウェア、ドライバのバージョンによっては様々な不具合が発生することがあります。
r3. 受信路
ケーブルの品質、ケーブル長、クロストークや信号干渉等によりエラーが発生し、ドロップすることがあります。
シリアルの場合エラー時の再送処理はありません。
TCP/IP、pipe の場合は可能性は低いと思われます。
r2. UARTチップ,OS(受信側)
Tera Termは SetupComm()で通信デバイスに受信バッファーの推奨サイズとして16KBを提案します。
高負荷等により、UARTチップやOSからの読み出しが遅延すると、通信デバイスの受信バッファがオーバーフローしてドロップします。
フロー制御等は OS(ドライバ)が行うか program が行うかは実装によります。
TCP/IP ではフロー制御、エラー時の再送が行われ、多くの場合 OS 内のプロトコルスタックがこれらの処理を行います。
シリアルではフロー制御の有無はユーザーが決めることができ、オーバーフロー等エラー時の再送は自動で行われません。

主なUARTチップ、ドライバの受信バッファサイズは以下のとおり。 

8250 UART                 受信バッファなし
16550 UART                16 Byte FIFO
FT232R                    256 Byte receive buffer
TTY drive(Linux 2.6.26)   4KB  (TTSSHによるSSHの設計と実装/擬似端末のしくみ)
r1. Tera Term内の受信バッファ
OSから読み出した受信データは、Tera Term の受信バッファ InBuff[](16KB) に格納され、画面描画、ログ出力、マクロの処理等が行われます。
Tera Termの処理(画面描画、ログ出力、マクロの処理等)が遅延すると受信バッファがオーバーフローしてドロップします。

3. 対処方法

  1. 接続方法の確認
    2. シリアル接続の場合は、送信側と受信側で通信設定(ボーレート、ビット長等)が一致していることを確認して下さい。
    フロー制御の導入により、受信バッファのオーバーフローを抑制出来ます。
    ハードウェアフロー制御(RTS/CTS、DSR/DTR)の使用が推奨です。

  2. 送信データがドロップする場合
    3. 対向機器「s4. UARTチップ,OS(受信側)」、「program」の処理性能の不足が原因と思われます。
    対処方法は、通信速度を遅くすること、単位時間あたりの送信量を減らすことになります。
    シリアル接続の場合は、ボーレートを低くして下さい。
    組み込み機器等でボーレートの変更が出来ない場合は送信ディレイを設定し、受信バッファのオーバーフローを抑制します。
    LCDコントローラ等で改行や画面クリアに時間がかかり、処理完了前に次のコマンドを送信すると不具合が発生するような場合も送信ディレイは有効です。

  3. 受信データがドロップする場合
    4. 「r2. UARTチップ,OS(受信側)」、「r1. Tera Term内の受信バッファ」の処理性能の不足が原因と思われます。
    Visual Studio、動画・画像編集ソフト等多くのリソースを必要とするアプリを起動する際、一時的にリソースが不足しドロップすることがあります。
    対処方法は、通信速度を遅くすること、単位時間あたりの送信量を減らすことになります。
    シリアル接続の場合は、ボーレートを低くして下さい。

  4. その他
    5. データエラーが発生する場合は、高品質なケーブルを使用したり、ノイズ発生源(電源アダプタ、電源ケーブル等)からケーブルを離すことで改善される場合があります。