On 4/12/2022 1:22 PM, Cole Walker wrote:
> Hi Jake, I'm still working my way through this issue. I was looking at
> the ice driver code and I noticed this comment in ice_gnss.c (1.7.16):
>
> L96
> /* Send the data to the tty layer for users to read. This doesn't
> * actually push the data through unless tty->low_latency is set.
> */
> tty_insert_flip_string(port, buf, i);
> tty_flip_buffer_push(port);
>
> Given that I am running on a real-time system, do you think there is any
> chance that this could be contributing? How would I go about testing this?
>
Really not sure. If this ends up going to an output pin of some kind you
could try measuring the actual latency of the output pin but I'm not
familiar with the GNSS code.
> I'm thinking I need to rebuild the driver and add something after L289?
>
> /* Initialize the tty driver*/
> tty_driver->owner = THIS_MODULE;
> tty_driver->driver_name = dev_driver_string(dev);
> tty_driver->name = (const char *)ttydrv_name;
> tty_driver->type = TTY_DRIVER_TYPE_SERIAL;
> tty_driver->subtype = SERIAL_TYPE_NORMAL;
> tty_driver->init_termios = tty_std_termios;
> tty_driver->init_termios.c_iflag &= ~INLCR;
> tty_driver->init_termios.c_iflag |= IGNCR;
> tty_driver->init_termios.c_oflag &= ~OPOST;
> tty_driver->init_termios.c_lflag &= ~ICANON;
> tty_driver->init_termios.c_cflag &= ~(CSIZE | CBAUD | CBAUDEX);
> # Something like
> tty_driver->low_latency = 1;
>
>
You could try this, but Richard seemed to think it won't do much in the
RT setup..
> I have also been running the change described below for a few days and
> the master offset is incredibly stable when ts2phc_slave_offset() is
> changed to
>
> if (source_ts.tv_nsec > 500000000) {
> source_ts.tv_sec++;
> } else {
> source_ts.tv_sec++;
> pr_info("Timing went weird, advancing tv_sec anyways.");
> }
>
I'm not an expert on ts2phc so I don't know if this change is correct.
This basically just always enforces the tv_sec incrementing. It doesn't
feel correct at a glance.. but as I said I'm no expert in this program.
> But that does not really address the root cause of the nmea delay spikes.
>
I suspect given your RT system that the tty issues are the cause. I
think Richard is correct that the issue will be that without using a
kthread and proper scheduling priority the RT kernel can end up starving
the background work, which might be the cause of some of the instability
here...
>
> Thanks for your input on any of these points,
>
Perhaps someone else on the list here can help with whether that ts2phc
change is safe/correct or not.
Thanks,
Jake
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
