Need help to calculate gptp time

[keyurparekh1]

Hello,

I am currently debugging gptp daemon. I have intel card hardware. Now how can I make sure that local time in gptp daemon and Intel hardware counter time is in sync? Can you let me know how I can get those two times?

Thanks & Regards, Keyur Parekh

[intel-ethernet]

+Chris Hall, our gPTP expert.

“making sure” the gPTP daemon time and the LAN hardware counter time are in sync requires some statistic analysis.

There are two components to being ‘in-sync’. You have to match frequency. Then you have to match phase. Frequency means the LAN wallclock increments at the same rate as your local gPTP notion of time. Phase means that you have applied corrections to the master gPTP time and figured out the offset to the local LAN time. Some implementations let the LAN wallclock run at its own rate and apply pure software corrections to derive the gPTP time. Probably the ‘easier’ path however is to correct the frequency on the LAN timer using the linux phc adjustment APIs on the LAN interface (but maybe or maybe not correcting for phase – as phase corrections can lead to ‘jumps’ depending how they are done)

To figure out frequency requires multiple samples of the LAN timestamps and the gPTP master time intervals, and you typically perform a least-squares or other method to average out the jitter / noise. Then once frequency is locked you sort out the apparent offset between your local time and gPTP time (again averaging out the noise).

Getting the local time (of the LAN) eventually bumps into a jittery noise barrier … typically, with current state of the art, sw running on the host samples the CPU timestamp counter (RDTSC on Intel CPUs), reads the system time (SYSTIME) registers on the LAN device, and then reads the timestamp counter again to bracket the TSC values and the system time. You can see this in the igb readwallclock() API.

In practice this method can be hard – depending on CPU generation and SKU. Sometimes, not all CPUs on all cores had the same instantaneous idea of TSC. Other times the CPUs would go into power management states and slow down or stop the TSC counter for periods of time. And then depending whether you had a client or server CPU sku, and exactly where the device is located – either directly attached to the CPU PCIe, or hanging off of a bridge of a bridge of a bridge - the latency to read the device register can vary by several microseconds. Considering the gPTP time is in nanoseconds, this variance will certainly impact accuracy.

Some have resorted to centering all time around the LAN interface, although this leads to other issues (as typically you need to sample other sources to the LAN wallclock to convert back and forth – like audio or video media clocks). The standard retail I210 cards have a header (for instance) which enables (2) pins to be used to drive a timed output or sample a pin as an input for this purpose. Keeping things centered around a pervasive clock reference like TSC has its advantages.

So – depending on your level of fidelity – you may have a lot of characterization to do.

Hope this helps. ekm

From: Keyur [mailto:notifications@github.com] Sent: Wednesday, April 09, 2014 6:37 PM To: intel-ethernet/Open-AVB Subject: [Open-AVB] Need help to calculate gptp time (#56)

Hello,

I am currently debugging gptp daemon. I have intel card hardware. Now how can I make sure that local time in gptp daemon and Intel hardware counter time is in sync? Can you let me know how I can get those two times?

Thanks & Regards, Keyur Parekh

— Reply to this email directly or view it on GitHubhttps://github.com/intel-ethernet/Open-AVB/issues/56.

[keyurparekh1]

Hello,

Thanks very much for the reply. I gone through your message and have some questions.

Currently we are following coarse method to update hardware register time. If our system is gptp slave than we need to match grand master time. So for this what we did is, in gptp daemon, when we get followup message from master, we compare that time with current hardware register time and take difference between these two times. If there is any delta than we write that delta to slave device hardware register and set the update bit. So that delta will be added to slave device hardware registers. So we believe in coarse method that is only enough to be in sync with master.

So can you guide me whatever method I am following is correct or not? Or I am missing out something else?

Awaiting for your valuable reply.

Thanks & Regards, Keyur Parekh

[intel-ethernet]

I would look at the code here - https://github.com/richardcochran/linuxptp-as/blob/master/clockadj.c - to how to adjust (1st) the frequency, and then (2nd) the phase offset if any.

e.g. clockadj_set_freq() to increase or decrease the local clock rate to match the GM rate, and then clockadj_step() to correct any phase error once you get frequency corrected. These methods themselves use the Linux APIs defined for PTP timestamping support.

Does this help?

ekm

From: Keyur [mailto:notifications@github.com] Sent: Wednesday, April 16, 2014 10:28 AM To: intel-ethernet/Open-AVB Cc: Mann, Eric Subject: Re: [Open-AVB] Need help to calculate gptp time (#56)

Hello,

Thanks very much for the reply. I gone through your message and have some questions.

Currently we are following coarse method to update hardware register time. If our system is gptp slave than we need to match grand master time. So for this what we did is, in gptp daemon, when we get followup message from master, we compare that time with current hardware register time and take difference between these two times. If there is any delta than we write that delta to slave device hardware register and set the update bit. So that delta will be added to slave device hardware registers. So we believe in coarse method that is only enough to be in sync with master.

So can you guide me whatever method I am following is correct or not? Or I am missing out something else?

Awaiting for your valuable reply.

Thanks & Regards, Keyur Parekh

— Reply to this email directly or view it on GitHubhttps://github.com/intel-ethernet/Open-AVB/issues/56#issuecomment-40627381.

[christopher-s-hall]

Hi Keyur,

You might want to take a look at the -S flag for the Linux source. In the source it is referred to as "syntonization", but it is really synchronization. We've had this working in the lab with very good results using the I210.

Run "daemon_cl ethX -S" to synchronize the local slave clock to that of the master. If you're interested in how to adapt this for your own purposes, take a look in setMasterOffset (in ieee1588clock.cpp) and use of the _syntonization flag.

Hope this helps.

Chris

[keyurparekh1]

Hi Chris,

I will certainly look into that. So what I understand from your answer is that, the open source gptp daemon support to correct time. So i need to download gptp daemon and run with -s flag? is that right understanding?

Thanks & Regard, Keyur Parekh

[christopher-s-hall]

Keyur,

That's right. It adjusts the local network clock to match master clock when in slave mode. I think we've only tested this with two I210s connected together, but it should work with a switch also. This should be considered reference code, but the results were good when we tested it. As Eric mentions above, the I210 can generate a PPS output and verify that the clocks are actually synchronized. To enable this output, use the -p flag.

Chris

[keyurparekh1]

Hello,

I have gone through files which you suggested. ieee1588clock.cpp.

In that there is one function setMasterOffset and that function provide me some parameters like

master_local_offset local_system_offset master_local_freq_offset local_system_freq_offset local_time

So from above parameters what I understood is, if I want my system to be synchronize with master time than I need to use master_local_offset variable. I need to add or subtract this value from my current hardware registers. Is that correct understanding?

[SumeetPJain]

setMasterOffset (in ieee1588clock.cpp) only updates the shared memory parameters like the ones @keyurparekh1 mentioned above. Right ?

[SumeetPJain]

Our hardware doesnot support any frequency synchronization. Means our HW is not capable of tuning its frequency. That means that we have to keep on calculating the master-slave clock difference in the daemon and then keep updating the LAN HW Counters everytime the follow-up message reaches the slave. Now the code for calculating the master-slave clock difference is as follow :

/* Coarse Method */ MasterClockTime = TIMESTAMP_TO_NS(preciseOriginTimestamp) + delay; // Master Clock Time(delay = link_delay) ClockDiffCount = MasterClockTime - TIMESTAMP_TO_NS(sync_arrival); // Time difference between master and slave (offset) // printf("FreqScaleFactor = %llu", ClockDiffCount); port->SendFreqScaleFact(ClockDiffCount);

(This piece of code is our implementation inside PTPMessageFollowUp:processMessage function because at this stage we have sync depart and arrival times aswell as the delay) The SendFreqScaleFact function makes an ioctl call to our driver to update the HW counters. This is how we are maintaining master-slave to be in sync. I understand the importance of the frequency locking but unfortunately its not supported by our HW. With this limitations, is this implemention sufficient or we can improve it more ? Any inputs will be of great help.

-Sumeet

[andrew-elder]

You shouldn't ever have to write to the hardware timestamping counter. Instead use the offset and rateRatio to convert local counter timestamps to master PTP time.

---

From: "engineerdrmz" notifications@github.com Sent: Friday, April 18, 2014 9:00 AM To: "intel-ethernet/Open-AVB" Open-AVB@noreply.github.com Subject: Re: [Open-AVB] Need help to calculate gptp time (#56)

Our hardware doesnot support any frequency synchronization. Means our HW is not capable of tuning its frequency. That means that we have to keep on calculating the master-slave clock difference in the daemon and then keep updating the LAN HW Counters everytime the follow-up message reaches the slave. Now the code for calculating the master-slave clock difference is as follow : /* Coarse Method */ MasterClockTime = TIMESTAMP_TO_NS(preciseOriginTimestamp) + delay; // Master Clock Time(delay = link_delay) ClockDiffCount = MasterClockTime - TIMESTAMP_TO_NS(sync_arrival); // Time difference between master and slave (offset) // printf("FreqScaleFactor = %llu", ClockDiffCount); port->SendFreqScaleFact(ClockDiffCount); (This piece of code is our implementation inside PTPMessageFollowUp:processMessage function because at this stage we have sync depart and arrival times aswell as the delay) The SendFreqScaleFact function makes an ioctl call to our driver to update the HW counters. This is how we are maintaining master-slave to be in sync. I understand the importance of the frequency locking but unfortunately its not suppoprted by our HW. With this limitations, is this implemention sufficient or we can improve it more ? Any inputs will be of great help.

-Sumeet

Reply to this email directly or view it on GitHub.

[SumeetPJain]

Hi andrew,

Thanks for the response and time. Can you help me to understand this as how I can use this parameters(offset and rateRatio) to covert local counter TS to master PTP time? Actually I am not writing to the HW counters directly but I am writing the offsets(difference between Master-Slave time) to the TS_Update registers which are there in our HW and they automatically update(add/subract values with TS_Update) the actual HW counter registers with the values in their(TS_Update) registers.

[intel-ethernet]

The general concept is described in the publically available AVnu SW-API Best Practices document located at:

http://www.avnu.org/files/static_page_files/C5E0B5F8-1D09-3519-ADB32F1F88E6C057/AVnu_SWAPIs_v1.0.pdf

ekm

From: engineerdrmz [mailto:notifications@github.com] Sent: Friday, April 18, 2014 6:51 AM To: intel-ethernet/Open-AVB Cc: Mann, Eric Subject: Re: [Open-AVB] Need help to calculate gptp time (#56)

Hi andrew,

Thanks for the response and time. Can you help me to understand this as how I can use this parameters(offset and rateRatio) to covert local counter TS to master PTP time?

— Reply to this email directly or view it on GitHubhttps://github.com/intel-ethernet/Open-AVB/issues/56#issuecomment-40809761.

[SumeetPJain]

Hi Andrew,

Can you please elaborate as how I can use the offset and rateRatio to convert local counter timestamps to master PTP time.?. I understand that the idea of updating the HW counters is not logical.

Any inputs will of great help.

-Sumeet

[andrew-elder]

Hi Sumeet,

It is actually outside my area of expertise. I only know that in principle it is possible. Perhaps someone else can chime in. Did you review the document that was posted?

On 4/22/2014 9:05 AM, engineerdrmz wrote:

Hi Andrew,

Can you please elaborate as how I can use the offset and rateRatio to convert local counter timestamps to master PTP time.?. I understand that the idea of updating the HW counters is not logical.

Any inputs will of great help.

-Sumeet

— Reply to this email directly or view it on GitHub https://github.com/intel-ethernet/Open-AVB/issues/56#issuecomment-41036626.

Andrew Elder AudioScience, Inc. +1-585-271-8870 www.audioscience.com

[keyurparekh1]

Hello andrew,

I have one doubt, if you can help me in that, it will be great for me to resolve issue.

When My system will behave as slave it need to update its time according to master time.

So what I am doing is, whenever I am updating my system time, I am putting time stamp uncertain bit = 1 and time stamp invalid = 0 in my 1722 application. So when I am updating hardware registers, for that amount of time my all 1722 packets does not have valid time. So those packets will not block in hardware.

Is that valid scheme? Please let me know for this.

Thanks & Regards, Keyur Parekh

[jdkoftinoff]

'tu' should be set to 0 when you know you are transitioning between grand masters. This tells the receiver that the avtp_timestamp value may be uncertain even if it is set.

However the 'tv' bit, for subtype 0, is to be set based on the value of the dbc and the sample count in the packet. This tells the receiver that the avtp_timestamp field contains a value and that the timestamp is for a specific sample within the packet (not necessarily the first sample!)

The following table describes the data block number within the AVTPDU that is time stamped, based on the AVTPDU’s DBC field value and a 48 kHz stream where SYT_INTERVAL is 8 and the number of data blocks (samples) in the AVTPDU is 6:

mod( dbc, SYT_INTERVAL)	Time stamped sample index	tv value
0	0	1
1	7	0 (since there is no 8th sample)
2	6	0 (since there is no 7th sample)
3	5	1
4	4	1
5	3	1
6	2	1
7	1	1

The “Time stamped sample index” column in the above table is calculated by the function defined in IEEE Std 1722-2011 Clause 6.4.4:

mod((SYT_INTERVAL – mod(DBC, SYT_INTERVAL), SYT_INTERVAL )

[keyurparekh1]

Hello,

Thanks very much for your reply. So can you tell me if I set tu bit == 1 than how can I handle those packets at listener side? Do I need to ignore time stamp in those packets?

Thanks & Regards, Keyur Parekh

[jdkoftinoff]

it depends on your implementation. You can monitor it and see if it makes sense and ignore it if it doesn't

[andrew-elder]

Keyur, Has your question been answered? Thanks, Andrew

[pinealservo]

Closing due to lack of response.