On Wed, Nov 05, 2014 at 05:34:23PM +0100, Richard Cochran wrote: > On Wed, Nov 05, 2014 at 03:02:14PM +0100, Miroslav Lichvar wrote: > > > > But I'm wondering how difficult it would be to implement a BC from > > separate PHCs more cleanly. How about adding a new virtual transport > > that uses clock_gettime() to timestamp the messages, create a clock > > instance in ptp4l for each PHC with a port to the virtual transport? > > Instead of one BC handling multiple PHCs there are multiple BCs in a > > virtual network. > > > > What do you think? > > This similar to what Patrick Ohly (inventor of so_timestamping) > suggested in his paper, with "two-layer ptp" or something like that.
Looking at the paper, it seems the two level PTP is exactly what we have now with ptp4l and phc2sys, one servo steers the NIC clock from PTP and the second servo steers the system clock to the NIC clock. > It would add a bunch of protocol overhead, messages back and forth, > and so on. Also it would change the BMC network topology. This impacts > the hops for managment message forwarding. Yes, managing multiple clock instances in ptp4l would be more expensive and there would be an extra hop visible on the network, but is that really a problem? They are separate physical clocks. > I like the idea of "automatic" phc2sys, if it would only work right. I like the automatic phc2sys mode when used to synchronize the system clock. It's used by timemaster and seems to be working nicely. I'm just worried the tight coupling between ptp4l and phc2sys that will be needed for the jbod mode will be problematic in the future and phc2sys will eventually have to be included in ptp4l for some reason we don't see know. -- Miroslav Lichvar ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
