Messages in this thread |  | | Subject | Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver | | From | Vladimir Oltean <> | | Date | Wed, 29 May 2019 23:41:22 +0300 |
| |
On 5/29/19 7:52 AM, Richard Cochran wrote: > On Wed, May 29, 2019 at 02:56:22AM +0300, Vladimir Oltean wrote: >> Not all is rosy, though. > > You can sure say that again! > >> PTP timestamping will only work when the ports are bridged. Otherwise, >> the metadata follow-up frames holding RX timestamps won't be received >> because they will be blocked by the master port's MAC filter. Linuxptp >> tries to put the net device in ALLMULTI/PROMISC mode, > > Untrue. >
I'm sorry, then what does this code from raw.c do?
> mreq.mr_ifindex = index; > mreq.mr_type = PACKET_MR_ALLMULTI; > mreq.mr_alen = 0; > if (!setsockopt(fd, SOL_PACKET, option, &mreq, sizeof(mreq))) { > return 0; > } > pr_warning("setsockopt PACKET_MR_ALLMULTI failed: %m"); > > mreq.mr_ifindex = index; > mreq.mr_type = PACKET_MR_PROMISC; > mreq.mr_alen = 0; > if (!setsockopt(fd, SOL_PACKET, option, &mreq, sizeof(mreq))) { > return 0; > } > pr_warning("setsockopt PACKET_MR_PROMISC failed: %m");
>> but DSA doesn't >> pass this on to the master port, which does the actual reception. >> The master port is put in promiscous mode when the slave ports are >> enslaved to a bridge. >> >> Also, even with software-corrected timestamps, one can observe a >> negative path delay reported by linuxptp: >> >> ptp4l[55.600]: master offset 8 s2 freq +83677 path delay -2390 >> ptp4l[56.600]: master offset 17 s2 freq +83688 path delay -2391 >> ptp4l[57.601]: master offset 6 s2 freq +83682 path delay -2391 >> ptp4l[58.601]: master offset -1 s2 freq +83677 path delay -2391 >> >> Without investigating too deeply, this appears to be introduced by the >> correction applied by linuxptp to t4 (t4c: corrected master rxtstamp) >> during the path delay estimation process (removing the correction makes >> the path delay positive). > > No. The root cause is the time stamps delivered by the hardware or > your driver. That needs to be addressed before going forward. >
How can I check that the timestamps are valid?
Regards, -Vladimir
> Thanks, > Richard >
|  |