> + ts += offset;
I think there is a sign error here. This line of code is attempting to
reconstruct the 'tp' variable in sysoff_estimate(). In other words, ts
should become the ethernet device's PHC timestamp at the time of the
best sample.
sysoff_measure writes the
In the current design of the SO_SELECT_ERR_QUEUE socket option (which is
enabled by sk_timestamping_init on the event fd), it is a bug to only
check revents & POLLIN, but not also POLLERR.
Normally the error queue events that the application expects (i.e. TX
timestamps) are received, within a give
The application's main event loop (clock_poll) is woken up by poll() and
dispatches the socket receive queue events to the corresponding ports as
needed.
So it is a bug if poll() wakes up the process for data availability on a
socket's receive queue, and then recvmsg(), called immediately
afterwar
Ptp4l is too silent when receiving, for whatever reason, out of order
messages. If the reordering is persistent (which is either a broken
network, or a broken kernel), the behavior looks like a complete
synchronization stall, since the application is designed to never
attempt to recover from such a
The reordering issue reported by me initially on the linuxptp-devel
list [0] with the sja1105 DSA driver turned out not to be a reordering
issue at all, in fact.
Due to a kernel bug described in this patch [1], the DSA driver was in
race with the master Ethernet driver and would occasionally (very
On Mon, Dec 16, 2019 at 03:42:52PM +0530, Prasanth KV wrote:
> BC (IPv4 UC) - TC --- BC(IP4 UC)
>
> I'm trying this scenario and I'm not successful with TC. TC is not able to
> forward the PTP packets. Do any one has a working settings for TC in this
> scenario?
Here is the relevant code:
Greetings.
BC (IPv4 UC) - TC --- BC(IP4 UC)
I'm trying this scenario and I'm not successful with TC. TC is not able to
forward the PTP packets. Do any one has a working settings for TC in this
scenario?
--
Best Regards,
Prasanth
___
Linuxptp-devel
