Discussion:
[Linuxptp-devel] 802.1AS Time-Aware Bridge
Burkhard Ilsen
2017-03-27 08:45:16 UTC
Permalink
Hello,
So I do want to have TC/TAB in linuxptp for version 2.0.
According to 802.1 AS all message timestamps shall be based on a free running clock (LocalClock) in order to minimize the errors resulting from a varying clock frequency.
Also phase discontinuities in the pdelay_resp(fup) messages are avoided this way.
So the SlaveClock controlled by the servo is different from the hardware clock taking the timestamps.
An implementation would require to translate hardware timestamps into the SlaveClock epoch to compute the master offset correctly.

I was not able to find this behavior implemented in linuxptp. Did I miss something, or was this already issued?

Thanks and regards,
Burkhard



Hilscher Gesellschaft für Systemautomation mbH | Rheinstrasse 15 | 65795 Hattersheim | Germany | www.hilscher.com
Sitz der Gesellschaft / place of business: Hattersheim | Geschäftsführer / managing director: Dipl.-Ing. Hans-Jürgen Hilscher
Handelsregister / commercial register: Frankfurt B 26873 | Ust. Idnr. / VAT No.: DE113852715
Registergericht / register court: Amtsgericht Frankfurt/Main

Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

Wichtiger Hinweis:
Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und rechtlich geschützte Informationen, die nur für den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und löschen Sie diese Nachricht und ihre Anhänge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veränderung der E-Mail ist untersagt. Der Absender haftet nicht für Inhalte von veränderten E-Mails.
Richard Cochran
2017-03-27 09:33:51 UTC
Permalink
Post by Burkhard Ilsen
So I do want to have TC/TAB in linuxptp for version 2.0.
According to 802.1 AS all message timestamps shall be based on a free running clock (LocalClock) in order to minimize the errors resulting from a varying clock frequency.
Also phase discontinuities in the pdelay_resp(fup) messages are avoided this way.
So the SlaveClock controlled by the servo is different from the hardware clock taking the timestamps.
An implementation would require to translate hardware timestamps into the SlaveClock epoch to compute the master offset correctly.
I was not able to find this behavior implemented in linuxptp. Did I miss something, or was this already issued?
You are mistaken. The master offset is irrelevant for TC operation.
The TC is supposed to syntonize only.

Thanks,
Richard
Burkhard Ilsen
2017-03-27 10:32:46 UTC
Permalink
Post by Richard Cochran
Post by Burkhard Ilsen
According to 802.1 AS all message timestamps shall be based on a free running clock (LocalClock) in order to minimize the errors resulting from a varying clock frequency.
Also phase discontinuities in the pdelay_resp(fup) messages are avoided this way.
So the SlaveClock controlled by the servo is different from the hardware clock taking the timestamps.
An implementation would require to translate hardware timestamps into the SlaveClock epoch to compute the master offset correctly.
I was not able to find this behavior implemented in linuxptp. Did I miss something, or was this already issued?
You are mistaken. The master offset is irrelevant for TC operation.
The TC is supposed to syntonize only.
You are right, a plain TC does not need the offset.

My use case is a bridged end-station, i.e. a time-aware bridge with an application that needs to be synchronized.
The AS model of operation allows every time-aware system (including TAB) to include a ClockSlave and provide an application interface to a ClockTarget.

Syntonization is done by multiplying the residence time with the rate ratio, no servo needed, right?
So the servo should be free for synchronizing the ClockSlave but this requires the offset.
Would this be possible with linuxptp?
Any advice is appreciated.

Regards,
Burkhard




Hilscher Gesellschaft für Systemautomation mbH | Rheinstrasse 15 | 65795 Hattersheim | Germany | www.hilscher.com
Sitz der Gesellschaft / place of business: Hattersheim | Geschäftsführer / managing director: Dipl.-Ing. Hans-Jürgen Hilscher
Handelsregister / commercial register: Frankfurt B 26873 | Ust. Idnr. / VAT No.: DE113852715
Registergericht / register court: Amtsgericht Frankfurt/Main

Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

Wichtiger Hinweis:
Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und rechtlich geschützte Informationen, die nur für den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und löschen Sie diese Nachricht und ihre Anhänge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veränderung der E-Mail ist untersagt. Der Absender haftet nicht für Inhalte von veränderten E-Mails.
Richard Cochran
2017-03-27 15:32:22 UTC
Permalink
Post by Burkhard Ilsen
My use case is a bridged end-station, i.e. a time-aware bridge with an application that needs to be synchronized.
So we don't actually support TC or TAB. Those patches were only a
rudimentary proof of concept. Did you see the TODO list?
Post by Burkhard Ilsen
The AS model of operation allows every time-aware system (including TAB) to include a ClockSlave and provide an application interface to a ClockTarget.
If you are talking about 802.1AS-2011 Clause 9, then I recommend just
ignoring it. It is not one of the more brilliant examples of
standards writing.

In linuxptp, applications can find out everything they need to know
via the management interface. In particular, the TIME_STATUS_NP TLV
is designed for use with gPTP and the free_running option.
Post by Burkhard Ilsen
Syntonization is done by multiplying the residence time with the rate ratio, no servo needed, right?
No, syntonization means choosing a master and calculating the rate ratio.
Post by Burkhard Ilsen
So the servo should be free for synchronizing the ClockSlave but this requires the offset.
Would this be possible with linuxptp?
Any advice is appreciated.
You have two options:

1. Use TIME_STATUS_NP and implement the servo in the application.

2. Adjust the TC clock. Depending on your environment, this may be
acceptable. Even though 802.1AS-2011 says not to, 1588 allows it.

HTH,
Richard
Burkhard Ilsen
2017-03-31 14:59:36 UTC
Permalink
Thank you Richard for your help.
Post by Richard Cochran
So we don't actually support TC or TAB. Those patches were only a
rudimentary proof of concept. Did you see the TODO list?

Yes, I saw it and I am looking forward to 2.0.

Until then I stick with an endpoint only implementation. In fact the
differentiation of LocalClock and ClockSlave makes sense for endpoints too.

My task is to prototype an industrial TSN node. My hardware supports taking
two timestamps (from two different hardware clocks) for each message.
Post by Richard Cochran
1. Use TIME_STATUS_NP and implement the servo in the application.
2. Adjust the TC clock. Depending on your environment, this may be
acceptable. Even though 802.1AS-2011 says not to, 1588 allows it.

I already implemented a third option: I messed with the linuxptp code so
that timestamps relative to LocalClock are passed into delay measurement
and timestamps relative to ClockSlave are passed into the servo. It works
very well.

I stumbled upon some minor issues that I will address in other threads.


Best Regards,

Burkhard

Loading...