Dropping sent and received data

Data sent or received may be lost for various reasons.
The locations where drops occur and the solutions are as follows:

1. Sending Data

                    s1               s2                 s3                  s4                  program
Tera Term ---> Send buffer  ---> OS,driver ---> (sshd,telnet,pipe) ---> UART chip  ---> pty + shell, other program
               in Tera Term      UART chip      (serial          )      driver,OS       Embedded programs, etc.
s1. Sned buffer in Tera Term
It is unlikely to drop.
Data is sended while watching free size of send buffer OutBuff[](16KB).
s2. OS,UART chip(sender)
It is unlikely to drop.
Depending on hardware and driver version, various problems may occur, including BSoD.
You can see details of driver in Tera Term serial port settings.
Tera Term will suggest 4KB as the recommended size of the send buffer to the communication device in SetupComm().
s3. transmission path
Cable quality, cable length, crosstalk, signal interference, etc. can cause errors and drops.
In serial, there is no resend process with error. If error occurs in data, data is dropped.
For TCP/IP, pipe, it is unlikely to drop.
s4. UART chip,OS(receiver)
Receiving data beyond processing capacity of PC (CPU) (when PROGRAM does not pick up received data from OS or chip) or other causes, Receive buffer of OS (driver) or UART chip are overflows and data is dropped.
OS (driver) or program handles flow control depends on implementation.
In TCP/IP, flow control and resend on error are performed, and in most cases, protocol stack in OS handles these processes.
In serial, user can decide whether flow control is used or not, and resend are not automatically performed in case of overflow or other errors.
program
Dropped due to receive buffer overflow, etc. in program.
When receive buffer is about to overflow in pseudo terminal(pty), 0x07(BEL) is sent and Tera Term will ring bell.

2. Receiving Data

                    r1                  r2                 r3                  r4                  program
Tera Term ---> Receiving buffer ---> UART chip ---> (sshd,telnet,pipe) ---> OS,driver  ---> pty + shell, other program
               in Tera Term          driver,OS      (serial          )      UART chip       Embedded programs, etc.
program
It is unlikely to drop.
Drop due to send buffer overflow, etc. in program.
r4. OS,UART chip(sender)
It is unlikely to drop.
Depending on hardware and driver version, various problems may occur.
r3. transmission path
Cable quality, cable length, crosstalk, signal interference, etc. can cause errors and drops.
In serial, there is no resend process with error. If error occurs in data, data is dropped.
For TCP/IP, pipe, it is unlikely to drop.
r2. UART chip,OS(receiver)
Tera Term will suggest 16KB as the recommended receive buffer size for the communication device in SetupComm().
If reading from the UART chip or OS is delayed due to high load, the receive buffer of the communication device will overflow and data will be dropped.
In TCP/IP, flow control and resend on error are performed, and in most cases, protocol stack in OS handles these processes.
In serial, user can decide whether flow control is used or not, and resend are not automatically performed in case of overflow or other errors.

Receive buffer size of main UART chips and drivers

8250 UART                 no FIFO
16550 UART                16 Byte FIFO
FT232R                    256 Byte receive buffer
TTY drive(Linux 2.6.26)   4KB  (SSH Design and Implementation in TTSSH)
      
r1. Receiving buffer in Tera Term
The received data read from the OS is stored in Tera Term's receive buffer InBuff[] (16KB), where it is used for screen drawing, log output, macro processing, etc.
If Tera Term processing (screen drawing, log output, macro processing, etc.) is delayed, the receive buffer will overflow and data will be dropped.

3. Solution

  1. Checking the Connection Method
  2. For serial connections, make sure the Serial parameters (baud rate, bit length, etc.) match between the sender and receiver.
    Setting flow control can help prevent receive buffer overflow.
    Hardware flow control (RTS/CTS, DSR/DTR) is recommended.

  3. If the transmitted data is dropped
  4. This is thought to be due to insufficient processing performance of the opposing device "s4. UART chip,OS(receiver)" and "program".
    The solution is to slow down the communication speed and reduce the amount sent per unit time.
    For serial connections, lower the baud rate.
    If the baud rate cannot be changed, such as in embedded devices, set a send delay to prevent the receive buffer from overflowing.
    A send delay is also effective in cases where line feeds or screen clearing take time, such as with LCD controllers, and sending the next command before the processing is complete causes problems.

  5. If received data is dropped
  6. This is probably due to insufficient processing performance in "r2. UART chip,OS(receiver)" and "r1. Receiving buffer in Tera Term"
    When launching a resource-intensive app such as Visual Studio or video/image editing software, the app may temporarily run out of resources and drop.
    The solution is to slow down the communication speed and reduce the amount sent per unit time.
    For serial connections, lower the baud rate.

  7. Others
  8. If data errors occur, the problem may be resolved by using a higher quality cable or by moving the cable away from noise sources (power adapter, power cable, etc.).