CPU behavior at high UART baud rates.

[Mr.Current]

Hello folks,
I have a general question – what is expected %CPU usage rate when using UART at higher baud rates (400×492-byte frames/sec. at 3M baud specifically)?
The problem that I have is the following: once data is being sent to OSD, CPU load increases (monitored with top, %idle is at ~50%).
The test I do looks like this:
1. Connect FT4232 to UART0 on OSD
2. Set baud rate on OSD to 3M and raw data transfer with stty -F /dev/ttyS0 speed 3000000 raw (the expected behavior for the device is to send raw data, but I’m suspicious, whether raw option sets the flags right)
3. Call cat /dev/ttyS0 > logs &
4. Create a random file 19680 bytes long on another machine with dd if=/dev/urandom of=~/random-frame.txt bs=1 count=19680
5. Launch hterm and send the data periodically every 0.1s to OSD

Tests are done for ttyS0 but same problem applies to ttyS1, where it was noticed originally.

I use custom, minimalistic Linux built with buildroot, kernel 4.19.50 with 8250 UART drivers with DMA enabled.

PS.
When I tried to re-create the above steps hours later, %idle was at 70 instead of 50, but still suspiciously high to me. The only modifications in the meantime was me playing around with different flags and VMIN settings in termios structure in /dev/ttyS0 (which should go to default after each reset).

Best regards,
MrCurrent

Attachments:

1. 

   Screenshot-from-2019-09-19-16-03-42.png
   

[Neeraj Dantu]

MC,

Please accept my apologies for this delayed reply.

Coming to the issue at hand, the screenshot attached indicates a number of kworker threads indicating internal kernel activity that may/may not be related to the UART transfers. Have you tried to alter the test parameters such as speed/period to see how it effects the CPU usage?

It is clear that the DMA is functional as the CPU activity would be way higher for the test parameters. Can you provide an update here on the issue?

Best,

Neeraj

[Mr.Current]

Hello Neeraj,
No problem, right now I’m fighting with another circuit.
Yes, indeed, the DMA is working, however while browsing the web for potential solution, I encountered mentions of some interrupt problems in am3358’s UART, which are beyond my current state of knowledge.

When it comes to speed tests, I had to roll down the baud rate significantly to stop the issue from showing (way below 900k, cant remember exact number, but it was beyond the point of usability for my application).

Additionally, I made some fiddling with PocketBeagle (I needed USB slot for these tests). First I ran the same test as in original post (FTDI to UART0, BAUD 3M, resulting %idle=71-77%), and then modified it with a connection like this:
PC (hterm) <—usb—> FTDI#1 <—uart—> FTDI#2 <—usb—> PocketBeagle
The second test results are following:
accuracy: 1944100/1968000 bytes (98,7%)
%idle:91-94

Additionally, time it took to send the data through FTDI#1-FTDI#2 was in match with timing requested from hterm application (UART0 communication on the same PocketBeagle took 2-3 times longer than requested).

Best regards,
MC

[Neeraj Dantu]

MC,

Thanks for the update.

We came over some interesting discussion on this issue: https://lists.gt.net/linux/kernel/2352859. The discussion does seem to indicate a limitation as to the handling capability of the UART interface at higher speeds.

As the USB interface can handle much higher data rates, the CPU is not being tasked as much. Glad you were able to find a solution that works.

Please let us know if you have more questions.

Best,

Neeraj

[Author]

Posts