|
| 1 | +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| 2 | + "http://www.w3.org/TR/html4/strict.dtd"> |
| 3 | +<HTML> |
| 4 | +<HEAD> |
| 5 | +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| 6 | +<TITLE>Dropping sent and received data</TITLE> |
| 7 | +<META http-equiv="Content-Style-Type" content="text/css"> |
| 8 | +<link rel="stylesheet" href="../../style.css" type="text/css"> |
| 9 | +</HEAD> |
| 10 | +<BODY> |
| 11 | + |
| 12 | +<h1>Dropping sent and received data</h1> |
| 13 | + |
| 14 | +Data sent or received may be lost for various reasons.<br> |
| 15 | +The locations where drops occur and the solutions are as follows: |
| 16 | + |
| 17 | +<h2 id="send">1. Sending Data</h2> |
| 18 | + |
| 19 | +<pre> |
| 20 | + s1 s2 s3 s4 program |
| 21 | +Tera Term ---> Send buffer ---> OS,driver ---> (sshd,telnet,pipe) ---> UART chip ---> pty + shell, other program |
| 22 | + in Tera Term UART chip (serial ) driver,OS Embedded programs, etc. |
| 23 | +</pre> |
| 24 | + |
| 25 | +<dl> |
| 26 | + <dt>s1. Sned buffer in Tera Term</dt> |
| 27 | + <dd> |
| 28 | + It is unlikely to drop.<br> |
| 29 | + Data is sended while watching free size of send buffer OutBuff[](16KB). |
| 30 | + </dd> |
| 31 | + <dt>s2. OS,UART chip(sender)</dt> |
| 32 | + <dd> |
| 33 | + It is unlikely to drop.<br> |
| 34 | + Depending on hardware and driver version, various problems may occur, including BSoD.<br> |
| 35 | + You can see details of driver in Tera Term serial port settings.<br> |
| 36 | + Tera Term will suggest 4KB as the recommended size of the send buffer to the communication device in <a href="https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setupcomm">SetupComm()</a>. |
| 37 | + </dd> |
| 38 | + <dt>s3. transmission path</dt> |
| 39 | + <dd> |
| 40 | + Cable quality, cable length, crosstalk, signal interference, etc. can cause errors and drops.<br> |
| 41 | + In serial, there is no resend process with error. If error occurs in data, data is dropped.<br> |
| 42 | + For TCP/IP, pipe, it is unlikely to drop. |
| 43 | + </dd> |
| 44 | + <dt>s4. UART chip,OS(receiver)</dt> |
| 45 | + <dd> |
| 46 | + Receiving data beyond processing capacity of PC (CPU) (when PROGRAM does not pick up received data from OS or chip) or other causes, |
| 47 | + Receive buffer of OS (driver) or UART chip are overflows and data is dropped.<br> |
| 48 | + OS (driver) or program handles flow control depends on implementation.<br> |
| 49 | + In TCP/IP, flow control and resend on error are performed, and in most cases, |
| 50 | + protocol stack in OS handles these processes.<br> |
| 51 | + 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. |
| 52 | + </dd> |
| 53 | + <dt>program</dt> |
| 54 | + <dd> |
| 55 | + Dropped due to receive buffer overflow, etc. in program.<br> |
| 56 | + When receive buffer is about to overflow in pseudo terminal(pty), 0x07(BEL) is sent and Tera Term will ring bell. |
| 57 | + </dd> |
| 58 | +</dl> |
| 59 | + |
| 60 | +<h2 id="send">2. Receiving Data</h2> |
| 61 | + |
| 62 | +<pre> |
| 63 | + r1 r2 r3 r4 program |
| 64 | +Tera Term ---> Receiving buffer ---> UART chip ---> (sshd,telnet,pipe) ---> OS,driver ---> pty + shell, other program |
| 65 | + in Tera Term driver,OS (serial ) UART chip Embedded programs, etc. |
| 66 | +</pre> |
| 67 | + |
| 68 | +<dl> |
| 69 | + <dt>program</dt> |
| 70 | + <dd> |
| 71 | + It is unlikely to drop.<br> |
| 72 | + Drop due to send buffer overflow, etc. in program.<br> |
| 73 | + </dd> |
| 74 | + <dt>r4. OS,UART chip(sender)</dt> |
| 75 | + <dd> |
| 76 | + It is unlikely to drop.<br> |
| 77 | + Depending on hardware and driver version, various problems may occur.<br> |
| 78 | + </dd> |
| 79 | + <dt>r3. transmission path</dt> |
| 80 | + <dd> |
| 81 | + Cable quality, cable length, crosstalk, signal interference, etc. can cause errors and drops.<br> |
| 82 | + In serial, there is no resend process with error. If error occurs in data, data is dropped.<br> |
| 83 | + For TCP/IP, pipe, it is unlikely to drop. |
| 84 | + </dd> |
| 85 | + <dt>r2. UART chip,OS(receiver)</dt> |
| 86 | + <dd> |
| 87 | + Tera Term will suggest 16KB as the recommended receive buffer size for the communication device in <a href="https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setupcomm">SetupComm()</a>.<br> |
| 88 | + 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.<br> |
| 89 | + In TCP/IP, flow control and resend on error are performed, and in most cases, |
| 90 | + protocol stack in OS handles these processes.<br> |
| 91 | + 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. |
| 92 | + <p> |
| 93 | + Receive buffer size of main UART chips and drivers |
| 94 | + <pre> |
| 95 | +8250 UART no FIFO |
| 96 | +16550 UART 16 Byte FIFO |
| 97 | +FT232R 256 Byte receive buffer |
| 98 | +TTY drive(Linux 2.6.26) 4KB (<a href="../reference/sourcecode.html#ttssh">SSH Design and Implementation in TTSSH</a>) |
| 99 | + </pre> |
| 100 | + </dd> |
| 101 | + <dt>r1. Receiving buffer in Tera Term</dt> |
| 102 | + <dd> |
| 103 | + 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.<br> |
| 104 | + If Tera Term processing (screen drawing, log output, macro processing, etc.) is delayed, the receive buffer will overflow and data will be dropped. |
| 105 | + </dd> |
| 106 | +</dl> |
| 107 | + |
| 108 | +<h2 id="solution">3. Solution</h2> |
| 109 | + |
| 110 | +<ol> |
| 111 | + <li>Checking the Connection Method</li> |
| 112 | + For serial connections, make sure the <a href="../../menu/setup-additional-serialport.html#Speed">Serial parameters (baud rate, bit length, etc.)</a> match between the sender and receiver.<br> |
| 113 | + Setting flow control can help prevent receive buffer overflow.<br> |
| 114 | + Hardware flow control (RTS/CTS, DSR/DTR) is recommended.<br> |
| 115 | + <br> |
| 116 | + <li>If the transmitted data is dropped</li> |
| 117 | + This is thought to be due to insufficient processing performance of the opposing device "s4. UART chip,OS(receiver)" and "program".<br> |
| 118 | + The solution is to slow down the communication speed and reduce the amount sent per unit time.<br> |
| 119 | + For serial connections, lower the baud rate.<br> |
| 120 | + If the baud rate cannot be changed, such as in embedded devices, set a send delay to prevent the receive buffer from overflowing.<br> |
| 121 | + A send delay is also effective in cases where line feeds or screen clearing take time, such as with LCD controllers, |
| 122 | + and sending the next command before the processing is complete causes problems.<br> |
| 123 | + <br> |
| 124 | + <li>If received data is dropped</li> |
| 125 | + This is probably due to insufficient processing performance in "r2. UART chip,OS(receiver)" and "r1. Receiving buffer in Tera Term"<br> |
| 126 | + 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.<br> |
| 127 | + The solution is to slow down the communication speed and reduce the amount sent per unit time.<br> |
| 128 | + For serial connections, lower the baud rate.<br> |
| 129 | + <br> |
| 130 | + <li>Others</li> |
| 131 | + 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.). |
| 132 | +</ol> |
| 133 | + |
| 134 | +</BODY> |
| 135 | +</HTML> |
0 commit comments