Re: [chrony-users] makestep in Chrony

[Burton, John]

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 use that setup as a level 1 clock for my engineering network.

John

On Wed, May 16, 2018 at 2:24 AM, Bill Unruh  wrote:

> Actually I was looking at it seems Sure no longer makes that gps board, or
> at
> least I cannot find it using google or ebay.
> Not sure what the best gps card is now.
>
>
>
> 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, Hei Chan wrote:
>
> 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 Unruh <
>> un...@physics.ubc.ca> wrote:
>>
>>
>> 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 NTP time
>> Last offset: -0.00042 seconds
>> RMS offset  : 0.00167 seconds
>> Frequency  : 4.447 ppm fast
>> Residual freq  : -0.000 ppm
>> Skew: 0.002 ppm
>> Root delay  : 0.1 seconds
>> Root dispersion : 0.15283 seconds
>> Update interval : 16.0 seconds
>> Leap status: Normal
>>
>>
>> and the PPS sources line
>>
>> #* PPS0  0  4  37723  -348ns[ -375ns] +/-
>> 334ns
>>
>> I do not have experience with the atomic clocks available.
>>
>> I know they exist.
>> One step would be to put in an over controled crystal into your machine.
>> That
>> would bring the tsc drift down substantially. One could even use the
>> thermal
>> compensation that I think exists in chrony. I have not used it so have no
>> advice on setting it up.
>> (It uses one of the motherboard thermometers as a proxy for the crystal
>> temperature, and fits to the drift as a function of temperature assuming a
>> linear relationship.
>>
>>
>>
>>
>>
>>
>> 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, Hei Chan wrote:
>>
>> > 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 Tuesday, May 15, 2018, 11:01:44 PM GMT+8, Bill Unruh <
>> un...@physics.ubc.ca> wrote:
>> >
>> >
>> >
>> > On Tue, 15 May 2018, Hei Chan wrote:
>> >
>> > > 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.
>> >
>> > That is really tough. And you are operating with your hands tied behind
>> your
>> > back.
>> >
>> > >
>> > > 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
>> measurement is
>> > taken
>> > > probably 1.5 billion times (or more a day) in multiple cores (~10?).
>> As you can
>> see
>> > > timestamping happens very frequent in my system.  Hence, that's why I
>> have a weird
>> > > thought of using rdtsc-clock_gettime() map.
>> >
>> > Sure. The designers of the Linux clock had the same idea.
>> >
>> > >
>> > > I have to admit that I don't know how to use the chrony/ntp's
>> parameters very
>> well.
>> > > What parameters would you recommend with a NTP source that is one hop
>> a way within
>> > the
>> > > same data center?
>> >
>> > And how is that ntp source disciplined? How do you know that the time
>> > delivered by that source has any accuracy whatsoever. And added to
>> that, there
>> > are the transmission problems. The hubs and routers between your
>> machine and
>> > that ntp source introduce jitter and delays. Contention for the ethernet
>> > introduces jitter. The interrupt handling in your computer introduces
>> jitter.
>> > The abysmally slow network (even gigabit cable takes microseconds to
>> send a
>> > packet down the 

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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, Hei Chan wrote:


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.


You do need a window or something like that to put the antenna in. but you can
run a pretty long cable (speed of light is a foot per nanosecond, slightly
less in a cable. ) So you can put the receiver and antenna somewhere where
they can see the sky, and then run even say cat 5 cable from there to the
computer. wire it up so that you use the usb power on the computer to drive
the receiver, and two of the other lines for the serial port, or even usb port
and the fifth line for the PPS.

Unforunately the PPS has, as it comes, no line already ready to deliver pps to
the computer, so you need to solder a line across the board to the serial port
interrupt line. You can estimate the transmission time along the wire by
something like .2m/ns, and tell chrony to subtract that time from the receipt
time of the pulse.





On Wednesday, May 16, 2018, 10:27:34 AM GMT+8, Bill Unruh 
 wrote:


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 NTP time
Last offset    : -0.00042 seconds
RMS offset      : 0.00167 seconds
Frequency      : 4.447 ppm fast
Residual freq  : -0.000 ppm
Skew            : 0.002 ppm
Root delay      : 0.1 seconds
Root dispersion : 0.15283 seconds
Update interval : 16.0 seconds
Leap status    : Normal


and the PPS sources line

#* PPS0                          0  4  377    23  -348ns[ -375ns] +/- 334ns

I do not have experience with the atomic clocks available.

I know they exist.
One step would be to put in an over controled crystal into your machine. That
would bring the tsc drift down substantially. One could even use the thermal
compensation that I think exists in chrony. I have not used it so have no
advice on setting it up.
(It uses one of the motherboard thermometers as a proxy for the crystal
temperature, and fits to the drift as a function of temperature assuming a
linear relationship.






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, Hei Chan wrote:

> 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 Tuesday, May 15, 2018, 11:01:44 PM GMT+8, Bill Unruh 
 wrote:
>
>
>
> On Tue, 15 May 2018, Hei Chan wrote:
>
> > 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.
>
> That is really tough. And you are operating with your hands tied behind your
> back.
>
> >
> > 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 
measurement is
> taken
> > probably 1.5 billion times (or more a day) in multiple cores (~10?).  As 
you can
see
> > timestamping happens very frequent in my system.  Hence, that's why I have 
a weird
> > thought of using rdtsc-clock_gettime() map.
>
> Sure. The designers of the Linux clock had the same idea.
>
> >
> > I have to admit that I don't know how to use the chrony/ntp's parameters 
very
well. 
> > What parameters would you recommend with a NTP source that is one hop a way 
within
> the
> > same data center?
>
> And how is that ntp source disciplined? How do you know that the time
> delivered by that source has any accuracy whatsoever. And added to that, there
> are the transmission problems. The hubs and routers between your machine and
> that ntp source introduce jitter and delays. Contention for the ethernet
> introduces jitter. The interrupt handling in your computer introduces jitter.
> The abysmally slow network (even gigabit cable takes microseconds to send a
> packet down the line, and then there is teh behaviour of the ethernet cards
> which will amass data and only send it when enough has accumulated and it
> feels 

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 Unruh 
 wrote:  
 
 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 NTP time
Last offset    : -0.00042 seconds
RMS offset      : 0.00167 seconds
Frequency      : 4.447 ppm fast
Residual freq  : -0.000 ppm
Skew            : 0.002 ppm
Root delay      : 0.1 seconds
Root dispersion : 0.15283 seconds
Update interval : 16.0 seconds
Leap status    : Normal


and the PPS sources line

#* PPS0                          0  4  377    23  -348ns[ -375ns] +/- 334ns

I do not have experience with the atomic clocks available.

I know they exist. 
One step would be to put in an over controled crystal into your machine. That
would bring the tsc drift down substantially. One could even use the thermal
compensation that I think exists in chrony. I have not used it so have no
advice on setting it up.
(It uses one of the motherboard thermometers as a proxy for the crystal
temperature, and fits to the drift as a function of temperature assuming a
linear relationship.






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, Hei Chan wrote:

> 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 Tuesday, May 15, 2018, 11:01:44 PM GMT+8, Bill Unruh 
>  wrote:
> 
> 
> 
> On Tue, 15 May 2018, Hei Chan wrote:
> 
> > 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.
> 
> That is really tough. And you are operating with your hands tied behind your
> back.
> 
> >
> > 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 
> > measurement is
> taken
> > probably 1.5 billion times (or more a day) in multiple cores (~10?).  As 
> > you can see
> > timestamping happens very frequent in my system.  Hence, that's why I have 
> > a weird
> > thought of using rdtsc-clock_gettime() map.
> 
> Sure. The designers of the Linux clock had the same idea.
> 
> >
> > I have to admit that I don't know how to use the chrony/ntp's parameters 
> > very well. 
> > What parameters would you recommend with a NTP source that is one hop a way 
> > within
> the
> > same data center?
> 
> And how is that ntp source disciplined? How do you know that the time
> delivered by that source has any accuracy whatsoever. And added to that, there
> are the transmission problems. The hubs and routers between your machine and
> that ntp source introduce jitter and delays. Contention for the ethernet
> introduces jitter. The interrupt handling in your computer introduces jitter.
> The abysmally slow network (even gigabit cable takes microseconds to send a
> packet down the line, and then there is teh behaviour of the ethernet cards
> which will amass data and only send it when enough has accumulated and it
> feels like sending something. If you want accurate times you HAVE to have
> something like gps/pps and to get tens of nanosecond precision, you need to 
> have a
> pretty sophisticated one.
> 
> 
> >
> > So what would you suggest me to use to synchronize in a datacenter that PTP 
> > isn't
> > available and GPS clock isn't allowed?
> 
> Here is one of the worl'd foremost watches. Now I want to repair it, but you
> must wear boxing gloved while doing so, and you are not allowed to remove them
> for any reason.
> 
> >
> > And indeed I have thought about a better solution for quiet some time 
> > because of the
> > conditions above and temperature effect on TSC.  But I can't think of a way 
> > to
> measure
> > from A to B without jitter and latency, and at the same time, I would like 
> > to know
> the
> > approximate epoch time of each "timestamping".  (again no jitter/latency is 
> > more
> 
> approximate? century? year? day, second, millisecond, microsecond nanosecond?
> 
> 
> > important than accuracy of the epoch time.).
> 
> But make sure you never remove those gloves.
> 

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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 NTP time
Last offset : -0.00042 seconds
RMS offset  : 0.00167 seconds
Frequency   : 4.447 ppm fast
Residual freq   : -0.000 ppm
Skew: 0.002 ppm
Root delay  : 0.1 seconds
Root dispersion : 0.15283 seconds
Update interval : 16.0 seconds
Leap status : Normal


and the PPS sources line

#* PPS0  0   4   37723   -348ns[ -375ns] +/- 334ns

I do not have experience with the atomic clocks available.

I know they exist. 
One step would be to put in an over controled crystal into your machine. That

would bring the tsc drift down substantially. One could even use the thermal
compensation that I think exists in chrony. I have not used it so have no
advice on setting it up.
(It uses one of the motherboard thermometers as a proxy for the crystal
temperature, and fits to the drift as a function of temperature assuming a
linear relationship.






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, Hei Chan wrote:


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 Tuesday, May 15, 2018, 11:01:44 PM GMT+8, Bill Unruh  
wrote:



On Tue, 15 May 2018, Hei Chan wrote:

> 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.

That is really tough. And you are operating with your hands tied behind your
back.

>
> 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 measurement 
is
taken
> probably 1.5 billion times (or more a day) in multiple cores (~10?).  As you 
can see
> timestamping happens very frequent in my system.  Hence, that's why I have a 
weird
> thought of using rdtsc-clock_gettime() map.

Sure. The designers of the Linux clock had the same idea.

>
> I have to admit that I don't know how to use the chrony/ntp's parameters very 
well. 
> What parameters would you recommend with a NTP source that is one hop a way 
within
the
> same data center?

And how is that ntp source disciplined? How do you know that the time
delivered by that source has any accuracy whatsoever. And added to that, there
are the transmission problems. The hubs and routers between your machine and
that ntp source introduce jitter and delays. Contention for the ethernet
introduces jitter. The interrupt handling in your computer introduces jitter.
The abysmally slow network (even gigabit cable takes microseconds to send a
packet down the line, and then there is teh behaviour of the ethernet cards
which will amass data and only send it when enough has accumulated and it
feels like sending something. If you want accurate times you HAVE to have
something like gps/pps and to get tens of nanosecond precision, you need to 
have a
pretty sophisticated one.


>
> So what would you suggest me to use to synchronize in a datacenter that PTP 
isn't
> available and GPS clock isn't allowed?

Here is one of the worl'd foremost watches. Now I want to repair it, but you
must wear boxing gloved while doing so, and you are not allowed to remove them
for any reason.

>
> And indeed I have thought about a better solution for quiet some time because 
of the
> conditions above and temperature effect on TSC.  But I can't think of a way to
measure
> from A to B without jitter and latency, and at the same time, I would like to 
know
the
> approximate epoch time of each "timestamping".  (again no jitter/latency is 
more

approximate? century? year? day, second, millisecond, microsecond nanosecond?


> important than accuracy of the epoch time.).

But make sure you never remove those gloves.


>
> If you have a good suggestion, i am all ears.

And at a budget of $50? How much are you willing to spend?

>
> Thanks!
>
>
> On Tuesday, May 15, 2018, 2:58:52 PM GMT+8, Bill Unruh  
wrote:
>
>
>
> 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 

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 Tuesday, May 15, 2018, 11:01:44 PM GMT+8, Bill Unruh 
 wrote:  
 
 
On Tue, 15 May 2018, Hei Chan wrote:

> 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.

That is really tough. And you are operating with your hands tied behind your
back.

> 
> 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 measurement 
> is taken
> probably 1.5 billion times (or more a day) in multiple cores (~10?).  As you 
> can see
> timestamping happens very frequent in my system.  Hence, that's why I have a 
> weird
> thought of using rdtsc-clock_gettime() map.

Sure. The designers of the Linux clock had the same idea.

> 
> I have to admit that I don't know how to use the chrony/ntp's parameters very 
> well. 
> What parameters would you recommend with a NTP source that is one hop a way 
> within the
> same data center?

And how is that ntp source disciplined? How do you know that the time
delivered by that source has any accuracy whatsoever. And added to that, there
are the transmission problems. The hubs and routers between your machine and
that ntp source introduce jitter and delays. Contention for the ethernet
introduces jitter. The interrupt handling in your computer introduces jitter.
The abysmally slow network (even gigabit cable takes microseconds to send a
packet down the line, and then there is teh behaviour of the ethernet cards
which will amass data and only send it when enough has accumulated and it
feels like sending something. If you want accurate times you HAVE to have
something like gps/pps and to get tens of nanosecond precision, you need to 
have a
pretty sophisticated one.


> 
> So what would you suggest me to use to synchronize in a datacenter that PTP 
> isn't
> available and GPS clock isn't allowed?

Here is one of the worl'd foremost watches. Now I want to repair it, but you
must wear boxing gloved while doing so, and you are not allowed to remove them
for any reason.

> 
> And indeed I have thought about a better solution for quiet some time because 
> of the
> conditions above and temperature effect on TSC.  But I can't think of a way 
> to measure
> from A to B without jitter and latency, and at the same time, I would like to 
> know the
> approximate epoch time of each "timestamping".  (again no jitter/latency is 
> more

approximate? century? year? day, second, millisecond, microsecond nanosecond?


> important than accuracy of the epoch time.).

But make sure you never remove those gloves.


> 
> If you have a good suggestion, i am all ears.

And at a budget of $50? How much are you willing to spend?

> 
> Thanks!
> 
> 
> On Tuesday, May 15, 2018, 2:58:52 PM GMT+8, Bill Unruh  
> wrote:
> 
> 
> 
> 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
> (i.e
> > while loop) to get the value out as soon as the writer finishes.
> >
> > I don't have an exact percentage of occurrence nor the exact delay.  I 
> > vaguely
> remember
> > it was like 200 nano or more.
> 
> I must say I am confused. You are wanting accuracy in the 10s of ns range, 
> but you
> are using pool servers to set you clock, which will give you accuracy in the
> hundreds of usec range (on a good day). Or even a local server, which will
> give you something like 10s of usec accuracy. There is a disconnect here.
> If you really want ns accuracy you will have to use a refclock directly
> connected to the machine. Even GPS has problems as it is only after the fact
> that you can figure out the sawtooth time error on a really good gps timing
> receiver and compensate for it.
> Never mind the temperature changes which make the tsc wander away from its
> rate. It is really unclear to me what you are trying to do, and why?
> 
> 
> 
> 
> >
> > Tho, the comparison between the latency of rdtsc and the latency of 
> > clock_gettime()
> > (~20 nano vs ~50 nano) is widely available online.
> >
> > As I mentioned that jitter/latency is more important than accuracy in my 
> > case, so I
> > comprised accuracy a bit (with complexity).
> >
> >
> > On Tuesday, May 15, 2018, 1:16:23 PM GMT+8, Bill Unruh 
> >  wrote:
> >
> >
> >
> > On Tue, 15 May 2018, Hei Chan wrote:
> >
> > > Hi Bill,
> > >
> > > Here is the source:
> 

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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, 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 yell every time one of my clients installs NTP 
into
  a virtual machine and calls it good. You are almost guaranteed to have a
  false ticker. I could tell you stories...


Do you mean people are using VMs for chrony (ntp) servers or clients?


Probably both.






--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] makestep in Chrony

[Stephen Satchell]

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 yell every time one of my clients 
installs NTP into a virtual machine and calls it good.  You are almost 
guaranteed to have a false ticker.  I could tell you stories...


Do you mean people are using VMs for chrony (ntp) servers or clients?


Yes.

"Go sail away, go sail away, go sail away with ticks..."

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] makestep in Chrony

[Miroslav Lichvar]

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 still allows chrony to control the clock.

> 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 yell every time one of my clients installs NTP into a virtual
> machine and calls it good.  You are almost guaranteed to have a false
> ticker.  I could tell you stories...

That depends on the clocksource. With some the clock may be very
unstable depending on what the host and other guests do. However, with
the tsc clocksource the system clock of the VM can be as good as the
host's. FWIW, I have some servers running on oversold VPSes and they
have no problems with the clock. Virtualized networking seems to be a
bigger problem. Some drivers (e.g. e1000) support SW timestamping and
that can help a lot.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] makestep in Chrony

[Stephen Satchell]

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 believe the clock is
synchronized (right?).  Then, it is very rare to have other processes
to update the clock.
Synchronized, but not regulated.  Let me give you an example:  in my 
admin desktop system, chronyc reports that the frequency of the computer 
clock is 12.373 ppm slow.  So that means that the real-time clock will 
lose time after being synchronized but not regulated.  Chrony will turn 
those knobs to compensate for the difference.


There are knobs in most operating systems's time software to compensate 
for the inaccuracies, so that long-term accuracy of the real-time clock 
is improved.  Because the crystals will wander over temperature, one 
would need to periodically re-synchronize, and perhaps tweak the RTC 
clock regulation.  That's what chrony (and NTP) do.


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. 
Virtually all modern computers (including cell phones) have crystals 
that meet this specification.


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 yell every time one of my clients installs NTP 
into a virtual machine and calls it good.  You are almost guaranteed to 
have a false ticker.  I could tell you stories...


Are you trying to do astronomical observations?  If so, use the search 
engine of your choice to find research papers on this subject.


--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 
measurement is taken probably 1.5 billion times (or more a day) in multiple 
cores (~10?).  As you can see timestamping happens very frequent in my system.  
Hence, that's why I have a weird thought of using rdtsc-clock_gettime() map.
I have to admit that I don't know how to use the chrony/ntp's parameters very 
well.  What parameters would you recommend with a NTP source that is one hop a 
way within the same data center?
So what would you suggest me to use to synchronize in a datacenter that PTP 
isn't available and GPS clock isn't allowed?
And indeed I have thought about a better solution for quiet some time because 
of the conditions above and temperature effect on TSC.  But I can't think of a 
way to measure from A to B without jitter and latency, and at the same time, I 
would like to know the approximate epoch time of each "timestamping".  (again 
no jitter/latency is more important than accuracy of the epoch time.).
If you have a good suggestion, i am all ears.
Thanks!

On Tuesday, May 15, 2018, 2:58:52 PM GMT+8, Bill Unruh 
 wrote:  
 
 
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 (i.e
> while loop) to get the value out as soon as the writer finishes.
> 
> I don't have an exact percentage of occurrence nor the exact delay.  I 
> vaguely remember
> it was like 200 nano or more.

I must say I am confused. You are wanting accuracy in the 10s of ns range, but 
you
are using pool servers to set you clock, which will give you accuracy in the
hundreds of usec range (on a good day). Or even a local server, which will
give you something like 10s of usec accuracy. There is a disconnect here. 
If you really want ns accuracy you will have to use a refclock directly
connected to the machine. Even GPS has problems as it is only after the fact
that you can figure out the sawtooth time error on a really good gps timing
receiver and compensate for it. 
Never mind the temperature changes which make the tsc wander away from its
rate. It is really unclear to me what you are trying to do, and why?




> 
> Tho, the comparison between the latency of rdtsc and the latency of 
> clock_gettime()
> (~20 nano vs ~50 nano) is widely available online.
> 
> As I mentioned that jitter/latency is more important than accuracy in my 
> case, so I
> comprised accuracy a bit (with complexity).
> 
> 
> On Tuesday, May 15, 2018, 1:16:23 PM GMT+8, Bill Unruh  
> wrote:
> 
> 
> 
> 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 occassionally due to the while
> loop?
> 
> Again that failure sounds like a bug.
> 
> 
> >
> > On Tuesday, May 15, 2018, 11:26:12 AM GMT+8, Bill Unruh 
> >  wrote:
> >
> >
> > 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 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.
> > >
> > > Ok, so the assumption here is that once the system clock is
> > > "synchronized" by chronyd there will be a linear function between the
> > > tsc and system time? And the goal is to have a clock that can be read
> > > in constant time and it doesn't have to be very accurate, but still
> > > track the real time?
> > >
> > > Yes to both :)
> > >
> > > I'm not sure if that's possible. The tsc is the direct source for the
> > > CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
> > > adjustments, i.e. it's sensitive to temperature changes etc. The
> > > constants of the linear function would have to be periodically updated
> > > and then you would need to deal with locking, which would increase the
> > > maximum latency in the reading of the clock.
> > >
> > > Here is the design I am thinking.
> > >
> > > I don't have chronyd run in backgroud, and periodically (through 

Re: [chrony-users] makestep in Chrony

[Miroslav Lichvar]

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 
> reason, and so it needs to spin (i.e while loop) to get the value out as soon 
> as the writer finishes.

How do you avoid this issue in your solution? If you update the
estimated frequency offset between real time and tsc, you will need to
prevent the conversion from using partially updated values. If you
don't update the offset at all (estimated only once on start), the
tsc-based clock will drift away.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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 (i.e
while loop) to get the value out as soon as the writer finishes.

I don't have an exact percentage of occurrence nor the exact delay.  I vaguely 
remember
it was like 200 nano or more.


I must say I am confused. You are wanting accuracy in the 10s of ns range, but 
you
are using pool servers to set you clock, which will give you accuracy in the
hundreds of usec range (on a good day). Or even a local server, which will
give you something like 10s of usec accuracy. There is a disconnect here. 
If you really want ns accuracy you will have to use a refclock directly

connected to the machine. Even GPS has problems as it is only after the fact
that you can figure out the sawtooth time error on a really good gps timing
receiver and compensate for it. 
Never mind the temperature changes which make the tsc wander away from its

rate. It is really unclear to me what you are trying to do, and why?






Tho, the comparison between the latency of rdtsc and the latency of 
clock_gettime()
(~20 nano vs ~50 nano) is widely available online.

As I mentioned that jitter/latency is more important than accuracy in my case, 
so I
comprised accuracy a bit (with complexity).


On Tuesday, May 15, 2018, 1:16:23 PM GMT+8, Bill Unruh  
wrote:



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 occassionally due to the while
loop?

Again that failure sounds like a bug.


>
> On Tuesday, May 15, 2018, 11:26:12 AM GMT+8, Bill Unruh 
 wrote:
>
>
> 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 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.
> >
> > Ok, so the assumption here is that once the system clock is
> > "synchronized" by chronyd there will be a linear function between the
> > tsc and system time? And the goal is to have a clock that can be read
> > in constant time and it doesn't have to be very accurate, but still
> > track the real time?
> >
> > Yes to both :)
> >
> > I'm not sure if that's possible. The tsc is the direct source for the
> > CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
> > adjustments, i.e. it's sensitive to temperature changes etc. The
> > constants of the linear function would have to be periodically updated
> > and then you would need to deal with locking, which would increase the
> > maximum latency in the reading of the clock.
> >
> > Here is the design I am thinking.
> >
> > I don't have chronyd run in backgroud, and periodically (through cronjob) 
to issue
> the
>
> That is a terrible way of usign chrony. One of the key features of both chrony
> and ntpd is that it disciplines not only the offset but also the the rate of
> the clock. And the rate can only be determine over a (lengthy ) time period.
> Why would you run it like this?
>
> > command chronyd -q 'pool [some NTP server/switch which is 1 switch away] 
iburst',
> then
> > as soon as it returns (the clock is synchronized right?), then I do 
something like:
>
> No. See above.
>
> > s = cpuid + rdtsc
> > clock_getime(REALTIME_CLOCK, )
> > e = rdtscp + cpuid
>
> >
> > Then, log it.
> >
> > So after 24 hours, I have a map for rdtsc<->absolute epoch time in nano.
>
> You have a very sophisticated program whose whole purpose is to continuously
> set the translation between the tsc and the UTC. And you throw it all away and
> use it in the way that Unix time was disciplined 40 years ago.
>
>
> >
> > Then, I can use the map to estimate the TSC frequency every 2 t's with the
assumption
> > that t is correct and TSC will change between two t's.
>
>
> >
> > Then, for everything I track with rdtsc, I can estimate the absolute epoch 
time in
> > nano.
> >
> > You might question why I don't just have chronyd running in background and 
call
> > clock_gettime(CLOCK_REATIME, ) for all the stamping I do with rdtsc.  The 
main
> issue
> > is that clock_gettime(CLOCK_REALTIME) is great 99% of the time but 
sometimes, it
just
> > fails internally and loops and then take a long time to return.
>
> No idea what this is all about. I have never 

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 as soon as the writer 
finishes.
I don't have an exact percentage of occurrence nor the exact delay.  I vaguely 
remember it was like 200 nano or more.
Tho, the comparison between the latency of rdtsc and the latency of 
clock_gettime() (~20 nano vs ~50 nano) is widely available online.
As I mentioned that jitter/latency is more important than accuracy in my case, 
so I comprised accuracy a bit (with complexity).

On Tuesday, May 15, 2018, 1:16:23 PM GMT+8, Bill Unruh 
 wrote:  
 
 
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 occassionally due to the while
loop?

Again that failure sounds like a bug.


> 
> On Tuesday, May 15, 2018, 11:26:12 AM GMT+8, Bill Unruh 
>  wrote:
> 
> 
> 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 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.
> >
> > Ok, so the assumption here is that once the system clock is
> > "synchronized" by chronyd there will be a linear function between the
> > tsc and system time? And the goal is to have a clock that can be read
> > in constant time and it doesn't have to be very accurate, but still
> > track the real time?
> >
> > Yes to both :)
> >
> > I'm not sure if that's possible. The tsc is the direct source for the
> > CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
> > adjustments, i.e. it's sensitive to temperature changes etc. The
> > constants of the linear function would have to be periodically updated
> > and then you would need to deal with locking, which would increase the
> > maximum latency in the reading of the clock.
> >
> > Here is the design I am thinking.
> >
> > I don't have chronyd run in backgroud, and periodically (through cronjob) 
> > to issue
> the
> 
> That is a terrible way of usign chrony. One of the key features of both chrony
> and ntpd is that it disciplines not only the offset but also the the rate of
> the clock. And the rate can only be determine over a (lengthy ) time period.
> Why would you run it like this?
> 
> > command chronyd -q 'pool [some NTP server/switch which is 1 switch away] 
> > iburst',
> then
> > as soon as it returns (the clock is synchronized right?), then I do 
> > something like:
> 
> No. See above.
> 
> > s = cpuid + rdtsc
> > clock_getime(REALTIME_CLOCK, )
> > e = rdtscp + cpuid
> 
> >
> > Then, log it.
> >
> > So after 24 hours, I have a map for rdtsc<->absolute epoch time in nano.
> 
> You have a very sophisticated program whose whole purpose is to continuously
> set the translation between the tsc and the UTC. And you throw it all away and
> use it in the way that Unix time was disciplined 40 years ago.
> 
> 
> >
> > Then, I can use the map to estimate the TSC frequency every 2 t's with the 
> > assumption
> > that t is correct and TSC will change between two t's.
> 
> 
> >
> > Then, for everything I track with rdtsc, I can estimate the absolute epoch 
> > time in
> > nano.
> >
> > You might question why I don't just have chronyd running in background and 
> > call
> > clock_gettime(CLOCK_REATIME, ) for all the stamping I do with rdtsc.  The 
> > main
> issue
> > is that clock_gettime(CLOCK_REALTIME) is great 99% of the time but 
> > sometimes, it just
> > fails internally and loops and then take a long time to return.
> 
> No idea what this is all about. I have never seen this. If it truely does
> this, that is bug, and needs to be reported.
> 
> 
> >
> > Any issue you see?
> >
> > P.S.  calling chronyd and creating the map file will be done by one 
> > dedicated core at
> > C0 (i.e. off OS scheduler to improve accuracy)
> >
> > > Ideally, I have a C application that calls chrony's API (if there is one) 
> > > similar
> to
> > "chronyd -q" to block till it finishes or gets a callback.
> > > Any suggestion?
> >
> > There is no C API for chrony (yet). Instead, you could use adjtimex()
> > and check the frequency and maxerror fields. The maxerror value
> > increases slowly and drops only when chronyd updates the clock. When
> > it drops below a 

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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 occassionally due to the while
loop?

Again that failure sounds like a bug.




On Tuesday, May 15, 2018, 11:26:12 AM GMT+8, Bill Unruh  
wrote:


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 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.
>
> Ok, so the assumption here is that once the system clock is
> "synchronized" by chronyd there will be a linear function between the
> tsc and system time? And the goal is to have a clock that can be read
> in constant time and it doesn't have to be very accurate, but still
> track the real time?
>
> Yes to both :)
>
> I'm not sure if that's possible. The tsc is the direct source for the
> CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
> adjustments, i.e. it's sensitive to temperature changes etc. The
> constants of the linear function would have to be periodically updated
> and then you would need to deal with locking, which would increase the
> maximum latency in the reading of the clock.
>
> Here is the design I am thinking.
>
> I don't have chronyd run in backgroud, and periodically (through cronjob) to 
issue
the

That is a terrible way of usign chrony. One of the key features of both chrony
and ntpd is that it disciplines not only the offset but also the the rate of
the clock. And the rate can only be determine over a (lengthy ) time period.
Why would you run it like this?

> command chronyd -q 'pool [some NTP server/switch which is 1 switch away] 
iburst',
then
> as soon as it returns (the clock is synchronized right?), then I do something 
like:

No. See above.

> s = cpuid + rdtsc
> clock_getime(REALTIME_CLOCK, )
> e = rdtscp + cpuid

>
> Then, log it.
>
> So after 24 hours, I have a map for rdtsc<->absolute epoch time in nano.

You have a very sophisticated program whose whole purpose is to continuously
set the translation between the tsc and the UTC. And you throw it all away and
use it in the way that Unix time was disciplined 40 years ago.


>
> Then, I can use the map to estimate the TSC frequency every 2 t's with the 
assumption
> that t is correct and TSC will change between two t's.


>
> Then, for everything I track with rdtsc, I can estimate the absolute epoch 
time in
> nano.
>
> You might question why I don't just have chronyd running in background and 
call
> clock_gettime(CLOCK_REATIME, ) for all the stamping I do with rdtsc.  The 
main
issue
> is that clock_gettime(CLOCK_REALTIME) is great 99% of the time but sometimes, 
it just
> fails internally and loops and then take a long time to return.

No idea what this is all about. I have never seen this. If it truely does
this, that is bug, and needs to be reported.


>
> Any issue you see?
>
> P.S.  calling chronyd and creating the map file will be done by one dedicated 
core at
> C0 (i.e. off OS scheduler to improve accuracy)
>
> > Ideally, I have a C application that calls chrony's API (if there is one) 
similar
to
> "chronyd -q" to block till it finishes or gets a callback.
> > Any suggestion?
>
> There is no C API for chrony (yet). Instead, you could use adjtimex()
> and check the frequency and maxerror fields. The maxerror value
> increases slowly and drops only when chronyd updates the clock. When
> it drops below a threshold and the frequency didn't change
> significantly, the system clock could be considered to be
> synchronized.
>
> --
> Miroslav Lichvar
>
>
>

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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:  
 
 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 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.
> 
> Ok, so the assumption here is that once the system clock is
> "synchronized" by chronyd there will be a linear function between the
> tsc and system time? And the goal is to have a clock that can be read
> in constant time and it doesn't have to be very accurate, but still
> track the real time?
> 
> Yes to both :)
> 
> I'm not sure if that's possible. The tsc is the direct source for the
> CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
> adjustments, i.e. it's sensitive to temperature changes etc. The
> constants of the linear function would have to be periodically updated
> and then you would need to deal with locking, which would increase the
> maximum latency in the reading of the clock.
> 
> Here is the design I am thinking.
> 
> I don't have chronyd run in backgroud, and periodically (through cronjob) to 
> issue the

That is a terrible way of usign chrony. One of the key features of both chrony
and ntpd is that it disciplines not only the offset but also the the rate of
the clock. And the rate can only be determine over a (lengthy ) time period.
Why would you run it like this?

> command chronyd -q 'pool [some NTP server/switch which is 1 switch away] 
> iburst', then
> as soon as it returns (the clock is synchronized right?), then I do something 
> like:

No. See above.

> s = cpuid + rdtsc
> clock_getime(REALTIME_CLOCK, )
> e = rdtscp + cpuid

> 
> Then, log it.
> 
> So after 24 hours, I have a map for rdtsc<->absolute epoch time in nano.

You have a very sophisticated program whose whole purpose is to continuously
set the translation between the tsc and the UTC. And you throw it all away and
use it in the way that Unix time was disciplined 40 years ago.


> 
> Then, I can use the map to estimate the TSC frequency every 2 t's with the 
> assumption
> that t is correct and TSC will change between two t's.


> 
> Then, for everything I track with rdtsc, I can estimate the absolute epoch 
> time in
> nano.
> 
> You might question why I don't just have chronyd running in background and 
> call
> clock_gettime(CLOCK_REATIME, ) for all the stamping I do with rdtsc.  The 
> main issue
> is that clock_gettime(CLOCK_REALTIME) is great 99% of the time but sometimes, 
> it just
> fails internally and loops and then take a long time to return.

No idea what this is all about. I have never seen this. If it truely does
this, that is bug, and needs to be reported.


> 
> Any issue you see?
> 
> P.S.  calling chronyd and creating the map file will be done by one dedicated 
> core at
> C0 (i.e. off OS scheduler to improve accuracy)
> 
> > Ideally, I have a C application that calls chrony's API (if there is one) 
> > similar to
> "chronyd -q" to block till it finishes or gets a callback.
> > Any suggestion?
> 
> There is no C API for chrony (yet). Instead, you could use adjtimex()
> and check the frequency and maxerror fields. The maxerror value
> increases slowly and drops only when chronyd updates the clock. When
> it drops below a threshold and the frequency didn't change
> significantly, the system clock could be considered to be
> synchronized.
> 
> --
> Miroslav Lichvar
> 
> 
>  

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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 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.

Ok, so the assumption here is that once the system clock is
"synchronized" by chronyd there will be a linear function between the
tsc and system time? And the goal is to have a clock that can be read
in constant time and it doesn't have to be very accurate, but still
track the real time?

Yes to both :)

I'm not sure if that's possible. The tsc is the direct source for the
CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
adjustments, i.e. it's sensitive to temperature changes etc. The
constants of the linear function would have to be periodically updated
and then you would need to deal with locking, which would increase the
maximum latency in the reading of the clock.

Here is the design I am thinking.

I don't have chronyd run in backgroud, and periodically (through cronjob) to 
issue the


That is a terrible way of usign chrony. One of the key features of both chrony
and ntpd is that it disciplines not only the offset but also the the rate of
the clock. And the rate can only be determine over a (lengthy ) time period.
Why would you run it like this?


command chronyd -q 'pool [some NTP server/switch which is 1 switch away] 
iburst', then
as soon as it returns (the clock is synchronized right?), then I do something 
like:


No. See above.


s = cpuid + rdtsc
clock_getime(REALTIME_CLOCK, )
e = rdtscp + cpuid




Then, log it.

So after 24 hours, I have a map for rdtsc<->absolute epoch time in nano.


You have a very sophisticated program whose whole purpose is to continuously
set the translation between the tsc and the UTC. And you throw it all away and
use it in the way that Unix time was disciplined 40 years ago.




Then, I can use the map to estimate the TSC frequency every 2 t's with the 
assumption
that t is correct and TSC will change between two t's.





Then, for everything I track with rdtsc, I can estimate the absolute epoch time 
in
nano.

You might question why I don't just have chronyd running in background and call
clock_gettime(CLOCK_REATIME, ) for all the stamping I do with rdtsc.  The 
main issue
is that clock_gettime(CLOCK_REALTIME) is great 99% of the time but sometimes, 
it just
fails internally and loops and then take a long time to return.


No idea what this is all about. I have never seen this. If it truely does
this, that is bug, and needs to be reported.




Any issue you see?

P.S.  calling chronyd and creating the map file will be done by one dedicated 
core at
C0 (i.e. off OS scheduler to improve accuracy)

> Ideally, I have a C application that calls chrony's API (if there is one) 
similar to
"chronyd -q" to block till it finishes or gets a callback.
> Any suggestion?

There is no C API for chrony (yet). Instead, you could use adjtimex()
and check the frequency and maxerror fields. The maxerror value
increases slowly and drops only when chronyd updates the clock. When
it drops below a threshold and the frequency didn't change
significantly, the system clock could be considered to be
synchronized.

--
Miroslav Lichvar

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 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.

Ok, so the assumption here is that once the system clock is
"synchronized" by chronyd there will be a linear function between the
tsc and system time? And the goal is to have a clock that can be read
in constant time and it doesn't have to be very accurate, but still
track the real time?

Yes to both :)

I'm not sure if that's possible. The tsc is the direct source for the
CLOCK_MONOTONIC_RAW clock. Its frequency doesn't change with chronyd's
adjustments, i.e. it's sensitive to temperature changes etc. The
constants of the linear function would have to be periodically updated
and then you would need to deal with locking, which would increase the
maximum latency in the reading of the clock.
Here is the design I am thinking.
I don't have chronyd run in backgroud, and periodically (through cronjob) to 
issue the command chronyd -q 'pool [some NTP server/switch which is 1 switch 
away] iburst', then as soon as it returns (the clock is synchronized right?), 
then I do something like:
s = cpuid + rdtscclock_getime(REALTIME_CLOCK, )e = rdtscp + cpuid
Then, log it.
So after 24 hours, I have a map for rdtsc<->absolute epoch time in nano.
Then, I can use the map to estimate the TSC frequency every 2 t's with the 
assumption that t is correct and TSC will change between two t's.
Then, for everything I track with rdtsc, I can estimate the absolute epoch time 
in nano.
You might question why I don't just have chronyd running in background and call 
clock_gettime(CLOCK_REATIME, ) for all the stamping I do with rdtsc.  The 
main issue is that clock_gettime(CLOCK_REALTIME) is great 99% of the time but 
sometimes, it just fails internally and loops and then take a long time to 
return.
Any issue you see?
P.S.  calling chronyd and creating the map file will be done by one dedicated 
core at C0 (i.e. off OS scheduler to improve accuracy)

> Ideally, I have a C application that calls chrony's API (if there is one) 
> similar to "chronyd -q" to block till it finishes or gets a callback.
> Any suggestion?

There is no C API for chrony (yet). Instead, you could use adjtimex()
and check the frequency and maxerror fields. The maxerror value
increases slowly and drops only when chronyd updates the clock. When
it drops below a threshold and the frequency didn't change
significantly, the system clock could be considered to be
synchronized.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

  

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 /proc/cpuinfo). With these processors, the TSC ticks at the 
processor's nominal frequency, regardless of the actual CPU clock frequency due 
to turbo or power saving states. Hence TSC ticks are counting the passage of 
time, not the number of CPU clock cycles elapsed."

TSC isn't perfect that's why people need PTP, NTP or chrony as well even tho 
the underneath system clock uses TSC:$ cat 
/sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
And yes, I trust chrony clock and but I don't want to have jitter when I call 
clock_gettime(), that's why I hope to rely on chrony updating clock accurately 
and then use it with tsc to estimate the time...
Thanks!


On Friday, May 11, 2018, 12:49:37 PM GMT+8, Bill Unruh 
 wrote:  
 
 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 the the chrony time more than the txc
counter. 
(Yes, if you go in and manually change the time, the system time will be
flakey. Don't do it. If someone puts a bullet through your computer, the tsc
will be pretty unreliable too.)





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 Fri, 11 May 2018, Hei Chan wrote:

> Hi Bill,
> 
> Really appreciate your reply.
> 
> I removed the group to avoid spamming the group too much as my use case is a 
> bit
> unique/dumb.
> 
> Yes, invariant TSC only means that the frequency won't change due to power, 
> ACPI, etc. 
> But due to the physical property as you stated, temperature might affect TSC 
> frequency.
> 
> And this is exactly why I would like to do some estimate of time based on TSC 
> +
> clock_getttime().
> 
> Here is my use case:
> - I use rdtsc(p) (+CPUID) everywhere to stamp all the event happens in my 
> application
> and store somewhere (e.g. db, file, etc)
> - Then, I would like to convert them back to timestamp.
> 
> You would wonder why I don't call clock_gettime() directly because
> clock_gettime(CLOCK_REALTIME) has a while loop inside and occasionally it 
> will fail and
> then it will loop for quite some time before returning the time.
> 
> I am trying to avoid this kind of jitter in my application but at the same 
> time, I
> would like to have as accurate as possible timestamp without PTP (my data 
> center
> doesn't have PTP and disallow setting my own GPS clock).
> 
> So basically no jitter and low latency are more important to me than accuracy 
> of
> timestamp.  Hence, I sacrifice the accuracy by a bit, in return I get no 
> jitter and low
> latency.
> 
> Hope the picture is more complete now :)
> On Friday, May 11, 2018, 11:10:26 AM GMT+8, Bill Unruh  
> wrote:
> 
> 
> 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 you want to do
> this.
> 
> It is of course true that your system might use another clock (HPET,...) whose
> clicks it counts and interprets to get the system time.
> 
> You might want to look at the reports from adjtimex to see what the relation
> is between the hardware and the time.
> 
> Note that the tsc is not invariant. it depends on the computer's crystal which
> can speed up and slow down as temperature changes, or other things
> From wikipedia Time_Stamp_counter
> 
> " The Time Stamp Counter was once an excellent high-resolution, low-overhead
> way for a program to get CPU timing information. With the advent of
> multi-core/hyper-threaded CPUs, systems with multiple CPUs, and hibernating
> operating systems, the TSC cannot be relied upon to provide accurate results
> --unless great care is taken to correct the possible flaws: rate of tick
> and whether all cores (processors) have identical values in their time-keeping
> registers. There is no promise that the timestamp counters of multiple CPUs on
> a single motherboard will be synchronized. Therefore, a program can get
> reliable results only by limiting itself to run on one specific CPU. Even
> then, the CPU speed may change because of power-saving measures taken by the
> OS or BIOS, or the system may be hibernated and later resumed, 

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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 the the chrony time more than the txc
counter. 
(Yes, if you go in and manually change the time, the system time will be

flakey. Don't do it. If someone puts a bullet through your computer, the tsc
will be pretty unreliable too.)





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 Fri, 11 May 2018, Hei Chan wrote:


Hi Bill,

Really appreciate your reply.

I removed the group to avoid spamming the group too much as my use case is a bit
unique/dumb.

Yes, invariant TSC only means that the frequency won't change due to power, 
ACPI, etc. 
But due to the physical property as you stated, temperature might affect TSC 
frequency.

And this is exactly why I would like to do some estimate of time based on TSC +
clock_getttime().

Here is my use case:
- I use rdtsc(p) (+CPUID) everywhere to stamp all the event happens in my 
application
and store somewhere (e.g. db, file, etc)
- Then, I would like to convert them back to timestamp.

You would wonder why I don't call clock_gettime() directly because
clock_gettime(CLOCK_REALTIME) has a while loop inside and occasionally it will 
fail and
then it will loop for quite some time before returning the time.

I am trying to avoid this kind of jitter in my application but at the same 
time, I
would like to have as accurate as possible timestamp without PTP (my data center
doesn't have PTP and disallow setting my own GPS clock).

So basically no jitter and low latency are more important to me than accuracy of
timestamp.  Hence, I sacrifice the accuracy by a bit, in return I get no jitter 
and low
latency.

Hope the picture is more complete now :)
On Friday, May 11, 2018, 11:10:26 AM GMT+8, Bill Unruh  
wrote:


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 you want to do
this.

It is of course true that your system might use another clock (HPET,...) whose
clicks it counts and interprets to get the system time.

You might want to look at the reports from adjtimex to see what the relation
is between the hardware and the time.

Note that the tsc is not invariant. it depends on the computer's crystal which
can speed up and slow down as temperature changes, or other things
From wikipedia Time_Stamp_counter

" The Time Stamp Counter was once an excellent high-resolution, low-overhead
way for a program to get CPU timing information. With the advent of
multi-core/hyper-threaded CPUs, systems with multiple CPUs, and hibernating
operating systems, the TSC cannot be relied upon to provide accurate results
--unless great care is taken to correct the possible flaws: rate of tick
and whether all cores (processors) have identical values in their time-keeping
registers. There is no promise that the timestamp counters of multiple CPUs on
a single motherboard will be synchronized. Therefore, a program can get
reliable results only by limiting itself to run on one specific CPU. Even
then, the CPU speed may change because of power-saving measures taken by the
OS or BIOS, or the system may be hibernated and later resumed, resetting the
TSC. In those latter cases, to stay relevant, the program must re-calibrate
the counter periodically."

So, again it would seem to be better to just use the system time, disciplined
by chrony. But then I may be misinterpreting completely what you want to do.



On Fri, 11 May 2018, Hei Chan wrote:

> 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 to
> "chronyd -q" to block till it finishes or gets a callback.
>
> Any suggestion?
>
> On Thursday, May 10, 2018, 10:05:04 PM GMT+8, Bill Unruh 

wrote:
>
>
> 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 it be, and it will have your clock synced to the source as well as
> possible. So, I am not 

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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 you want to do
this.

It is of course true that your system might use another clock (HPET,...) whose
clicks it counts and interprets to get the system time.

You might want to look at the reports from adjtimex to see what the relation
is between the hardware and the time.

Note that the tsc is not invariant. it depends on the computer's crystal which
can speed up and slow down as temperature changes, or other things
From wikipedia Time_Stamp_counter

" The Time Stamp Counter was once an excellent high-resolution, low-overhead
way for a program to get CPU timing information. With the advent of
multi-core/hyper-threaded CPUs, systems with multiple CPUs, and hibernating
operating systems, the TSC cannot be relied upon to provide accurate results
--unless great care is taken to correct the possible flaws: rate of tick
and whether all cores (processors) have identical values in their time-keeping
registers. There is no promise that the timestamp counters of multiple CPUs on
a single motherboard will be synchronized. Therefore, a program can get
reliable results only by limiting itself to run on one specific CPU. Even
then, the CPU speed may change because of power-saving measures taken by the
OS or BIOS, or the system may be hibernated and later resumed, resetting the
TSC. In those latter cases, to stay relevant, the program must re-calibrate
the counter periodically."

So, again it would seem to be better to just use the system time, disciplined
by chrony. But then I may be misinterpreting completely what you want to do.



On Fri, 11 May 2018, Hei Chan wrote:


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 to
"chronyd -q" to block till it finishes or gets a callback.

Any suggestion?

On Thursday, May 10, 2018, 10:05:04 PM GMT+8, Bill Unruh  
wrote:


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 it be, and it will have your clock synced to the source as well as
possible. So, I am not sure what you have in mind. So, if you could tell us
what problem you are trying to fix, rather than asking what the best solution
to an unknown problem is, it would make answering much easier.


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 Thu, 10 May 2018, Hei Chan wrote:

> 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 -- 
chronyc
burst
> or chronyc waitsync?
>
> WHICH COMMAND IS BETTER TO FORCE CHRONY TO SYNCHRONIZE TIME RIGHT NOW --...
>
>
> Or even better -- is there a way that I can call through a C API and get a 
callback
or
> get blocked after it is done?
>
> Thanks!
>
> On Wednesday, May 9, 2018, 2:58:44 PM GMT+8, Bill Unruh 
 wrote:
>
>
>
>
> 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, Miroslav Lichvar wrote:
>
> > 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 of the 
Linux
> machines are using TSC as the source:$ cat
> /sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
> >> Given a machine using TSC as the clock source and new Intel CPUs have 
invariant
TSC,
> how can chrony slow down or speed up the clock?  I am sure I misunderstand 
the doc.
> >
> > The clocksources don't change their frequency. It's the software
> > system clock maintained by the kernel, whose 

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 to "chronyd -q" to block till it finishes or gets a callback.
Any suggestion?
On Thursday, May 10, 2018, 10:05:04 PM GMT+8, Bill Unruh 
 wrote:  
 
 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 it be, and it will have your clock synced to the source as well as
possible. So, I am not sure what you have in mind. So, if you could tell us
what problem you are trying to fix, rather than asking what the best solution
to an unknown problem is, it would make answering much easier.


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 Thu, 10 May 2018, Hei Chan wrote:

> 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 -- 
> chronyc burst
> or chronyc waitsync?
> 
> WHICH COMMAND IS BETTER TO FORCE CHRONY TO SYNCHRONIZE TIME RIGHT NOW --...
> 
> 
> Or even better -- is there a way that I can call through a C API and get a 
> callback or
> get blocked after it is done?
> 
> Thanks!
> 
> On Wednesday, May 9, 2018, 2:58:44 PM GMT+8, Bill Unruh 
>  wrote:
> 
> 
> 
> 
> 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, Miroslav Lichvar wrote:
> 
> > 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 of the 
> Linux
> machines are using TSC as the source:$ cat
> /sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
> >> Given a machine using TSC as the clock source and new Intel CPUs have 
> >> invariant TSC,
> how can chrony slow down or speed up the clock?  I am sure I misunderstand 
> the doc.
> >
> > The clocksources don't change their frequency. It's the software
> > system clock maintained by the kernel, whose frequency is adjusted by
> > the adjtimex(2) system call.
> 
> To expand, there is counter that counts the pulses in TSC, but those pulses
> need to be converted into seconds. That conversion factor can get changed by
> the adjtimex.
> 
>  

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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 it be, and it will have your clock synced to the source as well as

possible. So, I am not sure what you have in mind. So, if you could tell us
what problem you are trying to fix, rather than asking what the best solution
to an unknown problem is, it would make answering much easier.


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 Thu, 10 May 2018, Hei Chan wrote:


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 -- 
chronyc burst
or chronyc waitsync?

WHICH COMMAND IS BETTER TO FORCE CHRONY TO SYNCHRONIZE TIME RIGHT NOW --...


Or even better -- is there a way that I can call through a C API and get a 
callback or
get blocked after it is done?

Thanks!

On Wednesday, May 9, 2018, 2:58:44 PM GMT+8, Bill Unruh  
wrote:




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, Miroslav Lichvar wrote:

> 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 of the 
Linux
machines are using TSC as the source:$ cat
/sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
>> Given a machine using TSC as the clock source and new Intel CPUs have 
invariant TSC,
how can chrony slow down or speed up the clock?  I am sure I misunderstand the 
doc.
>
> The clocksources don't change their frequency. It's the software
> system clock maintained by the kernel, whose frequency is adjusted by
> the adjtimex(2) system call.

To expand, there is counter that counts the pulses in TSC, but those pulses
need to be converted into seconds. That conversion factor can get changed by
the adjtimex.

Re: [chrony-users] makestep in Chrony

[Ariel Garcia]

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
chrony_is_synced -v
to get the result on stdout.

The first parameter to waitsync (1) tells chronyc to only check once, i.e. , 
the call will be (roughly) non-blocking.
You can change that into "0" or a big number to get a blocking command, it 
will wait (long/forever) to sync. Attached also my "chrony_wait_sync" shell 
command).
On purpose i use big max-correction and max-skew values (1 500), to allow for 
a fast(er) rough initial synchronization.


BTW, chronyc burst  will _NOT_ give you any synchronization warranty, it will 
only force so many measurements from (each) server.

Hope it helps, Ariel



On Thursday, 10 May 2018 12:16:29 CEST Hei Chan wrote:
>  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 -- chronyc burst or chronyc
> waitsync?
> 
> Which command is better to force chrony to synchronize time right now --...
> 
> Or even better -- is there a way that I can call through a C API and get a
> callback or get blocked after it is done? Thanks!


chrony_wait_sync
Description: application/shellscript


chrony_is_synced
Description: application/shellscript

Re: [chrony-users] makestep in Chrony

[Hei Chan]

 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 -- 
chronyc burst or chronyc waitsync?


| 
| 
|  | 
Which command is better to force chrony to synchronize time right now --...


 |

 |

 |


Or even better -- is there a way that I can call through a C API and get a 
callback or get blocked after it is done?
Thanks!
On Wednesday, May 9, 2018, 2:58:44 PM GMT+8, Bill Unruh 
 wrote:  
 
 

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, Miroslav Lichvar wrote:

> 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 of the Linux machines are using TSC as the source:$ cat 
>> /sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
>> Given a machine using TSC as the clock source and new Intel CPUs have 
>> invariant TSC, how can chrony slow down or speed up the clock?  I am sure I 
>> misunderstand the doc.
>
> The clocksources don't change their frequency. It's the software
> system clock maintained by the kernel, whose frequency is adjusted by
> the adjtimex(2) system call.

To expand, there is counter that counts the pulses in TSC, but those pulses
need to be converted into seconds. That conversion factor can get changed by
the adjtimex.  

Re: [chrony-users] makestep in Chrony

[Bill Unruh]

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, Miroslav Lichvar wrote:


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 of the Linux 
machines are using TSC as the source:$ cat 
/sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
Given a machine using TSC as the clock source and new Intel CPUs have invariant 
TSC, how can chrony slow down or speed up the clock?  I am sure I misunderstand 
the doc.


The clocksources don't change their frequency. It's the software
system clock maintained by the kernel, whose frequency is adjusted by
the adjtimex(2) system call.


To expand, there is counter that counts the pulses in TSC, but those pulses
need to be converted into seconds. That conversion factor can get changed by
the adjtimex.

Re: [chrony-users] makestep in Chrony

[Miroslav Lichvar]

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 of 
> the Linux machines are using TSC as the source:$ cat 
> /sys/devices/system/clocksource/clocksource0/current_clocksourcetsc
> Given a machine using TSC as the clock source and new Intel CPUs have 
> invariant TSC, how can chrony slow down or speed up the clock?  I am sure I 
> misunderstand the doc.

The clocksources don't change their frequency. It's the software
system clock maintained by the kernel, whose frequency is adjusted by
the adjtimex(2) system call.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.