CoolTerm slow after connection on Linux Mint

[roger]

Hi,

thanks for your feedback. This is interesting. CoolTerm treats all devices it thinks are serial devices exactly the same way. I have no idea why it would behave differently with one it identifies as ttyUSB0. I'm not a Linux expert. Do you have any insight on what will lead to something being identified as ttyUSB0 and some other thing as ttyACM0? Normally, when I see difference in behavior between devices, it's related to the device driver (at least this has been my experience with Windows), where devices with one USB/Serial chipset behave differently than devices with another one (e.g. FTDI versus Prolific chips). Googling tells me the following:

The main difference between ttyUSB0 and ttyACM0 on Linux is that ttyUSB0 is used by more specific drivers, while ttyACM0 is used for devices that conform to the USB Communications Device Class (CDC) standard:
ttyUSB0: Used by vendor-specific drivers
ttyACM0: Used for devices that conform to the USB Communications Device Class (CDC) standard, specifically its Abstract Control Model (ACM)

I'm not sure what that means, exactly, but perhaps my suspicion of the driver is on to something? Do you know if there is an updated driver available for your ttyUSB0 identified devices?

Roger

[chr.wiese65]

Hello Roger,

I cannot confirm (with my setup) that CoolTerm reacts differently with ttyACMx and ttyUSBx. My current embedded hardware has a simple CH552 chip ("daplink" programmer) as a serial/usb adapter (which identifies itself as ttyACM0). With this I can see the problems described at the beginning. To compare the different types, I tried the following: I connected two usb/serial adapters (FTDI, appears under Linux as ttyUSB0 and 1) on the rs232 side and also started two CoolTerm instances, and then transferred a very large text file from one CoolTerm to the other using “send file”. The behavior is exactly the same as with the CH552.

Now to version 2.3.0.b6 (thank you very much for making this available to me ). In fact, the CPU load stays the same all the time, but the scrolling seems to stutter and the scroll bar moves up and down unpleasantly (apparently whenever the buffer is full and is emptied again). It doesn't matter whether "Avoid plain text flicker" is on or off. Here too, I tested it with my CH552 hardware and two FTDI adapters in loopback, no difference.

Best regards, Christian

[roger]

Hi Christian,

thanks for testing the new build. Is it also stuttering when you test it in your normal use case? Not sending a large file from one CoolTerm to another, but the one where you first noticed that the CPU load was increasing when you leave it running? Sending a large file from one to another at high speed may be a bet of an extreme use case, but I'll look into it.

Roger

[roger]

Hi Christian,

thanks for testing the new build. Is it also stuttering when you test it in your normal use case? Not sending a large file from one CoolTerm to another, but the one where you first noticed that the CPU load was increasing when you leave it running? Sending a large file from one to another at high speed may be a bet of an extreme use case, but I'll look into it.

Roger

[roger]

Christian, @brown_roy,

The latest build you guys tested removes data from the top of the text display when the receive buffer is full and new data arrives. For each new byte it adds at the bottom, it removes one from the top. This solves the problem with the CPU load and memory increasing over time. However, as Christian has already found, it makes the display stutter when the buffer is full and large amounts of data are being received, tested by sending a large file from one CoolTerm window to another. But how is it behaving in other situations on your systems? Is it stuttering when you do other things? If there is any stutter in any use case, then it should be dramatically less than with "avoid plain text flicker" turned off.

I don't have a dedicated Linux system. I can only test with Ubuntu running on WSL on a Windows 11 system, and I can see almost no stutter with the new build with the test case of sending one file from one window to another, and I can not see any stutter in any other use case, where one CoolTerm window is receiving data over the serial port at not super-high data flow rates, where turning off "avoid plain text flicker" makes it basically unusable.
I assume different Linux distributions behave differently, and I don't have a Mint system to test with.

I have experimented with a slightly different build where, instead of removing one byte at the top for every received byte at the bottom of the text display when the buffer is full, it lets the display fill up to twice the size of the receive buffer and then prunes it 1x the size. For example, if you set the receive buffer size to 10,000, CoolTerm lets the text display fill up to 20,000 bytes and then removes 10,000 bytes form the to reduce it back to 10,000. With this build, I don't see any stutter at all. I will send you the link to this build by e-mail for testing. Keep an eye out for that.

Cheers,

Roger

[chr.wiese65]

Hello Roger,

your build 1357 (help->about says 1358) made my day! The solution of making the buffer twice as big and always holding at least as much data as configured sounds plausible and works great. No more flickering or stuttering, tried with several RS232/USB adapters and even with 230400 baud. I often let my applications run for hours or even days and record the log data in a file, sometimes up to 100 lines of text per second - now the live view is so convenient that I can always leave it open and it no longer distracts me from my work.

I have only been working mainly with Linux for two years (before that exclusively Windows, my serial terminal tool was teraterm there), but now I know a little better that I will gradually say goodbye to Windows, it develops too much of a life of its own and does things that I have not under control, maybe I'm just getting too old for it

Great work!
Best regards Christian

[roger]

Great! I’m glad the new build works better. Thanks for sanity-checking it for me!

Roger