[time-nuts] Re: TimeProvider 2700 PTP UTC offset issue.

Andrew Back andrew at carrierdetect.com
Tue Jun 28 09:15:41 UTC 2022


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 at 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 at 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 at 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 at lists.febo.com
>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe send an email to time-nuts-leave at lists.febo.com




More information about the Time-nuts_lists.febo.com mailing list