John Ackermann N8UR wrote: > Long ago I measured the impact of the linux low_latency flag on a 16550 UART. > I don't know where that data is sitting now, but I remember that it made a > significant difference. > >> On Jul 18, 2016, at 9:59 PM, Hal Murray <hmur...@megapathdsl.net> wrote: >> >> >> jim...@earthlink.net said: >>> except that virtually every UART in use today has some sort of buffering >>> (whether a FIFO or double buffering) between the CPU interface and the bits >>> on the wire, which completely desynchronizes the bits on the wire from the >>> CPU interface. >> >> The idea was to reduce the CPU load processing interrupts by batching things >> up. >> >> Some of those chips generate an interrupt when the see a return or line-feed >> character. >> >> Most of them have an option to disable that batching. On Linux the >> setserial >> command has a low_latency option. I haven't measured the difference. It >> would be a fun experiment.
AFAIK the low_latency flag just sets the UART's FIFO threshold to 1, i.e. the UART generates an IRQ when the 1st character came in. If you don't set this flag then the FIFO threshold is set to something different. A *very* quick search on the Linux source code seems to indicate the default threshold is 16 in current kernels, but if I remember correctly then it was 4 or 8 in earlier kernel versions. If you need to timestamp the 1st character of the serial time string then things are easy. For example, for Meinberg time strings the on-rtime character is the 1st character, STX (0x02), and subsequent characters are sent without gap. So it doesn't matter much if you get an IRQ after the 1st character, and compensate for 1 character only, or the IRQ occurs after the 8th character, and you compensate for 8 characters. But of course you need to know the current FIFO threshold. I think if you need to timestamp e.g. the CR of LF at the end of a string which eventually has even variable length then the timing may vary depending on the actual string length. E.g., with a FIFO threshold of 16 the first IRQ is generated when 16 characters have been received, but if the whole string is e.g. only 30 characters then only 14 characters follow after the first part, and the FIFO threshold (16) is never reached by that single string. I'm not sure if the UART then generates an IRQ anyway after some kind of timeout, but this seems to make exact timing quite a bit more tricky. Martin _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.