Usefulness of COM port latency
Asked Answered
P

3

1

As you can see in this tutorial, the default latency timer for the COM port is 16ms.
COM Port Latency

But in most cases we want the minimum latency.

On the internet we see a lot of explanation on why this value should be as small as possible, but never when it is good to choose a large value.

So why the default value is 16ms when it could be 1ms ?

Pickens answered 28/1, 2021 at 16:13 Comment(0)
F
1

It's more CPU-efficient to transfer data in larger chunks. If you have a 1ms latency, your serial port may cause up to 1000 transfers per second through the OS (interrupt, lower handler, context switch, user callback, etc). With a 16ms latency, you would process the same amount of data in only 60 transfers, with each transfer handling a larger block.

Reducing the interrupt count is a lot less useful on a modern multicore system than it was on a single core, where all time spent in a serial (or USB) interrupt meant delays in processing other I/O such as disk transfers. Now that work can be split among multiple cores, although inefficient processing still has a bad effect on e.g. battery life.

Fortify answered 28/1, 2021 at 16:39 Comment(0)
S
2

I've been working on Visual C++ code for my Serial Wombat GPIO expander project. It connects via UART and uses 8 byte packets for communication. Each transaction requires 8 bytes to be sent and an 8 byte response to be processed. Latency here is paramount, because the faster you can process packets, the faster you can take measurements or drive IO. More data per interrupt doesn't help, because its effectively half-duplex. I'm using an FTDI adapter under Windows 10, using the default drivers installed when you plug it in. For the serial receive, I'm setting up the timeouts as follows:

COMMTIMEOUTS timeouts = { 0 };
     timeouts.ReadIntervalTimeout = MAXDWORD;
     timeouts.ReadTotalTimeoutConstant = 0;
     timeouts.ReadTotalTimeoutMultiplier = 0;
     timeouts.WriteTotalTimeoutConstant = 10;
     timeouts.WriteTotalTimeoutMultiplier = 1;

which makes RX not wait for any bytes to come in, only return the ones that are available. Then I read repeatedly until I have enough bytes for the 8 byte response:

uint8_t buffer[2];
     bool result = ReadFile(hSerial, buffer, 1, &dwBytesRead, NULL);
     if (dwBytesRead > 0)
     {
         return(buffer[0]);
     }
     else
     {
         return(-1);
     }

By default, I see the roughly 16mS delay you're seeing looking on a logic analyzer. However, if you go into the windows device manager, choose Properties for the FTDI Com port, go to Port Settings and Advanced, you get this gem: FTDI Screen Capture

Change the Latency Timer to 1 mS to maximize responsiveness. Looked at the result on the logic analyzer, and it works exactly as expected.

Scroggins answered 17/3, 2022 at 2:36 Comment(1)
The part about changing the latency in the device manager made ALL the difference. Thanks for pointing that out.Smell
F
1

It's more CPU-efficient to transfer data in larger chunks. If you have a 1ms latency, your serial port may cause up to 1000 transfers per second through the OS (interrupt, lower handler, context switch, user callback, etc). With a 16ms latency, you would process the same amount of data in only 60 transfers, with each transfer handling a larger block.

Reducing the interrupt count is a lot less useful on a modern multicore system than it was on a single core, where all time spent in a serial (or USB) interrupt meant delays in processing other I/O such as disk transfers. Now that work can be split among multiple cores, although inefficient processing still has a bad effect on e.g. battery life.

Fortify answered 28/1, 2021 at 16:39 Comment(0)
B
0

The features you are looking at are specially provided by the vendor's hardware and device drivers and are not supported by most other vendors.

The RS232C port and the standard software API do not have an equivalent feature.

It's a good idea to ask the vendor that provides it for more information, such as why it provides that feature and how to use it.

Bunt answered 28/1, 2021 at 23:52 Comment(4)
Most vendors may not give the user a configuration interface, but the same latency tradeoffs exist for any port containing a FIFO, and for certain for ports which are connected through a secondary bus such as USB. Only the very old 8250 and 16450 lack a FIFO. The standard register interface for the 16550 does allow configuring the FIFO depth.Fortify
Does the FIFO depth you're talking about exist as a 16550 FIFO buffering in Microsoft's standard UI? Figure 22-7 of 22.4 Installing and Configuring Serial Port Hardware It's probably different from the Latency Timer in the question.Bunt
Yes, that's configurable there. The latency timer is roughly equivalent when you get a USB bus involved, as it has the same effect (only interrupting the processor when a larger block of data is available).Fortify
I think they are similar but not the same, but that's the opinion of the individual. It depends on the desired effect.Bunt

© 2022 - 2024 — McMap. All rights reserved.