On Sun, Sep 08, 2019 at 12:07:27PM +0100, Vladimir Oltean wrote: > I think Richard has been there when the taprio, etf qdiscs, SO_TXTIME > were first defined and developed: > https://patchwork.ozlabs.org/cover/808504/ > I expect he is capable of delivering a competent review of the entire > series, possibly way more competent than my patch set itself.
I am really not familiar with the taprio/qdisc stuff. Sorry. > Additionally, the 802.1AS PTP profile even calls for switches and > end-stations to use timestamping counters that are free-running, and > scale&rate-correct those in software - due to a perceived "double > feedback loop", or "changing the ruler while measuring with it". Now > I'm no expert at all, but it would be interesting if we went on with > the discussion in the direction of what Linux is currently > understanding by a "free-running" PTP counter. On one hand there's the > timecounter/cyclecounter in the kernel which makes for a > software-corrected PHC, and on the other there's the free_running > option in linuxptp which makes for a "nowhere-corrected" PHC that is > only being used in the E2E_TC and P2P_TC profiles. But user space > otherwise has no insight into the PHC implementation from the kernel, > and "free_running" from ptp4l can't really be used to implement the > synchronization mechanism required by 802.1AS. That just isn't true. We have already done this for end stations. > To me, the most striking aspect is that this particular recommendation > from 802.1AS is at direct odds with 802.1Qbv (time-based egress) / > 802.1Qci (time-based ingress policing) which clearly require a PTP > counter in the NIC that ticks to the wall clock, and not to a random > free-running time since boot up. I simply can't seem to reconcile the > two. Well, yeah. The various PTP standards and profiles dream up whatever they want. The HW we get dictates what is actually possible. > But let's leave 802.1AS aside for a second - that's not what the patch > set is about, but rather a bit of background on why there are 2 PTP > clocks in this switch, and why I'm switching from one to the other. > Richard didn't really warm up to the phc2sys-to-itself idea in the > past, and opted for simplicity: just use the hardware-corrected > PTPCLKVAL for everything, which is exactly what I'm doing as of now. If you really want to make an 802.1-AS bridge, then 1. You can leave the clock free running, and 2. you don't need to synchronize the Linux system clock at all. Thanks, Richard
