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 use that setup as a level 1 clock for my engineering network. John On Wed, May 16, 2018 at 2:24 AM, Bill Unruhwrote: > 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Satchellwrote: 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
On 05/15/2018 05:56 AM, Alexander Bisogiannis wrote: On Tue, 15 May, 2018 at 1:53 PM, Stephen Satchellwrote: 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
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
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
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 Unruhwrote: 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
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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Lichvarwrote: 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
Thanks for your reply. See my comment inline. On Friday, May 11, 2018, 4:26:14 PM GMT+8, Miroslav Lichvarwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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 Unruhwrote: 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
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
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 Unruhwrote: 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
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
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.