Re: [chrony-users] makestep in Chrony

Ublox makes a nice family of receivers. I am currently using a EVK-7PAM evaluation kit connected by a RS-232 serial cable to the computer. PPS comes in over the DCD/RI control lines on the port and is handled by KPPS in the kernel. I power it with a USB cable connected to a small USB charger. I

Re: [chrony-users] makestep in Chrony

William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 Physics _|___ Advanced Research _| Fax: +1(604)822-5324 UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ On Wed, 16 May 2018,

Re: [chrony-users] makestep in Chrony

Wow, that's pretty amazing.  I probably will buy one to play around given such low cost.  I just looked up online...40$ shipping included. But then I think I can't use it in the data center as I don't think it can receive the GPS signal. On Wednesday, May 16, 2018, 10:27:34 AM GMT+8, Bill

Re: [chrony-users] makestep in Chrony

I use a cheap GPS/PPS card (Sure electronics. Cost $50). which keeps my machine in the sub-usec range. (On chrony, here is the output of the tracking Reference ID: 50505330 (PPS0) Stratum : 1 Ref time (UTC) : Wed May 16 02:15:54 2018 System time : 0.1 seconds fast of

Re: [chrony-users] makestep in Chrony

Hi Bill, Let's say I am willing to spend 1K-2K USD for any hardware that can give accurate time (in millisecond without drifting) and that hardware can be installed in a 1U server, then I think it could be a good solution.  Any tip?  Anything installed outside the server isn't allowed. On

Re: [chrony-users] makestep in Chrony

William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 Physics _|___ Advanced Research _| Fax: +1(604)822-5324 UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ On Tue, 15 May 2018,

Re: [chrony-users] makestep in Chrony

On 05/15/2018 05:56 AM, Alexander Bisogiannis wrote: On Tue, 15 May, 2018 at 1:53 PM, Stephen Satchell wrote: Now, in a VM object, the base clock used for timekeeping is almost worthless because the error and jitter fall outside of those boundaries.  That's why I scream and

Re: [chrony-users] makestep in Chrony

On Tue, May 15, 2018 at 05:53:25AM -0700, Stephen Satchell wrote: > Both NTP and chrony assume that the base clock has an absolute accurate of > 100 ppm or better, and a relative accuracy of 5 ppm or better. There is no such assumption in chrony. It will work fine with any frequency offset that

Re: [chrony-users] makestep in Chrony

On 05/15/2018 04:23 AM, Hei Chan wrote: Since the application calling rdtsc+clock_gettime()+rdtsc (to create the mapping file) has its own dedicated core, and this application is only called after "chronyd -q 'pool [some NTP server/switch which is 1 switch away] iburst'" returns, at that time, I

Re: [chrony-users] makestep in Chrony

Hi Bill, I think you are indeed confused.  I want accuracy in 100s of ns range.  But again I want no jitter/extra latency in my application. In all my measurement from point A to point B, the time span is less than 15 micro 99.% of the time (0.0001% for the undesired jitter).  And the

Re: [chrony-users] makestep in Chrony

On Tue, May 15, 2018 at 05:57:04AM +, Hei Chan wrote: > If I remember correctly that there was a post explaining why it wasn't a > bug, the post mentioned the value was written to a shared memory (or some > sort), and the writer and reader aren't protected by a lock for performance >

Re: [chrony-users] makestep in Chrony

On Tue, 15 May 2018, Hei Chan wrote: If I remember correctly that there was a post explaining why it wasn't a bug, the post mentioned the value was written to a shared memory (or some sort), and the writer and reader aren't protected by a lock for performance reason, and so it needs to spin

Re: [chrony-users] makestep in Chrony

If I remember correctly that there was a post explaining why it wasn't a bug, the post mentioned the value was written to a shared memory (or some sort), and the writer and reader aren't protected by a lock for performance reason, and so it needs to spin (i.e while loop) to get the value out

Re: [chrony-users] makestep in Chrony

On Tue, 15 May 2018, Hei Chan wrote: Hi Bill, Here is the source: https://elixir.bootlin.com/linux/v4.9/source/arch/x86/entry/vdso/vclock_gettime.c#L183 As you can see, clock_gettime() is in a while loop because sometimes, it might fail... Hm, yes. How much of a time delay do you get

Re: [chrony-users] makestep in Chrony

Hi Bill, Here is the source:https://elixir.bootlin.com/linux/v4.9/source/arch/x86/entry/vdso/vclock_gettime.c#L183 As you can see, clock_gettime() is in a while loop because sometimes, it might fail... On Tuesday, May 15, 2018, 11:26:12 AM GMT+8, Bill Unruh wrote:

Re: [chrony-users] makestep in Chrony

On Tue, 15 May 2018, Hei Chan wrote: Thanks for your reply. See my comment inline. On Friday, May 11, 2018, 4:26:14 PM GMT+8, Miroslav Lichvar wrote: On Fri, May 11, 2018 at 12:30:30AM +, Hei Chan wrote: >  Hi Bill, > Sorry that I wasn't clear. > What I tried to

Re: [chrony-users] makestep in Chrony

Thanks for your reply. See my comment inline. On Friday, May 11, 2018, 4:26:14 PM GMT+8, Miroslav Lichvar wrote: On Fri, May 11, 2018 at 12:30:30AM +, Hei Chan wrote: >  Hi Bill, > Sorry that I wasn't clear. > What I tried to do is to call clock_gettime() and

Re: [chrony-users] makestep in Chrony

From wiki (Time Stamp Counter - Wikipedia): | | | | | | | | | | | Time Stamp Counter - Wikipedia | | | "Recent Intel processors include a constant rate TSC (identified by the kern.timecounter.invariant_tsc sysctl on FreeBSD or by the "constant_tsc" flag in Linux's

Re: [chrony-users] makestep in Chrony

It would be best to have as many people look at this so as to maximize the chance of getting a solution. As far as I know, theTSC will change due to temp, to power management of the cpu, to hibernation, etc. Ie, I am not at all sure that the tsc is as good a "clock" as you think. I would trust

Re: [chrony-users] makestep in Chrony

I guess I am still confused. The system clock usually uses something like the tsc as the clock, and all chrony does is to change the interpretation (clicks per second) of that reading. Now you want to use the system time to determine the clicks per second of the tsc? Ie, it is unclear to me why

Re: [chrony-users] makestep in Chrony

Hi Bill, Sorry that I wasn't clear. What I tried to do is to call clock_gettime() and rdtsc(p) as soon as chrony finishes synch so that I can get the best estimate when I try to derive time from (invariant) tsc. Ideally, I have a C application that calls chrony's API (if there is one) similar

Re: [chrony-users] makestep in Chrony

I am not sure what you mean. chrony syncs constantly, and once it is running, it, unless some disaster comes along, like you deciding to "test" it by changing the clock out from under chrony, it will keep the clock within the tightest bounds possible given the server/refclock it uses. Just leave

Re: [chrony-users] makestep in Chrony

Hello Hei, i use the call chronyc waitsync 1 1 500 for knowing if chrony has already achieved synchronization. Attached a trivial shell script which you can use as boolean command: chrony_is_synced && do_something || fail_somehow_if_not_synced or you can call it

Re: [chrony-users] makestep in Chrony

Thanks Miroslav and Bill! One last related question -- how can I be able to tell the sync/calibration is done after I manually ask chrony to synch/calibrate? I saw one of the posts 4 years ago suggesting that there is no way? Which command is better to force chrony to synchronize time right now

Re: [chrony-users] makestep in Chrony

William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 Physics _|___ Advanced Research _| Fax: +1(604)822-5324 UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ On Wed, 9 May 2018,

Re: [chrony-users] makestep in Chrony

On Sun, May 06, 2018 at 10:30:48AM +, Hei Chan wrote: > Hi, > I am reading this:https://chrony.tuxfamily.org/manual.html#makestep-command > It mentions, "Normally chronyd will cause the system to gradually correct any > time offset, by slowing down or speeding up the clock as required".  Most