This is a huge help! Thank you very much! I set the Tx timestamp up to 50 ms to ensure that it wasn't creating confusion. So far I've found that the PSF_TX status frames (TX Timestamps) are not coming back to the dp83640 driver when the problem shows up. I think I'm on the right track. And, I should be able to squash the bug from here.
Thanks again! -Dan On Tue, Dec 7, 2021 at 11:27 AM Richard Cochran <richardcoch...@gmail.com> wrote: > On Tue, Dec 07, 2021 at 06:30:32AM -0500, Dan Geer wrote: > > So, I'm into the phyter device driver... What's the next step? > > The phyter generates special frames that carry the time stamps. These > frames are delivered to the host. Because the frames appear to be PTP > frames, the networking stack will deliver them to the phy driver via > > skb_defer_rx_timestamp() > > So the flow is: > > 1. host sends a PTP event message > 2. phyter time stamps it and generates a frame back to the host > 3. frame is delivered to the phy driver via mii_ts->rxtstamp() > 4. driver decodes frame and delivers cmsg to user space > > The default Tx timestamp timeout is 1 ms. Maybe your NW stack is just > a bit too slow. Try increasing the timeout to 10 ms. > > Another thing to consider about the phyter: It generates these > special frames, but only when there is some bandwidth left to send > them. It will not preempt normal NW traffic. That means you cannot > use the 100 Mbit completely. > > HTH, > Richard > >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
