On Sat, Nov 01, 2014 at 08:00:21PM +0100, Richard Cochran wrote: > Before releasing v1.5, I wanted to test phc2sys's new automatic mode > in order to run a BC using a bunch of PCIe cards, but I found it did > not quite work. First of all, the port logic bails out when the PHC > device don't match, and secondly phc2sys has one line bug. > > After hacking those two problems away, the BC worked okay. With a > GM-BC-slave setup, the slave had about an additional 9 usec offset. > > I made the "jbod" a non-default option, so that users who want this > really know not to expect perfect performance.
Hm, I think this will work only when the first port is the slave. Otherwise, the servo will be trying to steer the clock of the master port from slave's timestamps and the slave clock will never be synchronized. The PHC device would need to be reopened when a new port becomes slave. Or there could be a check that allows only the first port to be slave, I think this would still be a very useful feature. There is also the problem that the master port will be sending sync messages before it's actually synchronized to the slave port by phc2sys. Maybe a new management message could be introduced to mark the port as synchronized from phc2sys and allow ptp4l to switch it to the master state. 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? -- Miroslav Lichvar ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
