Hi Miroslav, Thanks for bearing with us.
We were able to find out the cause of the issue of system clock time sync with master and slave which was explained in above two points. It was caused because we didn't run phc2sys on the master node. So the hardware clock UTC time was being sent as is to the slave. And the slave considered it as TAI time. If we run "phc2sys -c CLOCK_REALTIME -s em1" on master the problem is solved. Our original problem still exists. clock_gettime(clock_tai) returns same time as clock_gettime(clcok_realtime) Is there any other way to access TAI time / UTC-TAI offset programmatically? On Thu, Nov 1, 2018 at 2:14 PM Dolly Gyanchandani < dollygyanchandani1...@gmail.com> wrote: > Hi Miroslav > > Yes, it is 1 for now. > > The CLOCK_TAI and CLOCK_REALTIME for any of the machines is same. However, > there is always a constant difference in time of slave from master with a > value very close to the currentUTCOffset as shown by PMC. For example, > > - if I manually change the currentUTCOffset on master to 30 secs, the > CLOCK_REALTIME and CLOCK_TAI on master shows me a value "*X*" whereas > the CLOCK_REALTIME and CLOCK_TAI on slave shows me a value "*X-32*". > - if I manually change the currentUTCOffset on master to 100 secs, the > CLOCK_REALTIME and CLOCK_TAI on master shows me a value "Y* secs*" > whereas the CLOCK_REALTIME and CLOCK_TAI on slave shows me a value "Y > *-103* secs". > > > In any case the kernel parameter tai_offset does not get set and calling > ntptime from the shell gives me "TAI Offset 0". We also tried to set the > "GRAND_MASTER_SETTINGS_NP" with different variations as mentioned by > Richard but with no help. What could be the reason? > > On Thu, Nov 1, 2018 at 1:37 PM Puneet Patwari < > puneet.patw...@thoughtworks.com> wrote: > >> Hi Miroslav >> >> Yes, it is 1 for now. >> >> The CLOCK_TAI and CLOCK_REALTIME for any of the machines is same. >> However, there is always a constant difference in time of slave from master >> with a value very close to the currentUTCOffset as shown by PMC. For >> example, >> >> - if I manually change the currentUTCOffset on master to 30 secs, the >> CLOCK_REALTIME and CLOCK_TAI on master shows me a value "*X*" >> whereas the CLOCK_REALTIME and CLOCK_TAI on slave shows me a value " >> *X-32*". >> - if I manually change the currentUTCOffset on master to 100 secs, >> the CLOCK_REALTIME and CLOCK_TAI on master shows me a value "Y* secs*" >> whereas the CLOCK_REALTIME and CLOCK_TAI on slave shows me a value "Y >> *-103* secs". >> >> >> In any case the kernel parameter tai_offset does not get set and calling >> ntptime from the shell gives me "TAI Offset 0". We also tried to set the >> "GRAND_MASTER_SETTINGS_NP" with different variations as mentioned by >> Richard but with no help. What could be the reason? >> >> Regards >> Puneet >> >> On Thu, Nov 1, 2018 at 1:15 PM Miroslav Lichvar <mlich...@redhat.com> >> wrote: >> >>> On Thu, Nov 01, 2018 at 11:15:44AM +0530, Dolly Gyanchandani wrote: >>> > @Miroslav, after setting currentUtcOffsetValid and timeTraceable >>> parameters >>> > to 1, we still get clock_gettime(CLOCK_TAI) same as >>> > clock_gettime(CLOCK_REALTIME). >>> > And we still don't see kernel parameter tai_offset being set >>> (verified by >>> > ntptime command) >>> >>> Is ptpTimescale 1? >>> >>> -- >>> Miroslav Lichvar >>> >> >> >> -- >> Regards >> Puneet Patwari >> Application Developer >> ThoughtWorks, Pune >> >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
