![]() |
![]() |
Size of the Routing Buffers and How They Affect the Device ServerQuestion: I am wondering if the capacity of the internal serial buffers of the Device Server is enough for my serial application. How much data can the buffers hold (transmit)? Answer: Just checking the physical capacity of the serial buffers of the Device Server is not a correct approach. Several other factors must be taken into consideration. The ability of the Device Server to transmit (without losses) the serial data of a certain size also depends on the selected transport protocol and flow control options. Routing buffersRouting buffers, as the name implies, hold the data being routed between the Ethernet and serial port of the Device Server. We refer to these buffers as “routing buffers” and not “serial buffers” because they could be called “Ethernet buffers” just as well. There are two routing buffers, one for each routing direction (Serial–>Ethernet and Ethernet–>Serial). Notice that total serial–>Ethernet buffer capacity is listed as 510 (255) bytes. This means that while the DS100 has a 510-byte buffer, it is guaranteed to receive 255 bytes without using RTS/CTS handshaking. When RTS/CTS handshaking is enabled the DS100 (EM100) is guaranteed to reliably receive all 510 bytes. Buffer Capacity in Second-Generation ModelsIn Second-Generation Tibbo devices, such as EM120, EM200 and EM202, the Routing Buffer size is 8KB (Kilobytes) in each of the two buffers (a total of 16KB). How Flow Control and Transport Protocol affect your calculationsBut do the above buffer capacities mean that you can only transmit 510 (255) bytes in the Serial–>Ethernet direction and 510 bytes in the Ethernet–>Serial direction? Will the buffers overflow if you attempt to send more data than that? To answer this question you need to take into account the transport protocol and the flow control option. The table below shows the possibility of buffer overflows in different operating modes:
As you can see from the Table above the serial–>Ethernet buffer can overflow when the RTS/CTS flow control is disabled and will never overflow when the RTS/CTS flow control is enabled (provided that your serial device supports the RTS/CTS handshaking). The Ethernet–>serial buffer can overflow when the UDP/IP transport protocol is used and will never overflow with TCP/IP transport protocol (this is because the TCP/IP has its own reliable flow control mechanism). When you are using the TCP/IP transport protocol and the RTS/CTS flow controlIf you are using the TCP/IP transport protocol and the RTS/CTS flow control then you can reliably transmit the data of any size. You can pass megabytes upon megabytes of data through the Device Server, and simultaneously in both directions too! When you are using the UDP/IP transport protocolUDP/IP is a connectionless protocol, it doesn't have any built-in mechanism to prevent the receiving buffer from overflowing. You need to make sure that the data you send does not overflow the Ethernet–>serial buffer. Just sending less than 510 bytes at a time won't be enough- you need to estimate how fast the data is going out through the serial port. When you are not using the RTS/CTS flow controlBe careful not to overload the serial–>Ethernet buffer. If the Ethernet channel is not very congested so the Ethernet packets can be sent without any delays the DS100 (EM100) can reliably route a constant serial data stream at speeds up to 38400bps. However, the Ethernet network is not a stable media with guaranteed minimum throughput. Congestions can spontaneously occur on the Ethernet network preventing the DS100 from sending out the data fast enough to keep the serial–>Ethernet buffer from overflowing. Using the Device Server with "stream" systemsIn practice all serial devices that are designed to process infinite serial data streams support RTS/CTS flow control. To make the Device Server work reliably with such devices enable the RTS/CTS flow control and use the TCP/IP transport protocol. Using the Device Server with "command-reply" systemsMany serial devices utilize command-reply communications protocols that use some form of preformatted packets for data exchange. Typically there is a “master” device that sends commands to its “slaves” which send back their replies. Many such systems do not support RTS/CTS flow control. The Device Server will work reliably with such a device if the maximum length of command (or reply) does not exceed its internal buffer capacity. For the serial–>Ethernet direction you can consider this capacity to be 510 bytes for baudrates of up to 38400bps and 255 bytes for higher baudrates. For the Ethernet–>serial direction this capacity is 510 bytes. © Tibbo Technology Inc. 2001-2009 Contact Us | Account |