Data Transfer Performance Guidelines

Buffer size

The larger the buffers that are used, the fewer requests required to the Serial Communications Server. Use larger buffers to reduce the application's CPU requirements.

Global Buffers

To create or destroy a Descriptor requires CPU time to complete the constructor or destructor. Performance is increased by reducing the number of requests to create or destroy a Descriptor. To reduce the number of Descriptor create requests, create a global Descriptor for the data buffer. A global Descriptor is a Descriptor that is available to all functions in the application.

The RComm::Read() and RComm::Write() functions are available in variants that take a length parameter. Use the length parameter when a global descriptor is used. If the length parameter is not used, the RComm::Read() and RComm::Write() APIs use the length of the Descriptor to define the number of characters to read or write.

Indexing descriptors

Descriptors have C [] array indexing operators. Do not use the C [] array indexing operators since pointer arithmetic is faster.

Read Requests

Configure the ports so that the Serial Communications Server manages all the processing:

• Set time-outs to trap error conditions

• Set termination characters for the protocol. See How to Terminate Read Requests Early: Tutorial

Write Requests

Configure the ports so that the Serial Communications Server manages all the processing:

• Set ports to return early when no response from the remote device is expected, or where there is a lot of processing to prepare the next block of data to be sent. See How to Terminate Write Requests Early: Tutorial

ReadOneOrMore()

If RComm::ReadOneOrMore() is used in a loop, the function may cause slower performance. This slower performance is the result of the loop reading smaller and smaller blocks until on single characters are read.

The Glass Teletype example uses a time-out of one tenth of a second. This time-out has two purposes:

• The time-out simulates the delay effect of a terminal

• The time-out allows the RComm::Read() API to be used while not causing a large load on the CPU

If the time-out expires, the Glass Teletype example then calls ReadOneOrMore().

The trade-off is that the RComm::Read() call to the Serial Communications Server has to be renewed 10 times every second even when no data is being transferred. This was considered a smaller overhead than that incurred if data were coming in rapidly and as a result ReadOneOrMore() was called up to 2000 times every second.