gPTP clock sync accuracy

[tsnsystemspieter]

We are trying to understand and correlate the gPTP (802.1AS) clock accuracy output analysis to real world cases. It seems that in Omnet/INET, no clock Syntonization is implemented, and therefore if we simulate gPTP clocks using the Clock Quality requirements of 802.1AS (+-100ppm or 50ppm) we end up with a max Time Error of about 6us - which is of cause out of spec according to 802.1AS.
How to we use the clock analysis for real world cases?

The ClockDriftShowcase shows this behavior and our projects match this setup closely.

[levy]

The gPTP time synchronization protocol is implemented in INET, see the showcase at https://inet.omnetpp.org/docs/showcases/tsn/timesynchronization/gptp/doc/index.html

Isn't this what you are looking for?

[tsnsystemspieter]

Hi levy, thanks for the reply.
I should have probably explained my issue a bit more clearly.
I'm currently using the gPTP implementation in INET. My concern lays with the accuracy of the clock adjustments in comparison to real-world performance.
When using constantDriftOscillator or randomDriftOscillator in the clocks for the TsnDevice/TsnClock/TsnSwitch modules the drift rate is never adjusted. In reality, to my understanding, the clock of the slave must synchronize to not only the time at each syncInterval but also the driftRate to the master clock. In reality this would be achieved by adjusting the clock frequency and the gPTP implementation in INET just corrects the time whilst not adjusting anything else.
To my understanding, this causes the simulation to be out of spec with the 802.1AS-2020 spec. When you evaluate a 50ppm drift rate on the slave clocks with a syncInterval of 125ms the maximum time offset to the master clock exceeds 1us before re-synchronizing.
This behavior can also be seen in the showcases/tsn/timesynchronization/clockdrift when adjusting the settings to reflect the drift rate and sync interval.
I have also noticed that the correctionField never is calculated in the followUp messages.

Am I missing something for the setup of my network or is this feature not supported/implemented entirely?

[levy]

Oh, I see now. INET doesn't fully implement 802.1AS-2020, only the multiple time domains have been added compared to the previous version. So yes, you are right that clock drift rates are not synchronized.

[tsnsystemspieter]

Would it be possible to clarify the following:
What is the goal of simulating gPTP in omnet/inet? How can users benefit from this feature?
Can we simulate the sync accuracy of gPTP clocks in a network in order to assist us in designing actual networks?

[levy]

gPTP can be used to synchronize the time of INET clocks which can drift away from each other.

Yes, you can simulate the time synchronization and the drifting of clocks and its effects on time-aware shaping, for example. The current gPTP implementation doesn't change the drift rate of clocks, it only sets the time value of clocks. Setting the drift rate would not be too difficult to do, I think.

[tsnsystemspieter]

With the understanding that the features are still maturing and under development, we would like to know what the future goals and plans are for the gPTP simulation.

gPTP can be used to synchronize the time of INET clocks which can drift away from each other.

In the quote above you mentioned that gPTP can be used to synchronize the time. But currently we have found this to not be true, as gPTP itself has strict constraints around the Time Error that can be introduced per hop. Currently we cannot simulate gPTP time sync correctly. When using the gPTP max required clock PPM (+- 100ppm), the simulation synchronization accuracy is outside of the gPTP specification. The MAX Time Error for one hop is expected to be about +- 70 to +- 80ns, but the simulation gives us a MAX Time Error of about ~12.5us on the first hop. This is detrimental to all other TSN features that depend on Time Sync.

Are we perhaps misunderstanding the simulation goals of gPTP in OMNET/INET? As currently it cannot be used to simulate gPTP clock accuracy, and all TSN features that depend on it such as the Time Aware Shaper would inherit the gPTP clock error.

[levy]

Hmmm, you make a very good point. I just looked at this issue more deeply. You should know that the gPTP protocol itself is an external contribution to INET (just like most of the protocols) and it seems that the integration wasn't done correctly or completely. When time synchronization happens in the gPTP protocol, the protocol module simply sets the time of the clock and doesn't compensate for the clock drift rate. This happens despite the fact that the grand master relative drift rate is actually calculated in the protocol during time synchronization. So this must be an integration issue between the gPTP protocol and the INET clock interface.

The fix isn't very difficult, but the INET clock interface doesn't support the compensation parameter right now. Of course, this can be added quite easily and the gPTP synchronization can be updated afterwards. I would expect the clock time difference to decrease with several orders of magnitude.

This issue will be fixed soon.

[tsnsystemspieter]

Thank you so much, we really appreciate you looking in to this further and look forward to the patch!

If any assistance is needed in the verification process we are happy to assist.

[levy]

We worked on this issue at the end of last week because it's very important to get this right in order to correctly implement TSN. We added a new feature to INET clocks that allows one to set an oscillator compensation factor. This value is 1.0 by default, which means the clock simply counts the number oscillator ticks, and there's no compensation. Even if the value is 1.0, due to imprecise drifting oscillators (constantly or randomly), clocks drift away from each other over time. Setting the oscillator compensation factor in gPTP to a value calculated from the grand master rate ratio is what is missing, I think. Do you agree with this?

For testing purposes, INET contains a SimpleClockSynchronizer module which synchronizes clocks without actual communication between the nodes, just by looking at the clock times of master and slave nodes. This module does two things when synchronization happens:

• sets the time of the slave clock to the time of the master clock
• sets the oscillator compensation factor to the relative speed of the master and slave clocks, so the rate of change of their clock times become the same

In the following diagram, the slave clocks are periodically synchronized to the master clock both in time and also in the rate of change of their clock times . Then they drift away randomly using a RandomDriftOscillator (which has a random walk model for drifting).

I think this diagram proves that the clocks work as expected and synchronization can be done. Now, the task is to get something very similar using gPTP. Perhaps the result would be less accurate because it uses real communication between the nodes.

We will let you know when we think it works as expected. It would be great if you could help us validating the model.

Best regards

[levy]

The INET branch topic/gptpsynch contains the updated clock model and the fixed gPTP model that supposed to correctly synchronize time between clocks both in terms of their clock time and also the rate of change of their clock time.

We tested the changes in the showcases/tsn/timesynchronization/gptp example OneMasterClock configuration. It's possible to test both gPTP and the above SimpleClockSynchronizer module by uncommenting a few lines in the INI file.

Could you please check the changes in this branch and do some validation tests before we push this into the master branch?

[tsnsystemspieter]

Thanks for the rapid development.
We are currently heading into our Christmas holidays here in the next week. We will attempt to maximize our testing before we close this year.

[levy]

The changes have been merged into the master branch.

[tsnsystemspieter]

Hi Levy,

Thanks for the update!
We are still verifying the workings but it is a definite improvement.
We close for the holidays this afternoon and will only return early January, so our full comment will follow then.

All the best for the festive season.

[levy]

Thanks, have a nice holiday and see you next year!

[adriaan-niess]

Hi everyone,

I was just thinking about using Omnet's gPTP implementation to evaluate some research for which I need a realistic timing model. For my use case I need the time offsets to the grandmaster follow a normal distribution with similar parameters to those of real systems) and I immediately noticed the lack of synthonization (frequency compensation) after having a short look into the documentation page. I was very happy after I saw that an issue was already created.

@levy Thanks a lot for the effort you put into this and that there's already progress. There are a few things I noticed that might be interesting to you regarding the implementation.

In the diagram above you still have a big timing error of ~1us after a synchronization period of 125ms. Note: I assume the distance from the grandmaster to the switch is 1 hop. It's possible to achieve a much higher precision in real systems even with very cheap oscillators and I think the reason is that the drift rate of the oscillator (+- 100ppm) needs to be split into a component-specific part (caused by manufacturing process) which is very much static for individual oscillators and a dynamically changing drift caused by heat, voltage levels, etc.

The component-specific drift rate of each oscillator is much higher than the drift due to heat and due to its static nature it can be fully compensated (more or less). The dynamic drift due to heat that can't be compensated for is a lot smaller than the +-100ppm.

So I propose splitting the drift parameter into two parameters A (static drift offset) and B (dynamic drift change). A is only initialized once when starting the simulation while B is evaluated repeatedly on every tick. The clock ratio at every tick is then composed of A and B, for example with A=uniform(-100ppm, 100ppm) and B=uniform(-1ppm, +1ppm). If B is modeled as a random walk the clock rate could be set to 1.0 + A + B_sum at every tick.

I think this simple model should come a lot closer to real systems and is very simple to implement. If you would add an additional parameter to INET's oscillator module for the "static drift" with a default value of 0 this could be downwards compatible to existing solutions.

Best regards

[levy]

Could you please take a look at https://github.com/inet-framework/inet/blob/master/src/inet/clock/oscillator/RandomDriftOscillator.ned in the master branch of INET, because I think it implements exactly what you are suggesting here. The oscillator drift is a random initial value plus the sum of a random walk process.

[adriaan-niess]

Thanks a lot! This is pretty much exactly what I meant. Seems like I didn't notice that the feature already existed.

[levy]

No problem. Please note that there are changes in that module in the current master branch since INET 4.4 version.

[tsnsystemspieter]

Hi Levy,
Happy new year and thanks again for the rapid development.

From our brief look through the new feature set it is definitely a good improvement over the old system. There are however some concerns that we have identified:

1. The Compensation Factor may require further clarification. Intuitively (for me) the scalar would adjust the calculated drift rate with the minima not being -simTime, but rather 0. With the current setup the compensation factor has to be a value incredibly close to 1 (in excess of 0.9999) to be realistic/usable. A compensation factor of anything below 0.999 yields results that very quickly cause the drift rate to become far too steep.
2. The change of the driftRate parameter to initialDriftRate in the randomDriftOscillator also may need some further clarification. From our understanding the variable has been replaced to ensure there is less confusion. The concern that this raises is the that it is no longer interoperable between constantDriftOscillators and randomDriftOscillators when using wildcards in setup. Is there any reason for this change other than making it more clear that the rate is initial only?

Upon further investigating the IEEE802.1AS-2020 standard there is no single way of synchronising a clock, thus the current method of setting the new clock time is valid. The introduction of a clock servo can be a good future alternative for clock synchronisation. This would have the clock drift rate value be the only value that changes with a synchronisation method such as pi or linear regression. LinuxPTP (ptp4l) implements such a servo.

Any comment on the above is appreciated.

[levy]

Happy New Year!

For 1, the oscillator compensation factor is currently a value around 1. The value 1 means the clock counts 1 for every tick of the oscillator that is no compensation. A value larger than 1 means the clock runs slower, a value less than 1 means the clock runs faster. You are right about having 0.99999 or 1.00001 values are difficult to understand for humans, so we could perhaps store this value in PPM similarly to the drift rates. For example, 1 PPM oscillator compensation factor would mean that for every millionth tick the clock is not incremented, -1 PPM would mean that for every millionth tick the clock is incremented twice. Is this what you are suggesting?

For 2, initialFoo is often used in such sense in INET, so we think that these parameter names are good as they are. We understand your reasons but these parameters work differently. For example, if you change the driftRate parameter of a ConstantDriftOscillator while the simulation is running, then it will affect the drift immediately, but this isn't the case for the initialDriftRate parameter of RandomDriftOscillator.

For the last point, the describe clock servo could even be an optional mode of operation of the Gptp module. So instead of setting the clock time at the current synchronization point, Gptp would overshoot the oscillator compensation factor in a way that causes the slave clock to catch up with the master clock by the time of the next synchronization point.

[tsnsystemspieter]

1. The suggestion of using ppm to offset from 1 does sound more intuitive and is a great solution in our opinion.
2. Ok, this makes sense.
3. Having servo options would prove very useful, particularly for comparison to real world deployments of gPTP. Several servo types could be made available as options (eg. none, pi, linear, etc). A good point of reference for its implementation could be ptp4linux, the servo.c file contains all of their setup. This tool is commonly used and thus can be considered a good reference point. Implementing this into OMNeT++/INET would also allow for the simulation of the servo type and its parameters and thus the selection of the most applicable values to achieve a desired behavior for real world use.

[adriaan-niess]

If the clock servo is implemented as proportional integral (PI) controller it would be nice to be able to configure

1. The proportional- and integral gain parameters for the PI controller.
2. A threshold for the clock error. If the threshold is exceeded the local time is set directly to the grandmaster's time (phase jump). In the first synchronization interval after the start-up the clock error might be too large to be compensated by a controller in a reasonable amount of time, because in off-the-shelf processors there are some limitations how fast/slow dynamic clock dividers can be configured.

[levy]

I created a separate issue for the gPTP clock servo feature.

[levy]

The remaining part of this issue, changing the internal representation of the oscillator compensation to PPM, has been pushed to the master branch. There's nothing left, so I'll close this issue.