Tera Term の送信遅延の動作を調べてみた

有名なターミナルエミュレータの [Tera Term](https://teratermproject.github.io/) には、「送信遅延」という機能がある。
これは、1文字ごと、および1行ごとにデータを送信する間隔を空けることで、フロー制御を行わなくても受信側の装置がデータを処理する時間を確保できるものである。
今回は、この「送信遅延」機能の動作を調べてみた。

# 環境

* OS：Windows 11 Home 24H2
* Tera Term Version 5.3 x86 (Git 5b83fb6f7)
* USB-シリアル変換：TTL-232R-5V ([秋月電子通商](https://akizukidenshi.com/catalog/default.aspx) 販売コード：105841)
* [USBロジックアナライザ - 24 MHz/8チャンネル（Type C コネクタ）](https://www.switch-science.com/products/7642)

# 今回の調査内容

* 1文字ごとの送信遅延は、文字の送信にかかる時間を含むか？文字の送信とは別に待機するか？
* 1行ごとの送信遅延は、1文字ごとの送信遅延に加算されるか？1文字ごとの送信遅延のかわりに行うか？

# 調査方法

Tera Term でUSB-シリアル変換器に接続し、通信速度を300bps、文字ごとの送信遅延を50ms、行ごとの送信遅延を100msに設定する。

![Tera Term の設定](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/669f4c7c-d605-4948-a3f0-58b76e8c690b.png)

この状態で、

```text
hello
world
```

を貼り付けて送信する。
そして、TXD 端子から出力される信号をロジックアナライザで観察する。

# 実験結果

以下のような信号が得られた。

![観測された信号](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/ca7db194-63cd-4632-bcb3-d5f2e7bbc548.png)

1文字の送信にかかる時間は、約33.3msである。

![1文字の送信にかかる時間 (300bps)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/5c0b11f9-2c84-4151-b93e-6d80348e295d.png)

以下のように、各文字と次の文字のスタートビットの先頭の時間間隔を測定した。

![文字の送信間隔の測定](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/416774b6-ec58-4cf6-8ef8-463d6f148420.png)

測定結果は、以下のようになった。

|文字|次の文字との間隔 [ms]|
|:-:|--:|
|h|60.00|
|e|60.00|
|l|66.65|
|l|60.00|
|o|63.35|
|(改行)|106.65|
|w|63.35|
|o|60.00|
|r|66.65|
|l|63.35|
|d|-|

このことから、以下のことが読み取れる。

* 各文字の送信間隔は、設定した送信遅延よりは長いが、文字の送信と別に待機しているにしては短い
* 1行ごとの送信遅延は、1文字ごとの送信遅延に加算せず、かわりに行う

# 追加実験

より詳細に動作を調べるため、以下の設定でさらに実験を行った。

* 通信速度：115200bps
* 文字ごとの送信遅延：50ms
* 行ごとの送信遅延：20ms

以下の信号が得られた。

![観測された信号 (追加実験)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/2263e3ce-f198-47ff-8814-23b94c417404.png)

1文字の送信にかかる時間は、約0.087msである。
300bpsのときより30ms以上短いので、もし1文字ごとの送信が文字の送信と別に行われているのであれば、送信間隔が30ms程度短くなると考えられる。

![1文字の送信にかかる時間 (115200bps)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/5c5c9b51-f5e5-41ad-8ad3-fe88d6504026.png)

各文字のスタートビットの先頭の間隔の測定結果は、以下のようになった。

|文字|次の文字との間隔 [ms]|
|:-:|--:|
|h|53.81|
|e|59.39|
|l|66.83|
|l|59.92|
|o|62.25|
|(改行)|29.81|
|w|63.24|
|o|60.33|
|r|64.88|
|l|62.12|
|d|-|

改行以外の文字と次の文字との間隔は、300bpsのときと比べて6ms程度短くなった文字もあるが、ほとんどの文字では0～2msの差であり、やはり文字の送信にかかる時間は考慮されていないようであることが読み取れる。

さらに、改行と次の文字との間隔は、他の文字と次の文字との間隔より短くなった。
このことから、行ごとの送信遅延は、文字ごとの送信遅延との最大値をとるわけでもなく、単純に上書きするということが読み取れる。

# 追加実験 (2)

文字ごとの送信遅延を15ms、行ごとの送信遅延を200msに設定し、以下の文字列を貼り付けて送信した。

```text
hello
world
!
```

115200bps のときは、以下の信号が得られた。

![観測された信号 (追加実験 (2) 115200bps)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/0adab122-2976-465f-a0f3-6463c73556b4.png)

各文字のスタートビットの先頭の間隔の測定結果は、以下のようになった。

|文字|次の文字との間隔 [ms]|
|:-:|--:|
|h|11.19|
|e|20.40|
|l|13.30|
|l|21.50|
|o|10.37|
|(改行)|204.35|
|w|11.71|
|o|16.36|
|r|14.96|
|l|16.67|
|d|14.80|
|(改行)|202.62|
|!|-|

おおむね10～20ms間隔で送信できていることがわかる。

300bps のときは、以下の信号が得られた。

![観測された信号 (追加実験 (2) 300bps)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/6d184eb8-5c51-46d7-8b85-db2ce18322bc.png)

各文字のスタートビットの先頭の間隔の測定結果は、以下のようになった。

|文字|次の文字との間隔 [ms]|
|:-:|--:|
|h|33.33|
|e|33.33|
|l|33.33|
|l|33.34|
|o|33.33|
|(改行)|113.32|
|w|33.33|
|o|33.33|
|r|33.32|
|l|33.33|
|d|33.33|
|(改行)|116.65|
|!|-|

1文字の送信にかかる時間よりも送信遅延を短く設定したため、改行以外の文字では直後に次の文字が送信されている。
そして、設定よりも文字の送信間隔が長くなった分、改行の後の間隔が減っていることがわかる。
このことから、Tera Termは1文字の送信にかかる時間は考慮せず、設定した間隔で各文字をUSB-シリアル変換器に送っているらしいことがわかる。

# 0ms設定の実験

* 通信速度：300bps
* 文字ごとの送信遅延：0ms
* 行ごとの送信遅延：150ms

に設定し、文字列

```text
1
23
456
7890
1
```

を貼り付けて送信すると、以下の信号が得られた。

![観測された信号 (0ms/字の実験)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/3c0240c7-3754-4f1d-b61b-d8aec813de84.png)

それぞれの行の最初のスタートビットと、次の行の最初のスタートビットの間隔は、以下のようになった。

|行|次の行との間隔 [ms]|
|:--|--:|
|1|150.00|
|23|153.35|
|456|156.65|
|7890|166.65|
|1|-|

各行の送信開始の間隔は、1行の送信にかかる時間が行ごとの送信遅延設定を超えなければ、1行の送信にかかる時間にかかわらずだいたい同じであることがわかる。
これまでの実験では、「行ごとの送信遅延設定」は各行の最後の文字 (改行文字) の送信を開始してから次の文字の送信を開始するまでの時間に反映されていたが、今回は1文字あたりの送信遅延を0msとしているため、それぞれの行の最初の文字を送るタイミングと最後の文字を送るタイミングが同じとみなされていると考えられる。

さらに、同じ設定で、文字列

```text
123
45678
9
0123
4567
8
9
```

を貼り付けて送信すると、以下の信号が得られた。

![観測された信号 (0ms/字の実験 (2))](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/f9eb1194-5d44-4d23-9d98-2077b83dbea7.png)

それぞれの行の最初のスタートビットと、次の行の最初のスタートビットの間隔は、以下のようになった。

|行|次の行との間隔 [ms]|
|:--|--:|
|123|149.05|
|45678|200.00|
|9|113.30|
|0123|166.65|
|4567|166.65|
|8|133.35|
|9|-|

1行の送信にかかる時間が行ごとの送信遅延設定を超えると、次の行とその次の行の間隔が短くなっていることがわかる。

また、


* 通信速度：300bps
* 文字ごとの送信遅延：100ms
* 行ごとの送信遅延：0ms

に設定し、文字列

```text
12
3

45
```

を貼り付けて送信すると、以下の信号が得られた。

![観測された信号 (0ms/行の実験)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/ee8d03ea-f6e5-4428-ab4a-6f1a1fd941f4.png)

各文字のスタートビットの先頭の間隔の測定結果は、以下のようになった。

|文字|次の文字との間隔 [ms]|
|:-:|--:|
|1|103.35|
|2|110.00|
|(改行)|110.00|
|3|106.65|
|(改行)|110.05|
|(改行)|106.65|
|4|110.00|
|5|-|

予想に反し、改行の送信後にも、他の文字の送信後と同程度の間隔が開いた。

行ごとの送信遅延を1msに設定し、同様に送信すると、以下の信号が得られた。

![観測された信号 (1ms/行の実験)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/8031bef9-bcbe-4140-93a6-f7a9e566aa0c.png)

|文字|次の文字との間隔 [ms]|
|:-:|--:|
|1|99.95|
|2|106.65|
|(改行)|33.35|
|3|93.29|
|(改行)|33.35|
|(改行)|33.35|
|4|76.65|
|5|-|

予想通り、改行文字の送信後はすぐに次の文字が送信され、それが改行でない場合はその次の文字との間隔が短くなる現象がみられた。
原則として行ごとの送信遅延は文字ごとの送信遅延を上書きするが、行ごとの送信遅延が0msのときは例外として上書きせず、文字ごとの送信遅延を使用するようである。

# まとめ

今回の実験から、Tera Term 5.3 の送信遅延は以下のような動作をするらしいことがわかった。

* **各文字の送信にかかる時間は考慮せず**、各文字をデバイスに送るタイミングの間隔を設定された時間にすることを狙う
* 行ごとの送信遅延設定が0msでない場合は、改行文字の送信から次の文字の送信までの間隔として、文字ごとの送信遅延設定の値の**かわりに**行ごとの送信遅延設定の値を用いる
* 行ごとの送信遅延設定が0msの場合は、改行文字の送信から次の文字の送信までの間隔としても、文字ごとの送信遅延設定の値を用いる

今回の実験結果はあくまで今回の条件でのものであり、Tera Term のバージョン・送り先のデバイス・送るデータの量 (とくに、送るデータの量が送り先のデバイスのバッファサイズを超える場合) などによっては異なる動作になる可能性が考えられる。