[time-nuts] GPS message jitter (was GPS for Nixie Clock)

Martin Burnicki martin.burnicki at burnicki.net
Tue Jul 19 10:26:05 EDT 2016

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 <hmurray at megapathdsl.net> wrote:
>> jimlux at 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.


More information about the time-nuts mailing list