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. Where is that historical "low-latency" bit, by the way? Thanks, -- Sergey Organov
