Hoping that someone may be able to shed some light on a PTP issue I'm experiencing, which could well be a simple configuration issue or, as I suspect, somehow related to the grandmaster firmware. I have a Symmetricom TimeProvider 2700, with firmware which I think dates from ~2014, connected to a BeagleBoneBlack running Debian and Linux PTP. A direct Ethernet connection with no switches in between. The TP2700 has the 1588 Annex J Default profile active, with all default configuration. Linux PTP client is configured for utc_offset 37. The GM is referenced to GPS and "show clock" returns "Leap Seconds : 37". However, when ptp4l is started on the client I get the running in a temporal vortex message and "updating UTC offset to 35", despite not seeing an offset of 35 configured anywhere. I did also run "pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET'" on the client, which similarly confirmed a UTC offset of 35. I don't seem to be able to manually configure UTC offset on the TP2700 and when I try, it complains that this is not possible with the current mode, since it's referenced to GPS I guess. Other than this perhaps being a grandmaster firmware issue, I'm out of ideas. Andrew

Hi Andrew, have you checked the PTP-Messages themselves? There is a field currentUtcOffset in the PTP announce message used to transfer leapsecond info. If thats 35, then it seems like a firmware issue. Regards Markus Am 25.06.2022 um 10:30 schrieb Andrew Back via time-nuts: > Hoping that someone may be able to shed some light on a PTP issue I'm experiencing, which could well be a simple configuration issue or, as I suspect, somehow related to the grandmaster firmware. > > I have a Symmetricom TimeProvider 2700, with firmware which I think dates from ~2014, connected to a BeagleBoneBlack running Debian and Linux PTP. A direct Ethernet connection with no switches in between. The TP2700 has the 1588 Annex J Default profile active, with all default configuration. Linux PTP client is configured for utc_offset 37. The GM is referenced to GPS and "show clock" returns "Leap Seconds : 37". However, when ptp4l is started on the client I get the running in a temporal vortex message and "updating UTC offset to 35", despite not seeing an offset of 35 configured anywhere. > > I did also run "pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET'" on the client, which similarly confirmed a UTC offset of 35. > > I don't seem to be able to manually configure UTC offset on the TP2700 and when I try, it complains that this is not possible with the current mode, since it's referenced to GPS I guess. > > Other than this perhaps being a grandmaster firmware issue, I'm out of ideas. > > Andrew > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com >

Hi Markus, I've pasted output from some pmc GET commands below, along with show clock on the GM. Seems like the grandmaster is getting 37 from GPS, while announcing 35? Also not sure why TIME_PROPERTIES_DATA_SET has currentUtcOffsetValid and timeTraceable both set to true, but GRANDMASTER_SETTINGS_NP has these set to false. Best, Andrew // andrew@bbb:~$ sudo pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET' sending: GET TIME_PROPERTIES_DATA_SET     94e36d.fffe.d2695e-0 seq 0 RESPONSE MANAGEMENT TIME_PROPERTIES_DATA_SET         currentUtcOffset      35         leap61                0         leap59                0         currentUtcOffsetValid 1         ptpTimescale          1         timeTraceable         1         frequencyTraceable    1         timeSource            0x20 andrew@bbb:~$ sudo pmc -u -b 0 'get PARENT_DATA_SET' sending: GET PARENT_DATA_SET     94e36d.fffe.d2695e-0 seq 0 RESPONSE MANAGEMENT PARENT_DATA_SET         parentPortIdentity                    00b0ae.fffe.0357ef-2         parentStats                           0         observedParentOffsetScaledLogVariance 0xffff         observedParentClockPhaseChangeRate    0x7fffffff         grandmasterPriority1                  128         gm.ClockClass                         6         gm.ClockAccuracy                      0x21         gm.OffsetScaledLogVariance            0x6400         grandmasterPriority2                  128         grandmasterIdentity                   00b0ae.fffe.0357ef andrew@bbb:~$ sudo pmc -u -b 0 'GET GRANDMASTER_SETTINGS_NP' sending: GET GRANDMASTER_SETTINGS_NP     94e36d.fffe.d2695e-0 seq 0 RESPONSE MANAGEMENT GRANDMASTER_SETTINGS_NP         clockClass              255         clockAccuracy           0xfe         offsetScaledLogVariance 0xffff         currentUtcOffset        35         leap61                  0         leap59                  0         currentUtcOffsetValid   0         ptpTimescale            1         timeTraceable           0         frequencyTraceable      0         timeSource              0xa0 tp2700> show clock System time     : 2022-06-27 12:43:58 Leap Seconds    : 37 Leap pending    : +0 On 27/06/2022 12:22, Markus Kleinhenz via time-nuts wrote: > Hi Andrew, > > have you checked the PTP-Messages themselves? There is a field > currentUtcOffset in the PTP announce message used to transfer leapsecond > info. If thats 35, then it seems like a firmware issue. > > Regards > Markus > > Am 25.06.2022 um 10:30 schrieb Andrew Back via time-nuts: >> Hoping that someone may be able to shed some light on a PTP issue I'm experiencing, which could well be a simple configuration issue or, as I suspect, somehow related to the grandmaster firmware. >> >> I have a Symmetricom TimeProvider 2700, with firmware which I think dates from ~2014, connected to a BeagleBoneBlack running Debian and Linux PTP. A direct Ethernet connection with no switches in between. The TP2700 has the 1588 Annex J Default profile active, with all default configuration. Linux PTP client is configured for utc_offset 37. The GM is referenced to GPS and "show clock" returns "Leap Seconds : 37". However, when ptp4l is started on the client I get the running in a temporal vortex message and "updating UTC offset to 35", despite not seeing an offset of 35 configured anywhere. >> >> I did also run "pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET'" on the client, which similarly confirmed a UTC offset of 35. >> >> I don't seem to be able to manually configure UTC offset on the TP2700 and when I try, it complains that this is not possible with the current mode, since it's referenced to GPS I guess. >> >> Other than this perhaps being a grandmaster firmware issue, I'm out of ideas. >> >> Andrew >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe send an email to time-nuts-leave@lists.febo.com >> > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

Just to confirm that this would appear to have been a grandmaster firmware issue and has been resolved upon upgrading to the latest firmware. Andrew On 27/06/2022 14:02, Andrew Back wrote: > Hi Markus, > > I've pasted output from some pmc GET commands below, along with show > clock on the GM. Seems like the grandmaster is getting 37 from GPS, > while announcing 35? > > Also not sure why TIME_PROPERTIES_DATA_SET has currentUtcOffsetValid > and timeTraceable both set to true, but GRANDMASTER_SETTINGS_NP has > these set to false. > > Best, > > Andrew > > // > > andrew@bbb:~$ sudo pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET' > sending: GET TIME_PROPERTIES_DATA_SET >     94e36d.fffe.d2695e-0 seq 0 RESPONSE MANAGEMENT > TIME_PROPERTIES_DATA_SET >         currentUtcOffset      35 >         leap61                0 >         leap59                0 >         currentUtcOffsetValid 1 >         ptpTimescale          1 >         timeTraceable         1 >         frequencyTraceable    1 >         timeSource            0x20 > > andrew@bbb:~$ sudo pmc -u -b 0 'get PARENT_DATA_SET' > sending: GET PARENT_DATA_SET >     94e36d.fffe.d2695e-0 seq 0 RESPONSE MANAGEMENT PARENT_DATA_SET >         parentPortIdentity                    00b0ae.fffe.0357ef-2 >         parentStats                           0 >         observedParentOffsetScaledLogVariance 0xffff >         observedParentClockPhaseChangeRate    0x7fffffff >         grandmasterPriority1                  128 >         gm.ClockClass                         6 >         gm.ClockAccuracy                      0x21 >         gm.OffsetScaledLogVariance            0x6400 >         grandmasterPriority2                  128 >         grandmasterIdentity                   00b0ae.fffe.0357ef > > andrew@bbb:~$ sudo pmc -u -b 0 'GET GRANDMASTER_SETTINGS_NP' > sending: GET GRANDMASTER_SETTINGS_NP >     94e36d.fffe.d2695e-0 seq 0 RESPONSE MANAGEMENT > GRANDMASTER_SETTINGS_NP >         clockClass              255 >         clockAccuracy           0xfe >         offsetScaledLogVariance 0xffff >         currentUtcOffset        35 >         leap61                  0 >         leap59                  0 >         currentUtcOffsetValid   0 >         ptpTimescale            1 >         timeTraceable           0 >         frequencyTraceable      0 >         timeSource              0xa0 > > tp2700> show clock > > > System time     : 2022-06-27 12:43:58 > Leap Seconds    : 37 > Leap pending    : +0 > > > On 27/06/2022 12:22, Markus Kleinhenz via time-nuts wrote: >> Hi Andrew, >> >> have you checked the PTP-Messages themselves? There is a field >> currentUtcOffset in the PTP announce message used to transfer leapsecond >> info. If thats 35, then it seems like a firmware issue. >> >> Regards >> Markus >> >> Am 25.06.2022 um 10:30 schrieb Andrew Back via time-nuts: >>> Hoping that someone may be able to shed some light on a PTP issue >>> I'm experiencing, which could well be a simple configuration issue >>> or, as I suspect, somehow related to the grandmaster firmware. >>> >>> I have a Symmetricom TimeProvider 2700, with firmware which I think >>> dates from ~2014, connected to a BeagleBoneBlack running Debian and >>> Linux PTP. A direct Ethernet connection with no switches in between. >>> The TP2700 has the 1588 Annex J Default profile active, with all >>> default configuration. Linux PTP client is configured for utc_offset >>> 37. The GM is referenced to GPS and "show clock" returns "Leap >>> Seconds : 37". However, when ptp4l is started on the client I get >>> the running in a temporal vortex message and "updating UTC offset to >>> 35", despite not seeing an offset of 35 configured anywhere. >>> >>> I did also run "pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET'" on the >>> client, which similarly confirmed a UTC offset of 35. >>> >>> I don't seem to be able to manually configure UTC offset on the >>> TP2700 and when I try, it complains that this is not possible with >>> the current mode, since it's referenced to GPS I guess. >>> >>> Other than this perhaps being a grandmaster firmware issue, I'm out >>> of ideas. >>> >>> Andrew >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe send an email to time-nuts-leave@lists.febo.com >>> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe send an email to time-nuts-leave@lists.febo.com