[LEAPSECS] Clarification and VM Synchronization
First, to clarify what I meant by UTC being inaccurate. IMO, UTC is inaccurate as a measure of Earth rotation. It is precise in atomic seconds, but it is inaccurate for astronomical purposes. Accuracy is restored to a significant degree by DUT. It is precise to the degree that contributing clocks can be synchronized (nanosecond level, or as previous discussions conjecture, picosecond level). I am as usual insecure about this, and I would appreciate either confirmation or a more suitable alternative. Second, I am now fascinated by the implications of lack of synch among virtual machines or real networks of distributed computers. I watched the YouTube video recommend in the previous thread. I do not understand this any way near to the others on this group, but I need to convince non-technical authorities that this matters. Any suggestions other than a two by four with lots of momentum -- and maybe a protruding nail? It is ironic that the shift in astrological signs made headlines this morning while the significance of Earth rotation and orientation parameters escapes notice. Dave Finkleman Senior Scientist Center for Space Standards and Innovation Analytical Graphics, Inc. 7150 Campus Drive Colorado Springs, CO 80920 Phone: 719-510-8282 or 719-321-4780 Fax: 719-573-9079 Discover CSSI data downloads, technical webinars, publications, and outreach events at www.CenterForSpace.com. ** ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
On 01/13/2011 22:19, Tom Van Baak wrote: It would appear that making adjustments every 10 days is not often enough, at least in the US, viz: http://www.nist.gov/pml/div688/grp50/NISTUTC.cfm http://www.nist.gov/pml/div688/grp50/nistusno.cfm Even if we abandon the leap second, we have issues at the nanosecond level. This is what happens any time you have more than one clock and if you have bounds on frequency steering. You'll find that all of the UTC(k) clocks disagree at the nanosecond level and that they all wander around the mean paper clock, UTC. This also is normal and expected. For large ensembles of clocks, you are pretty much guaranteed to have this level of fussiness too, since you can never set the clock to the frequency that you want. You can only ask it to set it to the frequency you want. Clocks usually comply, mostly. There's always some tiny error that gets through the process. It doesn't matter if that's a Hydrogen Maser, a Cesium HP5071A or your wrist watch. You don't notice the error either until it has had a chance to accumulate. The errors in frequency are on the order of 1 in 1e14 or so. Even these tiny errors accumulate to nanoseconds over days... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Pragmatic solution (sometimes)
I was talking to the IT manager for a town in Connecticut, USA. I asked if town residents could pay taxes and fees online. He said they could. I asked how they knew if a deadline had been met and whether late penalties should be added. He said that the town officials were lenient, and if the payment were close to the deadline, the late penalties would not be imposed. This avoids the need for split-second accuracy. He couldn't say what degree of accuracy could be achieved if called for, since an external company processes the credit card transactions. Of course, if it happens that the last person to receive leniency is a good friend of the mayor, and the first person to have the late penalty imposed is an opponent of the mayor... Gerry Ashton ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
On 01/14/2011 00:22, Sanjeev Gupta wrote: On Fri, Jan 14, 2011 at 13:47, Tom Van Baak t...@leapsecond.com mailto:t...@leapsecond.com wrote: You really didn't expect 250 diffeent atomic clocks around the world to all agree at the ns level at all times did you? tounge-in-cheek Why not? nano is 10E-9, and I see references to people trying for clocks with 10E-12 on this list. And what good is the atom part of an atomic clock, if it can't even handle nano? /foot-in-mouth Still waiting for the flying cars I was promised ... A good Cesium standard is good to better than 1ns/day. This is already 1e-12 or 1e-13 depending on the model. Hydrogen Masers are also available commercially, and they push this down to 1e-15 or 1e-16, which is good to about 1ns/year in frequency error. Experimental clocks can do even better, at least in the short term. The problem is that Cesium standards are between $5k and $25k to buy. Hydrogen Masers are more like $1M. It is a lot easier to have a bunch of Cesium standards than HMs. The BIPM collects time and frequency data for the different clocks, measured against each other. Each clock then has an error in frequency and time computed. These clocks are then weighted based on assigned values (based on the time scientists best guest about how good the clocks are). This value goes in to producing what's called a 'paper clock' which is a historical look at what the best guess at the actual time for each of these measurements. Based on that, you can know how close your clocks are running, and can steer them, if you wish. When you are running a clock, one thing that might not be obvious is that you can't have 'phase jumps' and keep the users of the clock happy. If you have a phase error of .1ns and want to steer it out, you have to adjust your frequency by 1e-10 / steer-time. The steer time is how long you want the steer to take, and is usually dictated by how much change in frequency the steering systems can do and how much the users of the time signals can tolerate. Warner P.S. I'm not sure if I agree that this will one day be common place. Having helped in a small way to run an ensemble of clocks at a former job, I know there's a lot of fussiness that goes into it. You need to calibrate the cable lengths, you need to adjust for temperature, you need to review the data frequently to make sure that everything is operating normally, etc. You also need to calibrate it to NIST from time to time. It can be quite the undertaking. I'm not sure that the ns level of accuracy and precision will ever make it into many devices. On the other hand, there's a lot of activity on the chip-scale atomic clocks pushing the cost way down, so who knows. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
On 01/14/2011 03:29, Tony Finch wrote: On Thu, 13 Jan 2011, Steve Allen wrote: Alas, 'tis neither normal nor expected by the APIs and the programmers who are implementing systems that deal with time. One of the core abstractions provided by operating systems is some coherent model of time. And the time labs provide a similar simplified model of time to the general public. Computers are *full* of clocks, including clocks with nanosecond resolution. Unfortunately the nanosecond clocks (the CPU cycle counters) run at different rates according to the CPU's power saving state. So the OS has to provide an abstraction layer on top of them in order to save the sanity of the programmer, and to allow the OS to do things like migrate threads from one CPU to another without affecting their idea of time. Older Intel parts had this problem. Same with some older MIPS designs. Newer designs don't have this issue with the time counters. Of course, there are other reasons for the OS to provide a time abstraction that's apart from this... phk has a good paper on this very topic, since he wrote the basic time counter stuff in FreeBSD :) For more along these lines, see http://www.youtube.com/watch?v=Dj7Y7Rd1Ou0 Tony. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
I can't help with the flying cars, but UTC does deliver a frequency that is the most precisely and accurately measured quantity known to humans. Time is the integral of that frequency, and over one leapsecond-less day a frequency error of 1.E-12 corresponds to a time error of 86400*1.E-12 = 86 nanoseconds. The USNO and BIPM web pages give our algorithms, though it takes a bit of clicking. The basic idea is that each clock's systematic errors in time, frequency and/or frequency drift are corrected for and the result goes into a weighted average. -Original Message- From: leapsecs-boun...@leapsecond.com [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Sanjeev Gupta Sent: Friday, January 14, 2011 2:23 AM To: Leap Second Discussion List Subject: Re: [LEAPSECS] Looking-glass, through On Fri, Jan 14, 2011 at 13:47, Tom Van Baak t...@leapsecond.com wrote: You really didn't expect 250 diffeent atomic clocks around the world to all agree at the ns level at all times did you? tounge-in-cheek Why not? nano is 10E-9, and I see references to people trying for clocks with 10E-12 on this list. And what good is the atom part of an atomic clock, if it can't even handle nano? /foot-in-mouth Still waiting for the flying cars I was promised ... -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
On 2011-01-14 16:26, Warner Losh wrote: The BIPM collects time and frequency data for the different clocks, measured against each other. Each clock then has an error in frequency and time computed. These clocks are then weighted based on assigned values (based on the time scientists best guest about how good the clocks are). This value goes in to producing what's called a 'paper clock' which is a historical look at what the best guess at the actual time for each of these measurements. Based on that, you can know how close your clocks are running, and can steer them, if you wish. The actual process as used by the BIPM (since 1977) is a bit more complex. The weighted mean of atomic clock readings results in an intermediate time scale called EAL (échelle atomique libre); in a second step, TAI is determined as an affine function of EAL so as to approximate the frequencies of the best atomic clocks. See for examle Dennis D McCarthy, P Kenneth Seidelmann: Time -- From Earth Rotation to Atomic Physics. Wiley-VCH. 2009. pages 201..216. The process was even more complex while the rate of TAI was intentionally increased during 1995..1998. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
Continuously adjusting clocks, even atomic clocks, to keep them within a certain tight tolerance is, in general, not a good pratice. Clocks will keep better time if left running. Rather, the offset of the clock from the standard is measured and used as appropriate. Performance levels of atomic clocks often assume that a linear rate term has been removed. -- Richard Langley On 14-Jan-11, at 12:26 PM, Warner Losh wrote: On 01/14/2011 00:22, Sanjeev Gupta wrote: On Fri, Jan 14, 2011 at 13:47, Tom Van Baak t...@leapsecond.com wrote: You really didn't expect 250 diffeent atomic clocks around the world to all agree at the ns level at all times did you? tounge-in-cheek Why not? nano is 10E-9, and I see references to people trying for clocks with 10E-12 on this list. And what good is the atom part of an atomic clock, if it can't even handle nano? /foot-in-mouth Still waiting for the flying cars I was promised ... A good Cesium standard is good to better than 1ns/day. This is already 1e-12 or 1e-13 depending on the model. Hydrogen Masers are also available commercially, and they push this down to 1e-15 or 1e-16, which is good to about 1ns/year in frequency error. Experimental clocks can do even better, at least in the short term. The problem is that Cesium standards are between $5k and $25k to buy. Hydrogen Masers are more like $1M. It is a lot easier to have a bunch of Cesium standards than HMs. The BIPM collects time and frequency data for the different clocks, measured against each other. Each clock then has an error in frequency and time computed. These clocks are then weighted based on assigned values (based on the time scientists best guest about how good the clocks are). This value goes in to producing what's called a 'paper clock' which is a historical look at what the best guess at the actual time for each of these measurements. Based on that, you can know how close your clocks are running, and can steer them, if you wish. When you are running a clock, one thing that might not be obvious is that you can't have 'phase jumps' and keep the users of the clock happy. If you have a phase error of .1ns and want to steer it out, you have to adjust your frequency by 1e-10 / steer-time. The steer time is how long you want the steer to take, and is usually dictated by how much change in frequency the steering systems can do and how much the users of the time signals can tolerate. Warner P.S. I'm not sure if I agree that this will one day be common place. Having helped in a small way to run an ensemble of clocks at a former job, I know there's a lot of fussiness that goes into it. You need to calibrate the cable lengths, you need to adjust for temperature, you need to review the data frequently to make sure that everything is operating normally, etc. You also need to calibrate it to NIST from time to time. It can be quite the undertaking. I'm not sure that the ns level of accuracy and precision will ever make it into many devices. On the other hand, there's a lot of activity on the chip-scale atomic clocks pushing the cost way down, so who knows. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
On 01/14/2011 09:40, Richard Langley wrote: Continuously adjusting clocks, even atomic clocks, to keep them within a certain tight tolerance is, in general, not a good pratice. Clocks will keep better time if left running. Rather, the offset of the clock from the standard is measured and used as appropriate. Performance levels of atomic clocks often assume that a linear rate term has been removed. Yes. That's why most people I've seen that keep their ensemble in sync do it by steering a DDS or similar device to the paper clock that's computed from the inputs of mulitple atomic clocks. Some Warner -- Richard Langley On 14-Jan-11, at 12:26 PM, Warner Losh wrote: On 01/14/2011 00:22, Sanjeev Gupta wrote: On Fri, Jan 14, 2011 at 13:47, Tom Van Baak t...@leapsecond.com wrote: You really didn't expect 250 diffeent atomic clocks around the world to all agree at the ns level at all times did you? tounge-in-cheek Why not? nano is 10E-9, and I see references to people trying for clocks with 10E-12 on this list. And what good is the atom part of an atomic clock, if it can't even handle nano? /foot-in-mouth Still waiting for the flying cars I was promised ... A good Cesium standard is good to better than 1ns/day. This is already 1e-12 or 1e-13 depending on the model. Hydrogen Masers are also available commercially, and they push this down to 1e-15 or 1e-16, which is good to about 1ns/year in frequency error. Experimental clocks can do even better, at least in the short term. The problem is that Cesium standards are between $5k and $25k to buy. Hydrogen Masers are more like $1M. It is a lot easier to have a bunch of Cesium standards than HMs. The BIPM collects time and frequency data for the different clocks, measured against each other. Each clock then has an error in frequency and time computed. These clocks are then weighted based on assigned values (based on the time scientists best guest about how good the clocks are). This value goes in to producing what's called a 'paper clock' which is a historical look at what the best guess at the actual time for each of these measurements. Based on that, you can know how close your clocks are running, and can steer them, if you wish. When you are running a clock, one thing that might not be obvious is that you can't have 'phase jumps' and keep the users of the clock happy. If you have a phase error of .1ns and want to steer it out, you have to adjust your frequency by 1e-10 / steer-time. The steer time is how long you want the steer to take, and is usually dictated by how much change in frequency the steering systems can do and how much the users of the time signals can tolerate. Warner P.S. I'm not sure if I agree that this will one day be common place. Having helped in a small way to run an ensemble of clocks at a former job, I know there's a lot of fussiness that goes into it. You need to calibrate the cable lengths, you need to adjust for temperature, you need to review the data frequently to make sure that everything is operating normally, etc. You also need to calibrate it to NIST from time to time. It can be quite the undertaking. I'm not sure that the ns level of accuracy and precision will ever make it into many devices. On the other hand, there's a lot of activity on the chip-scale atomic clocks pushing the cost way down, so who knows. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Do good fences make good neighbors?
Back home in Tucson from the American Astronomical Society meeting. Glad to see a rousing discussion, but I can't say that my heart is in unraveling the several threads. Instead, permit me to pose a question. Demetrios Matsakis, the founder of this list, wrote: I can't help with the flying cars, but UTC does deliver a frequency that is the most precisely and accurately measured quantity known to humans. Time is the integral of that frequency, What is described is a certain flavor of time. Does this flavor capture the essence of civil timekeeping? Generally phrases like most precisely and accurately measured are applied to highly scientific quantities of interest to small technical communities. The current UTC *also* delivers access to the dominant cadence of our lives, the synodic day. Both flavors of time are very widely used indeed. Which more closely tracks the requirements of civil timekeeping? My answer has always been that both are necessary. Leap seconds are one possible way to reconcile these very different flavors of time. We have discussed other ways, and we have discussed ways to make leap seconds more palatable if we choose not to undertake the daunting task of reinventing time. We need not continue to butt heads. Peace. Rob -- Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Clarification and VM Synchronization
In message 3b33e89c51d2de44be2f0c757c656c8809f66...@mail02.stk.com, Finklema n, Dave writes: It is ironic that the shift in astrological signs made headlines this morning while the significance of Earth rotation and orientation parameters escapes notice. Nobody ever went broke because underestimating the intelligence of the american public. -- H.L.Mencken -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Do good fences make good neighbors?
In message f1c36c4f-a32a-4ebb-bfde-c51c8a156...@noao.edu, Rob Seaman writes: My answer has always been that both are necessary. Leap seconds are one possible way to reconcile these very different flavors of time. They are not different flavors of time, one is a measurement of time, the other a measurement of speed of rotation. Both are needed, for sure, but that does not make the both measurements of time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Do good fences make good neighbors?
On Jan 14, 2011, at 2:40 PM, Poul-Henning Kamp wrote: In message f1c36c4f-a32a-4ebb-bfde-c51c8a156...@noao.edu, Rob Seaman writes: My answer has always been that both are necessary. Leap seconds are one possible way to reconcile these very different flavors of time. They are not different flavors of time, one is a measurement of time, the other a measurement of speed of rotation. Both are needed, for sure, but that does not make the both measurements of time. If you wish. In that case, note that sexagesimal notation is used for angles, while systems like Unix often express measurements of time intervals as unending counts of seconds (SI or otherwise) since some epoch. That epoch, eg midnight 1 Jan 1970, was itself selected as representing an angle related to the Earth. Both are needed. Any proposal to redefine UTC such that it no longer conveys both should thus address the mitigation that results from imposing such a change. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Do good fences make good neighbors?
In message p06240800c9568ccc4ca3@[192.168.1.100], Joe Gwinn writes: At 3:03 PM -0700 1/14/11, Rob Seaman wrote: UNIX chose 00:00:00 GMT 1 January 1970 as their epoch simply to be synchronized with civil time, at least initially. The initial versions of the operating system, which later became UNIX, kept time relative to randomly chosen epochs, which were updated whenever the counter were in danger of rolling over. Usually, but not always, the epoch was chosen to be the the beginning of the current month. The reason why the 1970-01-01 00:00:00GMT epoch stuck was they made the counter 32 bits to fix the problem once and for all (Source: Dennis Ritchie, at breakfast at USENIX ATC 1998 New Orleans) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] TAI adjustment ??
The process was even more complex while the rate of TAI was intentionally increased during 1995..1998. Could somebody say more? Or tell me what to google for? -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] TAI adjustment ??
On 01/14/2011 20:21, Hal Murray wrote: The process was even more complex while the rate of TAI was intentionally increased during 1995..1998. Could somebody say more? Or tell me what to google for? http://www.ucolick.org/~sla/leapsecs/dutc.html#TAI gives the answers. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
