On 05.01.2022 16:37:22, Sergey Organov wrote: > Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> writes: > > > On 05.01.2022 16:00:34, Sergey Organov wrote: > >> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > >> > >> > On Tue, Jan 04, 2022 at 11:32:03AM +0100, Tomasz Moń wrote: > >> >> Triggering RX interrupt for every byte defeats the purpose of aging > >> >> timer and leads to interrupt starvation at high baud rates. > >> >> > >> >> Increase receiver trigger level to 8 to increase the minimum period > >> >> between RX interrupts to 8 characters time. The tradeoff is increased > >> >> latency. In the worst case scenario, where RX data has intercharacter > >> >> delay slightly less than aging timer (8 characters time), it can take > >> >> up to 63 characters time for the interrupt to be raised since the > >> >> reception of the first character. > >> > > >> > 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? > >> > >> I don't like the idea of dynamic threshold as I don't think increased > >> complexity is worth it. > >> > >> In fact the threshold works "properly" on any baud rate, as maximum > >> latency is proportional to the current baud rate, and if somebody does > >> care about *absolute* latency, increasing baud rate is the primary > >> solution. > > > > Nope - this only works if you have both sides under control.... Which is > > not the case in our $CUSTROMER's use case. > > Yep, if one can't use primary solution, they need to come up with > something else. Please don't break existing use cases while improving the kernel. > Where is that historical "low-latency" bit, by the > way? ...has been removed: https://lore.kernel.org/all/20210105120239.28031-11-jslaby@xxxxxxx/ Is there an option to bring that back? 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
