Thread: [Linuxptp-users] phc2sys exists with a Connection Timed Out error
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Bernie E. <be...@gm...> - 2023-05-12 23:28:59
|
Hello, We are using linuxtptp 3.1.1 on an Intel i7 NUC running Ubutnu 18.04 with kernel 5.4.0-generic.. We have linuxptp running on the Intel NUC configured as an OC. Our grandmaster is a 3rd party device. This is all running on a stand-alone network dedicated to PTP. Every few hours, our phc2sys will stop with this error: phc2sys[264069.922]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out phc2sys will stop but ptp4l will continue to run. This error appears to originate from the sysoff_precise function;Doesn't this error just mean when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy? Wouldn't it be better to just 'log' the error and continue, or does even one occurrence of this error mean something is misconfigured in my setup? tia,bernardo |
|
From: Miroslav L. <mli...@re...> - 2023-05-17 10:24:18
|
On Fri, May 12, 2023 at 04:28:40PM -0700, Bernie Elayda wrote: > phc2sys will stop but ptp4l will continue to run. This error appears to > originate from the sysoff_precise function;Doesn't this error just mean > when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy? > Wouldn't it be better to just 'log' the error and continue, or does even > one occurrence of this error mean something is misconfigured in my setup? I think this phc2sys issue was fixed after 3.1.1 in git. Please try that and see if it still exits. -- Miroslav Lichvar |
|
From: Bernie G. <be...@gm...> - 2023-05-17 17:46:52
|
Thank you! We have the HEAD and re-running our test overnight. Will report back on our results tomorrow regards,bernardo Sent from fruit phone > On May 17, 2023, at 3:24 AM, Miroslav Lichvar <mli...@re...> wrote: > > On Fri, May 12, 2023 at 04:28:40PM -0700, Bernie Elayda wrote: >> phc2sys will stop but ptp4l will continue to run. This error appears to >> originate from the sysoff_precise function;Doesn't this error just mean >> when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy? >> Wouldn't it be better to just 'log' the error and continue, or does even >> one occurrence of this error mean something is misconfigured in my setup? > > I think this phc2sys issue was fixed after 3.1.1 in git. Please try > that and see if it still exits. > > -- > Miroslav Lichvar > |
|
From: Bernie E. <be...@gm...> - 2023-05-18 16:15:13
|
Hello, I have an update. I obtained the HEAD for linuxptp yesterday and re-ran my setup. Unfortunately, phc2sys failed again with a Connection timed out: phc2sys[470789.265]: CLOCK_REALTIME phc offset -63 s2 freq -9645 delay 0 phc2sys[470790.265]: CLOCK_REALTIME phc offset -797 s2 freq -10398 delay 0 phc2sys[470791.266]: CLOCK_REALTIME phc offset 524 s2 freq -9316 delay 0 phc2sys[470792.266]: CLOCK_REALTIME phc offset 598 s2 freq -9085 delay 0 phc2sys[470793.266]: CLOCK_REALTIME phc offset -247 s2 freq -9750 delay 0 phc2sys[470794.267]: CLOCK_REALTIME phc offset -22 s2 freq -9599 delay 0 phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out Is there something I can do to troubleshoot this? Our application needs to run for days. My solution is to modify the phc2sys's sysoff_precise to just use the last pctns and ts result when an ioctl error happens. when this connection timed out happen, ptp4l is still running. regards,bernardo On Wed, May 17, 2023 at 10:46 AM Bernie Gmail <be...@gm...> wrote: > > Thank you! We have the HEAD and re-running our test overnight. Will report > back on our results tomorrow > > regards,bernardo > > Sent from fruit phone > > > On May 17, 2023, at 3:24 AM, Miroslav Lichvar <mli...@re...> > wrote: > > > > On Fri, May 12, 2023 at 04:28:40PM -0700, Bernie Elayda wrote: > >> phc2sys will stop but ptp4l will continue to run. This error appears to > >> originate from the sysoff_precise function;Doesn't this error just mean > >> when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy? > >> Wouldn't it be better to just 'log' the error and continue, or does even > >> one occurrence of this error mean something is misconfigured in my > setup? > > > > I think this phc2sys issue was fixed after 3.1.1 in git. Please try > > that and see if it still exits. > > > > -- > > Miroslav Lichvar > > > |
|
From: Jacob K. <jac...@in...> - 2023-05-18 17:15:04
|
On 5/18/2023 9:14 AM, Bernie Elayda wrote: > Hello, I have an update. I obtained the HEAD for linuxptp yesterday and > re-ran my setup. Unfortunately, phc2sys failed again with a Connection > timed out: > > phc2sys[470789.265]: CLOCK_REALTIME phc offset -63 s2 freq -9645 > delay 0 > phc2sys[470790.265]: CLOCK_REALTIME phc offset -797 s2 freq -10398 > delay 0 > phc2sys[470791.266]: CLOCK_REALTIME phc offset 524 s2 freq -9316 > delay 0 > phc2sys[470792.266]: CLOCK_REALTIME phc offset 598 s2 freq -9085 > delay 0 > phc2sys[470793.266]: CLOCK_REALTIME phc offset -247 s2 freq -9750 > delay 0 > phc2sys[470794.267]: CLOCK_REALTIME phc offset -22 s2 freq -9599 > delay 0 > phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out > > Is there something I can do to troubleshoot this? Our application needs to > run for days. My solution is to modify the phc2sys's sysoff_precise to > just use the last pctns and ts result when an ioctl error happens. > when this connection timed out happen, ptp4l is still running. > > regards,bernardo What hardware are you using? I suspect the PHC driver must be returning some error here which is what ultimately causes sys_offset_precise to fail. |
|
From: Bernie G. <be...@gm...> - 2023-05-18 17:26:25
|
an Intel i7 NUC running Ubutnu 18.04 with kernel 5.4.0-generic Sent from fruit phone > On May 18, 2023, at 10:20 AM, Jacob Keller <jac...@in...> wrote: > > > >> On 5/18/2023 9:14 AM, Bernie Elayda wrote: >> Hello, I have an update. I obtained the HEAD for linuxptp yesterday and >> re-ran my setup. Unfortunately, phc2sys failed again with a Connection >> timed out: >> >> phc2sys[470789.265]: CLOCK_REALTIME phc offset -63 s2 freq -9645 >> delay 0 >> phc2sys[470790.265]: CLOCK_REALTIME phc offset -797 s2 freq -10398 >> delay 0 >> phc2sys[470791.266]: CLOCK_REALTIME phc offset 524 s2 freq -9316 >> delay 0 >> phc2sys[470792.266]: CLOCK_REALTIME phc offset 598 s2 freq -9085 >> delay 0 >> phc2sys[470793.266]: CLOCK_REALTIME phc offset -247 s2 freq -9750 >> delay 0 >> phc2sys[470794.267]: CLOCK_REALTIME phc offset -22 s2 freq -9599 >> delay 0 >> phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out >> >> Is there something I can do to troubleshoot this? Our application needs to >> run for days. My solution is to modify the phc2sys's sysoff_precise to >> just use the last pctns and ts result when an ioctl error happens. >> when this connection timed out happen, ptp4l is still running. >> >> regards,bernardo > > What hardware are you using? I suspect the PHC driver must be returning > some error here which is what ultimately causes sys_offset_precise to fail. > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Bernie E. <be...@gm...> - 2023-05-18 18:19:57
|
This is probably more useful than just 'intel NUC i7':: System-manufacturer : Intel(R) Client Systems System-product-name : NUC10i7FNH Bios-release-date : 04/09/2021 Bios-version : FNCML357.0052.2021.0409.1144 Let me know if you need more detailed info. regards,bernardo On Thu, May 18, 2023 at 10:26 AM Bernie Gmail <be...@gm...> wrote: > > an Intel i7 NUC running Ubutnu 18.04 with kernel 5.4.0-generic > > Sent from fruit phone > > > On May 18, 2023, at 10:20 AM, Jacob Keller <jac...@in...> > wrote: > > > > > > > >> On 5/18/2023 9:14 AM, Bernie Elayda wrote: > >> Hello, I have an update. I obtained the HEAD for linuxptp yesterday and > >> re-ran my setup. Unfortunately, phc2sys failed again with a Connection > >> timed out: > >> > >> phc2sys[470789.265]: CLOCK_REALTIME phc offset -63 s2 freq -9645 > >> delay 0 > >> phc2sys[470790.265]: CLOCK_REALTIME phc offset -797 s2 freq -10398 > >> delay 0 > >> phc2sys[470791.266]: CLOCK_REALTIME phc offset 524 s2 freq -9316 > >> delay 0 > >> phc2sys[470792.266]: CLOCK_REALTIME phc offset 598 s2 freq -9085 > >> delay 0 > >> phc2sys[470793.266]: CLOCK_REALTIME phc offset -247 s2 freq -9750 > >> delay 0 > >> phc2sys[470794.267]: CLOCK_REALTIME phc offset -22 s2 freq -9599 > >> delay 0 > >> phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out > >> > >> Is there something I can do to troubleshoot this? Our application > needs to > >> run for days. My solution is to modify the phc2sys's sysoff_precise to > >> just use the last pctns and ts result when an ioctl error happens. > >> when this connection timed out happen, ptp4l is still running. > >> > >> regards,bernardo > > > > What hardware are you using? I suspect the PHC driver must be returning > > some error here which is what ultimately causes sys_offset_precise to > fail. > > > > > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: Jacob K. <jac...@in...> - 2023-05-18 22:32:45
|
On 5/18/2023 3:16 PM, Bernie Elayda wrote: > And more detail on the Ethernet driver used on our NUC(duplicating previous > info for completeness, too) > > Ubutnu 18.04 with kernel 5.4.0-generic > System-manufacturer : Intel(R) Client Systems > System-product-name : NUC10i7FNH > Bios-release-date : 04/09/2021 > Bios-version : FNCML357.0052.2021.0409.1144 > > 00:1f.6 Ethernet controller: Intel Corporation Device 0d4f > Subsystem: Intel Corporation Device 2081 > Flags: bus master, fast devsel, latency 0, IRQ 149 > Memory at 96300000 (32-bit, non-prefetchable) [size=128K] > Capabilities: [c8] Power Management version 3 > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Kernel driver in use: e1000e > Kernel modules: e1000e > > Thanks, A quick search indicates this appears to be an e1000e-based controller by the presence of this define in e1000e/hw.h on a current Linux kernel: #define E1000_DEV_ID_PCH_CMP_I219_V10>-->-------0x0D4F At least on mainline kernels I could check, the e1000e_phc_gettimex function does not have a failure condition You're using PTP_SYS_OFFSET_PRECISE ioctl to get the clock time? The implementation in e1000e_phc_get_syncdevicetime does have a timeout condition if it is unable to acquire the timestamp within a delay. Unfortunately I am unfamiliar with this hardware so I do not know what the delay value is or whether it would be safe to change it. It is likely you occasionally hit the delay and timeout. I do not think your suggested modification of the SYS_OFFSET_PRECISE ioctl is a valid solution since I would expect that accepting the last value would be accepting some garbage data and be incorrect.... |
|
From: Bernie E. <be...@gm...> - 2023-05-18 22:39:56
|
We are just what is using what is there in the source code for phc2sys. the
code in question is in the sysoff.c file:
44 static int sysoff_precise(int fd, int64_t *result, uint64_t *ts)
45 {
46 struct ptp_sys_offset_precise pso;
47 memset(&pso, 0, sizeof(pso));
48 if (ioctl(fd, PTP_SYS_OFFSET_PRECISE, &pso)) {
49 print_ioctl_error("PTP_SYS_OFFSET_PRECISE");
50 return -errno;
51 }
52 *result = pctns(&pso.sys_realtime) - pctns(&pso.device);
53 *ts = pctns(&pso.sys_realtime);
54 return 0;
55 }
Could I get more clarification on my possible workaround? Are you saying
that once the timeout occurs the date and time are garbage forever?
tia,bernardo
On Thu, May 18, 2023 at 3:32 PM Jacob Keller <jac...@in...>
wrote:
>
>
> On 5/18/2023 3:16 PM, Bernie Elayda wrote:
> > And more detail on the Ethernet driver used on our NUC(duplicating
> previous
> > info for completeness, too)
> >
> > Ubutnu 18.04 with kernel 5.4.0-generic
> > System-manufacturer : Intel(R) Client Systems
> > System-product-name : NUC10i7FNH
> > Bios-release-date : 04/09/2021
> > Bios-version : FNCML357.0052.2021.0409.1144
> >
> > 00:1f.6 Ethernet controller: Intel Corporation Device 0d4f
> > Subsystem: Intel Corporation Device 2081
> > Flags: bus master, fast devsel, latency 0, IRQ 149
> > Memory at 96300000 (32-bit, non-prefetchable) [size=128K]
> > Capabilities: [c8] Power Management version 3
> > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Kernel driver in use: e1000e
> > Kernel modules: e1000e
> >
> >
>
> Thanks,
>
> A quick search indicates this appears to be an e1000e-based controller
> by the presence of this define in e1000e/hw.h on a current Linux kernel:
>
> #define E1000_DEV_ID_PCH_CMP_I219_V10>-->-------0x0D4F
>
> At least on mainline kernels I could check, the e1000e_phc_gettimex
> function does not have a failure condition
>
> You're using PTP_SYS_OFFSET_PRECISE ioctl to get the clock time?
>
> The implementation in e1000e_phc_get_syncdevicetime does have a timeout
> condition if it is unable to acquire the timestamp within a delay.
>
> Unfortunately I am unfamiliar with this hardware so I do not know what
> the delay value is or whether it would be safe to change it.
>
> It is likely you occasionally hit the delay and timeout.
>
> I do not think your suggested modification of the SYS_OFFSET_PRECISE
> ioctl is a valid solution since I would expect that accepting the last
> value would be accepting some garbage data and be incorrect....
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X