On 05.01.2022 11:37:05, Greg Kroah-Hartman wrote: > On Wed, Jan 05, 2022 at 08:59:09AM +0100, Tomasz Moń wrote: > > On 04.01.2022 23:49, Uwe Kleine-König wrote: > > > On Tue, Jan 04, 2022 at 12:38:01PM +0100, Greg Kroah-Hartman wrote: > > >> On Tue, Jan 04, 2022 at 12:13:06PM +0100, Tomasz Moń wrote: > > >>> On 04.01.2022 11:54, Greg Kroah-Hartman wrote: > > >>>> Why can't you do this dynamically based on the baud rate so as to always > > >>>> work properly for all speeds without increased delays for slower ones? > > >>> > > >>> Could you please advise on which baud rates to consider as slow? Does it > > >>> sound good to have the old trigger level for rates up to and including > > >>> 115200 and the new one for faster ones? > > >> > > >> You tell me, you are the one seeing this issue and are seeing delays on > > >> slower values with your change. Do some testing to see where the curve > > >> is. > > > > While the increased latency due to this change is undeniable, it is > > important to note that latency is not everything. There are applications > > where the latency is crucial, however using Linux for such applications > > is questionable. Linux is not a Real Time Operating System after all. > > Yes, Linux can be used in real time situtations just fine, look at the > RT patchset for proof of that. > > So let's not make things any worse for no good reason if at all > possible. +1 We have a $CUSTOMER, where serial latency is crucial. And we have a task to cut down latencies and jitter even more. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
