Re: [chrony-users] chrony receiveing GPS timestamp over UDP packet to up

Hi Tom,

First of all thank you very much for your reply.

In my system there are two to three cars. All cars are having embedded board. It receive GPS as well as vehicle status data & give it to our application. Our application detects any accident scenarios based on GPS information & other parameters.

We can't do field test again & again as our application is evolving . We decided to simulate the things.

So we are logging GPS time stamp value to a file with other required parameters. This file we are using to give inputs to our application over UDP at later point of time.

But all the cars(embedded board) should sync to exact time stamp to simulate the things properly.

I can have tolerance of 20ms.(i.e. 20ms system time forward or backward).

It will be very helpful if you tell me a better approach to achieve this.

Thanks again,

Pratik Pawar

On Sun, Apr 19, 2015 at 9:03 PM, Tomalak Geret'kal <tom@xxxxxxxxx> wrote:

On 19/04/2015 09:42, Pratik Pawar wrote:

Hi All,

I have one strange question about chrony.

I am using chrony to keep embedded board system time in sync. When GPS receiver is connected to board, It can able to sync system time with very negligible deviation. The reference clock for chrony are PPS & SHM.

Whenever GPS receiver got new time stamp, application log that value into a file as well as Same timestamp is being given to SHM. GPS receiver is sending updated time stamp at every 200ms.

I want to simulate same think. For this I am reading logged timestamp from file & sending it through UDP packet at 200ms interval using another application.

Embedded board receive that UDP packet extract timestamp information & write it into SHM.

With this approach chrony able to get SHM data & sync system time. But I am getting lots of deviation. PPS is disable only SHM is enable for this chrony.

Can any one tell me a better approach or previous experience to achieve this.

You can't "simulate" a time reference source. If it were any good then it would be an actual time reference source.

Having a list of timestamps in a file is completely useless; presumably you're sleeping for 200ms in that "another application" and now that operation, as well as the delay in reading from the file and sending the packet over UDP, is your new timebase. That is going to be orders of magnitude less stable than just using the existing, unreferenced system clock in the first place (which is driven by an oscillator, not by entirely unpredictable mechanical movements, memory congestion, CPU congestion, network conditions...).

You should rethink your goal here.

Hope that helps
Tom