Thanks, Miroslav. Your inputs are helpful to form our understanding. Regards, Dolly
On Thu, Oct 25, 2018 at 6:40 PM Miroslav Lichvar <mlich...@redhat.com> wrote: > On Thu, Oct 25, 2018 at 05:41:29PM +0530, Dolly Gyanchandani wrote: > > A separate and more accurate time source is necessary. For measuring > > the accuracy of SW timestamping you can use HW timestamping. > > > > What do you mean by this? Do we need to have PTP enabled NICs to be able > to > > test software timestamping? Not sure if we understand this point > correctly. > > Could you elaborate a bit? > > A synchronized PTP clock is a good reference for measuring the > accuracy of the system clock synchronized with SW timestamping. With > SW timestamping a typical error is in microseconds or tens of > microseconds and HW timestamping is usually good to hundreds of > nanoseconds. > > > Thanks for your inputs. They were of great help. When we ran ptp4l with > > hardware timestamping, without synchronization of the system clock with > the > > hardware clock on the master node, we are able to get around 25 > nanoseconds > > offset between the master and slave clock which seems to be a good and > > desired value. > > > ptp4l[304.918]: master offset -39 s2 freq +80417 path delay > > 1568 > > ptp4l[305.919]: master offset 3 s2 freq +80447 path delay > > 1568 > > ptp4l[306.919]: master offset -14 s2 freq +80431 path delay > > 1564 > > ptp4l[307.919]: master offset 27 s2 freq +80468 path delay > > 1563 > > The offset indicates the clock is stable to about 25 nanoseconds and > the delay gives an upper bound on the error. > > If you don't know how much asymmetry is there in the timestamping and > the network, you can tell only that this clock is accurate to 1.5 > microseconds relative to the master, or grandmaster if synchronized > directly to it. > > -- > Miroslav Lichvar >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
