Hi Richard,
On Thu, Jul 09, 2020 at 08:26:06AM -0700, Richard Cochran wrote:
> On Sat, Jun 27, 2020 at 11:27:47AM +0300, Vladimir Oltean wrote:
> > Hi Richard,
> >
> > I have a board with multiple DSA switches which I'm trying to make act as a
> > single boundary clock.
>
> Okay, so I think I got it...
>
> > But looking at the current object model in ts2phc, I figured my changes
> > would
> > be rather intrusive to its current design, so I would like to have a
> > discussion
> > with you before I even start.
>
> Yes, it would be too complex of a change for ts2phc. I want to keep
> these programs (ptp4l, phc2sys, and ts2phc) relatively simple, in the
> tradition of discrete unix command line tools. Of course, there are
> pros and cons of this "distributed" architecture, but I don't want to
> move in the direction of a super-programmable, monolithic mega library
> that handles every imaginable HW and use case. (That would be a
> interesting approach, but it would mean starting a new project.)
>
> It may be that writing your own service for your device is the best
> approach. I bet you could re-use some of the existing code. Let me
> suggest how you might tackle this with the least amount of effort.
>
> 1. Run ts2phc with the simple configuration that you mentioned. Let
> it run forever, making /dev/ptp1 the source of time.
>
> 2. For the TC use case, run ptp4l with the free_running and
> boundary_clock_jbod options. (Using a custom shell script or
> program, you can optionally monitor the frequency offset via
> management messages and syntonize /dev/ptp1 to the remote GM).
>
> 3. For the BC use case, again use ptp4l + free_running +
> boundary_clock_jbod. Write a custom program that queries
> TIME_STATUS_NP, feeds the offsets into a servo, and adjusts
> /dev/ptp1 accordingly. This will work provided the Sync rate is
> not too high.
>
> To support very high Sync rates, your program can receive "pushed"
> Sync timestamps using the new SLAVE_RX_SYNC_TIMING_DATA TLV.
> Together with CURRENT_DATA_SET.meanPathDelay you can figure the
> offsets and feed them into the servo.
>
> Thanks,
> Richard
Welcome back from holiday!
This is certainly an interesting idea and I might even end up giving it
a try. If I'm getting you right you are saying I could synchronize the
ts2phc_phc_master via yet another program which is based off of ptp4l's
virtual time, and then ts2phc writes that back into ptp4l's PHC and
makes it 'real'. I don't know how ptp4l with free_running will behave
when an external program is adjusting its clock, I would be surprised if
it reacted well to clock jumps and things like that, though. Not only
that, but thing is, for this particular application I don't even really
need /dev/ptp1 to be synchronized at all. I just want it to emit pulses
that are timestamped by all other PHCs. In fact, synchronizing /dev/ptp1
introduces instability in ts2phc's slave servos, due to the fact that
ts2phc_master_getppstime() doesn't have an ideal interface for a PHC
master. Honestly, I would have expected (somehow) that getppstime()
retuns the precise time of the PPS event, corresponding to the same
event on the slaves*. But right now, there's just an imprecise
approximation being made there, and that doesn't quite work when the PHC
master is also jumping.
In fact, I was already close to getting something working, which I would
still like to post as-is. I don't intend to break the existing
functionality, just add support for '-a' (and '--transportSpecific', for
802.1AS). I needed to refactor the synchronization logic, from
synchronizing a 'slave' into synchronizing a 'clock': every PHC in the
system, be it a master or a slave, has a 'struct clock' associated with
it now. The '-a' option just instantiates a PMC that listens for
PORT_PROPERTIES_NP and decides which clock from the list of clocks is
the 'source'. Without '-a', the PHC master is the 'source'. (yes, I
know, this breaks the master's polymorphism a little bit, since not all
masters are PHC masters, they can also be generic or NMEA masters.. oh
well).
If I can get ts2phc to do what I want, I'd rather keep using that, and
get your help to bring it in a shape where it's usable by the larger
community.
*I would have expected the "oneshot" flag of the perout request to do
exactly this. This is how the sja1105 hardware, when operated in a
multi-switch setup, is intended to be used: one switch (the "pulse
master") performs a one-shot toggle of the PTP_CLK, and retrieves a
precise timestamp of that, and the other switches ("pulse slaves") also
retrieve a precise timestamp of the same event. The offset that is fed
into the servo is just the delta of these 2 timestamps, no
approximations or rounding. Ideally this is what I would have went for,
but it looks like there's more kernel support necessary for that to
work, whereas using the Felix clock to generate periodic output is just
simpler (even though we have to live with the imprecise getppstime
result).
P.S. Why are we ever rounding the "source_ts" from
ts2phc_master_getppstime _up_? As far as I understand, when a slave
event is captured in ts2phc_slave_poll, that event is always in every
PHC's _past_, including the master's own past. So, rounding up doesn't
make a lot of sense to me.
Thanks,
-Vladimir
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
