Hi,
I'm currently testing a RT application that communicates with sensor
hardware using a tty serial port. The application polls the tty port
(non-blocking) in a user space thread (priority 80) for incoming data.
On a raspberry PI3 (ttyAMA0), with kernel 4.4.9-rt17, response times <
650usec are achieved, which is fine.
Any version equal or above 4.4.12-rt20 will increase response peaks to
(about 0.1%) > 2msec, with some peaks > 5msec.
cyclictest doesn't reproduce this, so I suspected a change in the tty
driver, or related to raspberry pi.
I found that, by reverting the attached patch, response times return
to < 650usec. I suspect it has something to do with a change in the
read poll.
I'd like to help solving this issue, can anyone give me some pointers
on how to continue?
Regards,
Niels Kolthoff
Gesendet: Montag, 12. Juni 2017 um 15:48 Uhr
Von: "Niels Kolthoff" [off-list ref]
An: linux-rt-users@vger.kernel.org
Betreff: RT and tty communication
Hi,
I'm currently testing a RT application that communicates with sensor
hardware using a tty serial port. The application polls the tty port
(non-blocking) in a user space thread (priority 80) for incoming data.
On a raspberry PI3 (ttyAMA0), with kernel 4.4.9-rt17, response times <
650usec are achieved, which is fine.
Any version equal or above 4.4.12-rt20 will increase response peaks to
(about 0.1%) > 2msec, with some peaks > 5msec.
When you use interrupt driven input, you have to wait for the interrupt and that depends on parameters like at how many bytes in the FIFO an interrupt is triggered.
But you can use polling instead of waiting for IRQ, e. g. check every 40 microseconds for new bytes.
And you should use hardware with low latency, e. g. an PCIe card and NOT an USB-RS-232/422/485 adapter.
Regards,
Rolf
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2017-06-13 12:29:21
On 2017-06-12 15:48:49 [+0200], Niels Kolthoff wrote:
Hi,
I'm currently testing a RT application that communicates with sensor
hardware using a tty serial port. The application polls the tty port
(non-blocking) in a user space thread (priority 80) for incoming data.
On a raspberry PI3 (ttyAMA0), with kernel 4.4.9-rt17, response times <
650usec are achieved, which is fine.
Any version equal or above 4.4.12-rt20 will increase response peaks to
(about 0.1%) > 2msec, with some peaks > 5msec.
cyclictest doesn't reproduce this, so I suspected a change in the tty
driver, or related to raspberry pi.
I found that, by reverting the attached patch, response times return
to < 650usec. I suspect it has something to do with a change in the
read poll.
I'd like to help solving this issue, can anyone give me some pointers
on how to continue?
My guess is that the newly introduced tty_buffer_flush_work() waits
until all in-kernel data is processed before returning -EAGAIN (if the
buffer is empty) for the non-blocking case which unbreaks ssh. So this
wait could blocking you for longer than required.
If that is really it, then this is what could be optimized :)
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2017-06-13 12:32:52
On 2017-06-12 19:39:03 [+0200], rolf.freitag@email.de wrote:
When you use interrupt driven input, you have to wait for the interrupt and that depends on parameters like at how many bytes in the FIFO an interrupt is triggered.
But you can use polling instead of waiting for IRQ, e. g. check every 40 microseconds for new bytes.
No, I think it is better to configure things properly and wait for the
interrupt to occur instead of busy-polling for things to happen.