Re: [Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
On Tue, Jan 09, 2018 at 05:21:39PM +0100, Miroslav Lichvar wrote: > > I think I said that this works when N==GM. > > Hm, does that change anything? If the delay of event messages going > from GM/N to S is larger than the delay of messages going from S to > GM/N, the clock of S will be running behind GM. The measurements of S > done by the GM/N will have the opposite error. Yes, you are right, of course. I wasn't thinking. The Meinberg doc has this statement: One big advantage of this mechanism is, that the communicated offset and delay from the monitored device can be compared to the measured offset and delay values and - assumed that the monitoring system is perfectly synchronized - asymmetries can be detected. So assuming the asymmetry on the monitor's path is known, then you can measure a constant offset on the normal GM path. Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Stepping the time backwards with phc2sys
On Mon, Jan 15, 2018 at 04:59:13PM +, Loy, Matthias wrote: > we are syncronizing devices using ptp. The absolute time is not > relevant but all devices should be close to each other. > > Furthermore devices are connected and disconnected at any time and most > of the time there is no real grandmaster clock with higher priority. > > As a result, a new connected device may became ptp grandmaster and all > others adjust there time. > > If the new grandmaster is wy back in time, phc2sys refuses to set > the clock. I found the reason in the kernel and created a patch you can > find attached. > > What do you think about that? For my understanding it would be okay to > step the realtime clock backwards even below 0 because the value > holding the sceonds is a signed int variable. I doubt your patch would find acceptance on the lkml. The check is a sanity check that makes sense for most use cases. You can work around this issue by setting some arbitrary date, like 1984, as part of your boot scripts. Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
