Re: [ntp:questions] NTP.conf using Dave Hart code.
Dave Hart daveh...@gmail.com wrote in message news:ee10a4f9-ec56-4be1-a068-70170ffbd...@s25g2000prd.googlegroups.com... On Feb 9, 21:08 UTC, David J Taylor wrote: Yes, quite a lot of differences. I put together a rather mixed bag of notes here: http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html Thanks for remembering to post that link, I should have mentioned it. I know of one other writeup of using PPS with ntpd on Windows. It refers to an increasingly dated 4.2.4-based branch of mine with no mention of the newer binaries I've posted, but beggars can't be choosers: http://blogs.cae.tntech.edu/jwlangston21/2009/12/07/installing-and-using-ntp-with-a-garmin-18-gps-with-pps/ Cheers, Dave Hart Dave, I've added a link to Jeremy's page from mine as he has a nice clean step-by-step guide. Thanks for providing it, Jeremy. When referring to your page: http://www.davehart.net/ntp/win/x86/ it would be nice of the versions were presented in date order. The present order looks to be alphabetic, making p19 listed before p2. I recall there being an option in Windows to list in natural numeric order, but whether UNIX/Linux offers a similar option I don't know. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP.conf using Dave Hart code.
Dave Hart daveh...@gmail.com wrote in message news:683c4b55-7c15-4195-ac5e-223131cf6...@t34g2000prm.googlegroups.com... [] No, I make it more confusing. :) Given your requirement that the GPS will send both RMC and GGA every second, the simple answer is the PPS is unavailable without PPSAPI/serialpps.sys, because of the once-per- second limitation of the way PPS timestamps replace end-of-input-line timestamps on Windows. [] Cheers, Dave Hart Would another alternative, to avoid the end-of-line overrun, be to increase the baud rate? Or is it because sending two NMEA sentences within the 1-second interval confuses the driver? Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP.conf using Dave Hart code.
E-Mail Sent to this address will be added to the BlackLists n...@blacklist.griffin-technologies.invalid wrote in message news:hku1dk$be...@news.eternal-september.org... David J Taylor wrote: When referring to your page: http://www.davehart.net/ntp/win/x86/ it would be nice of the versions were presented in date order. I don't think M$ IIS supports FancyIndexing; IIs 5 certainly didn't. Windows Explorer does, that's where I first saw it. I don't know about IIS 6. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] fudge time1 for gps-18x-LVC?
Dave Hart daveh...@gmail.com wrote in message news:9c212bbc-94a4-435d-8fdf-590f10ff4...@z10g2000prh.googlegroups.com... [] http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html Fudge Factors flag1 0 | 1 Disable PPS signal processing if 0 (default); enable PPS signal processing if 1. You are correct it's a relatively new flag. I think it was documented last spring but not working correctly until the middle of October: (4.2.5p232-RC) 2009/10/14 Released by Harlan Stenn st...@ntp.org * [Bug 1341] NMEA driver requires working PPSAPI #ifdef HAVE_PPSAPI. http://bugs.ntp.org/1341 Cheers, Dave Hart Dave, Many thanks for that pointer. As my ntp GPS/PPS ref-clocks have been working well since I moved them to Windows, following your sterling work, I've not really needed to look at those pages. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
cc wrote: I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remotest t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? I'd say it is but you don't know for certain where any path difference is having an effect, obvious guess is the ones with largest delay. Is it possible (or allowed even) to run ntpq -p Japan and ntpq -p NorthAmerica to check what their billboards are. David Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remotest t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? Chris Chris, Most likely asymmetrical paths, yes. To answer your implied question, it is most /unlikely/ that the USA National Time is 17 milliseconds away from Japan National Time, if that's what you were thinking. National time differences are likely to be microseconds or less, I believe. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
On 9 Feb, 10:19, David Lord sn...@lordynet.org wrote: cc wrote: I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remote st t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? I'd say it is but you don't know for certain where any path difference is having an effect, obvious guess is the ones with largest delay. Is it possible (or allowed even) to run ntpq -p Japan and ntpq -p NorthAmerica to check what their billboards are. David Chris Sure is, NorthAmerica remote refid st t when poll reach delay offset jitter == +x.x.x.x .GPS. 1 u 357 1024 377 59.276 -0.524 0.017 *x.x.x.x .GPS. 1 u 414 1024 377 28.865 -0.839 0.032 +peer2 u 797 1024 377 22.819 -0.566 0.067 -peer2 u 952 1024 376 23.532 -0.525 0.226 Japan remote refid st t when poll reach delay offset jitter == *.GPS. 0 l 57 64 3770.000 -0.008 0.008 +peer.GPS. 1 u 23 64 3771.2980.007 0.009 +peer.GPS. 1 u1 64 3770.2910.006 0.013 Chris. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
On 9 Feb, 10:46, David J Taylor david-tay...@blueyonder.delete-this- bit.and-this-part.co.uk.invalid wrote: I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remote st t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? Chris Chris, Most likely asymmetrical paths, yes. To answer your implied question, it is most /unlikely/ that the USA National Time is 17 milliseconds away from Japan National Time, if that's what you were thinking. National time differences are likely to be microseconds or less, I believe. Cheers, David I wouldn't have thought so either and given that they all trace back to GPS it isn't likely either but it made me consider the natioanal security / financial implications of setting your national clock 10ms ahead of where everyone else thinks it is. Chris. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
cc cjcrick...@googlemail.com wrote in message news:fc3f6bee-dc69-44ec-8525-0cdac516f...@g28g2000yqh.googlegroups.com... [] I wouldn't have thought so either and given that they all trace back to GPS it isn't likely either but it made me consider the natioanal security / financial implications of setting your national clock 10ms ahead of where everyone else thinks it is. Chris. I suspect they all trace back to their own atomic clocks, which gives a good frequency reference, and then they adjust the phase to all be in sync. These days I would guess that GPS is used for the phase (time) sync. There are others on this list who know far more about this than I do, though. So if your loan is 10ms overdue, how much extra interest might you get? G Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
On 9 Feb, 11:52, David J Taylor david-tay...@blueyonder.delete-this- bit.and-this-part.co.uk.invalid wrote: cc cjcrick...@googlemail.com wrote in message news:fc3f6bee-dc69-44ec-8525-0cdac516f...@g28g2000yqh.googlegroups.com... [] I wouldn't have thought so either and given that they all trace back to GPS it isn't likely either but it made me consider the natioanal security / financial implications of setting your national clock 10ms ahead of where everyone else thinks it is. Chris. I suspect they all trace back to their own atomic clocks, which gives a good frequency reference, and then they adjust the phase to all be in sync. These days I would guess that GPS is used for the phase (time) sync. There are others on this list who know far more about this than I do, though. So if your loan is 10ms overdue, how much extra interest might you get? G Cheers, David I was thinking more along the lines of a stock market open times / trade times. Chris. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
David J Taylor wrote: Most likely asymmetrical paths, yes. To answer your implied question, it is most /unlikely/ that the USA National Time is 17 milliseconds away from Japan National Time, if that's what you were thinking. National time differences are likely to be microseconds or less, I believe. Single-digit ns is more like it: GPS had ~10ns as their internal target vs US standard time, and the US would be within 10 ns from the global UTC paper clock, many years ago. Today we're almost certainly significantly closer than this. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
On 9 Feb, 13:44, Joseph Gwinn joegw...@comcast.net wrote: In article c2bcn.37983$ym4.23...@text.news.virginmedia.com, David J Taylor david-tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid wrote: I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remote st t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? Chris Chris, Most likely asymmetrical paths, yes. The wide area networks used for international connections are typically SONET rings, which are inherently asymmetrical. As one works around a ring, the poll response time is constant (being the perimeter of the ring), while the out and back times vary with position on the ring with respect to the server one is polling. Joe Gwinn Thanks. ChrisC. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] NTP.conf using Dave Hart code.
Hi, I am attempting to setup a new time server using GPS synchronized time on a Windows XP SP3 box. I started by installing the Meinburg NTP package, which I then updated with Dave Hart's NTP code, and then I put Dave Harts PPS dll on. It appears to be working, however I wanted some input to verify that my NTP.conf file is correct. Here are my objectives: 1) The GPS and PPS signals are coming in on COM1, this seems to be working fine. 2) I ALWAYS want to serve out time, even if it has to be the PC Clock. 3) I want the priority of syncing NTP to be: 1 - PPS synchronized 2 - GPS synchronized 3 - PC Clock. Does the following NTP.conf do this correctly? One questions is if the prefer should be on the PPS or GPS line. # NTP Network Time Protocol # ATTENTION : *You have to restart the NTP service when you change this file to activate the changes* # PLEASE CHECK THIS FILE CAREFULLY AND MODIFY IT IF REQUIRED # Configuration File created by Windows Binary Distribution Installer Rev.: 1.26 mbg # please check http://www.ntp.org for additional documentation and background information # Use drift file driftfile C:\Program Files\NTP\etc\ntp.drift # your local system clock, could be used as a backup # (this is only useful if you need to distribute time no matter how good or bad it is) server 127.127.1.0 # but it should operate at a high stratum level to let the clients know and force them to # use any other timesource they may have. fudge 127.127.1.0 stratum 5 pps 127.127.22.1 stratum 1 gps 127.127.20.1 stratum 2 #refclock servers server 127.127.22.1minpoll 4 # Atom - serialpps.sys server 127.127.20.1minpoll 4 prefer # NMEA serial port # Statistics collection enable stats statsdir C:\Program Files\NTP\etc\ statistics loopstats Thanks for your help. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
cc wrote: I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remotest t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? Chris AFAIK, there is no way to be sure! What is certain is that using sources that distant from your site leaves plenty of room for error! I try to use sources within 300 miles or less. My home system uses a GPS receiver as its primary source. This will work in most reasonable locations! It also provides extremely good accuracy! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
David J Taylor wrote: I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remotest t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? Chris Chris, Most likely asymmetrical paths, yes. To answer your implied question, it is most /unlikely/ that the USA National Time is 17 milliseconds away from Japan National Time, if that's what you were thinking. National time differences are likely to be microseconds or less, I believe. I believe that the word less is appropriate here but might be called an understatement. I'd guess that the various national time standards are within nanoseconds or less. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
cc wrote: On 9 Feb, 11:52, David J Taylor david-tay...@blueyonder.delete-this- bit.and-this-part.co.uk.invalid wrote: cc cjcrick...@googlemail.com wrote in message news:fc3f6bee-dc69-44ec-8525-0cdac516f...@g28g2000yqh.googlegroups.com... [] I wouldn't have thought so either and given that they all trace back to GPS it isn't likely either but it made me consider the natioanal security / financial implications of setting your national clock 10ms ahead of where everyone else thinks it is. Chris. I suspect they all trace back to their own atomic clocks, which gives a good frequency reference, and then they adjust the phase to all be in sync. These days I would guess that GPS is used for the phase (time) sync. There are others on this list who know far more about this than I do, though. So if your loan is 10ms overdue, how much extra interest might you get? G Cheers, David I was thinking more along the lines of a stock market open times / trade times. Chris. ISTR that the stock markets require time stamps to be within two seconds of the true time. That's not terribly demanding, given the available technology. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP.conf using Dave Hart code.
On Feb 9, 13:53 UTC, BK bkrei...@sigmatechcorp.com wrote: pps 127.127.22.1 stratum 1 fudge 127.127.22.1 refid pps stratum 1 gps 127.127.20.1 stratum 2 fudge 127.127.20.1 refid gps stratum 2 But that's not something I'd recommend -- there is no need to fudge stratum for refclock drivers, and you're going to in fact make the refid unreadable if you change from stratum 1. ntpd and ntpq treat stratum 1 refids as 4 ASCII characters, while higher stratum refids are displayed as if they were IPv4 addresses (sometimes they're hashed 32-bit numbers derived from IPv6 addresses). You mentioned using the replacement serialpps.sys driver. Keep in mind that the easiest way to use this with a PPS-enabled GPS connected via serial is to configure only the NMEA driver (20) and leave out the PPS/atom driver (22). The details depend on which version of ntpd you're working with, but the NMEA driver is capable of using PPSAPI to get high-quality PPS timestamps from serialpps.sys, and in a single- driver configuration, there is no need for a separate prefer source. If you do choose to configure both drivers, make sure NMEA isn't attempting to use PPSAPI and leave that to the PPS/atom driver alone, and add prefer to the server 127.127.20.1 line. Cheers, Dave Hart P.S. Very little of the code in ntpd is Dave Hart code. I will take credit for making up-to-date NTP binaries for Windows available regularly: http://davehart.net/ntp/win/x86/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
Richard B. Gilbert rgilber...@comcast.net wrote in message news:nkkdnyae0nzw5-zwnz2dnuvz_uli4...@giganews.com... David J Taylor wrote: [] Most likely asymmetrical paths, yes. To answer your implied question, it is most /unlikely/ that the USA National Time is 17 milliseconds away from Japan National Time, if that's what you were thinking. National time differences are likely to be microseconds or less, I believe. I believe that the word less is appropriate here but might be called an understatement. I'd guess that the various national time standards are within nanoseconds or less. Thanks for the update, Terje and Richard. You must need more digits in the NTP billboard display, then! G I remember the flying of caesium or other atomic clocks round the world, and that folks had to invoke relativistic corrections. Were these better than microseconds as well? Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP.conf using Dave Hart code.
Details: First I installed NTP4.2.4p8 Then I updated the binaries with your updates labeled 4.2.7p8 Then I installed the serial PPS driver 20091228 Although for NTP purposes, you would like only one output string, I have to output two NMEA strings because there is another device looking at the serial stream also. I am outputting GGA and RMC messages. According to the GPS manufacturer (I am using a Garmin GPS15H) the PPS signal is applied just before outputting the NMEA sentences that would be for that time period. I have the PPS signal set to 80ms width. One oddity about my configuration is that the NTP server will not be up 24x7. The machine will be booted, and I would like the ntpd to discipline the local clock to a reasonable (+-10ms) accuracy within 10 minutes. I have another machine that I will then synchronize to the computer with the GPS. Looking at the documentation it appears you can specify which NMEA string to use so perhaps this is better server 127.127.1.0 #the below line is just to remind me how cruddy the base clock might get fudge 127.127.1.0 stratum 5 #tell NMEA reflclock to use RMC messages server 127.127.20.1 minpoll 4 mode 1 # tell NMEA refclock to use PPS fudge 127.127.20.1 refid gps stratum 1 flag1 1 It really doesn't matter to me if I install the serialPPS driver or not. From your discussion it appears using the serialPPS driver is more accurate than the NMEA driver? Does that make it a better choice or is that just making it more confusing? And I really appreciate your help, I have been trying to research this as much as possible on the internet, but I am having a little difficulty because it appears that there are a fair number of differences between the Linux usage of PPS and the windows PPS, etc. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
David J Taylor wrote: Thanks for the update, Terje and Richard. You must need more digits in the NTP billboard display, then! G If you are phk, with hw-assisted pps timing and Rb-based cpu frequency, then the answer is yes, you do. :-) I remember the flying of caesium or other atomic clocks round the world, and that folks had to invoke relativistic corrections. Were these better than microseconds as well? With the corrections, yes absolutely, otherwise they wouldn't have needed to check the clocks in this way. Before common mode GPS observation became the default method to compare clocks, they used to use very wide band radio connections, i.e. like one or more TV channel links running for a long time. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
Richard B. Gilbert wrote: David J Taylor wrote: world, and that folks had to invoke relativistic corrections. Were these better than microseconds as well? Please excuse me if I leave relativistic corrections to the late Professor Einstein! It's not something I've ever needed to know! Oh, but you do! Or at least your GPS does: The sat clocks vary in speed since the orbits are not perfect circles: This means that they run slightly slower than average when in a low orbit part, and slightly faster during the higher parts, so that the average is correct. One of the corrections terms a regular GPS uses is a clock correction based on the orbit eccentricity and current altitude. :-) This also means that a GPS is the only piece of hardware most people will ever own that needs to consider Einstein. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
In article c2bcn.37983$ym4.23...@text.news.virginmedia.com, David J Taylor david-tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid wrote: I've setup an NTP server in the south east asia region synchonising with regional NTP servers as well as a couple of servers I am responsible for in the US. remotest t when poll reach delay offset jitter == +Japan 1 u 454 1024 377 87.402 -0.560 0.056 *Japan 1 u 476 1024 377 87.277 -0.810 1.542 -NorthAmerica 2 u 427 1024 377 285.387 -17.741 5.084 -NorthAmerica 2 u 429 1024 377 307.208 -17.061 0.083 Is the above delta seen between Japanese and North American time sources purely the delta between the outbound / return network path or something else? Chris Chris, Most likely asymmetrical paths, yes. The wide area networks used for international connections are typically SONET rings, which are inherently asymmetrical. As one works around a ring, the poll response time is constant (being the perimeter of the ring), while the out and back times vary with position on the ring with respect to the server one is polling. Joe Gwinn ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
On 2010-02-10, David J Taylor david-tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid wrote: David Woolley da...@ex.djwhome.demon.invalid wrote in message news:hksmaf$1c...@news.eternal-september.org... David J Taylor wrote: I remember the flying of caesium or other atomic clocks round the world, and that folks had to invoke relativistic corrections. Were these better than microseconds as well? That's called Navstar (GPS) and GPS position solutions do have to include a general relativity correction to the satellite clocks. Not today's GPS, but some forty or more years ago: http://www.hp.com/hpinfo/abouthp/histnfacts/timeline/hist_60s.html 1964: The highly accurate HP 5060A cesium-beam atomic clocks gain worldwide recognition as the flying clocks when they are flown from Palo Alto to Switzerland to compare time as maintained by the U.S. Naval Observatory in Washington, D.C. to time at the Swiss Observatory in Neuchatel. The atomic clock was designed to maintain accuracy for 3000 years with only one second of error. The cesium-beam standard becomes the standard for international time. I had wondered what accuracy was obtained - i.e. how far was each nation out - and whether relativistic corrections had been needed for these flying clock tests. 1 sec/3000years is 1 part in 10^-11. The gravitational redshift is gh/c^2 (g is gravity acceln on earth, h the height of the flight, and c vel of light) which is 10^-12 -- ie below ( but not by much) the accuracy of the clock. The velocity correction is 1/2 v^2/c^2 which is again about 1 part in 10^12. Ie, both corrections are smaller (but not much) than the uncertainty in the clock rate. If the plane flew at Mach 2, rather than well below Mach 1, you could get that velocity correction up the accuracy and one would have to take special relativity into account. Since the flight probably lasted say 10 hr, which is 10 sec, th eclocks would have been out by about 1usec. Assuming that the clocks could then have been synchronized, that would mean that US and Switzerland time have been out by about 1usec. (Why they would fly from Palo Alto when the time standard is in Washington DC I have no idea). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] National time standard differences
unruh un...@wormhole.physics.ubc.ca wrote: On 2010-02-10, David J Taylor david-tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid wrote: David Woolley da...@ex.djwhome.demon.invalid wrote in message news:hksmaf$1c...@news.eternal-september.org... David J Taylor wrote: I remember the flying of caesium or other atomic clocks round the world, and that folks had to invoke relativistic corrections. Were these better than microseconds as well? That's called Navstar (GPS) and GPS position solutions do have to include a general relativity correction to the satellite clocks. Not today's GPS, but some forty or more years ago: http://www.hp.com/hpinfo/abouthp/histnfacts/timeline/hist_60s.html 1964: The highly accurate HP 5060A cesium-beam atomic clocks gain worldwide recognition as the flying clocks when they are flown from Palo Alto to Switzerland to compare time as maintained by the U.S. Naval Observatory in Washington, D.C. to time at the Swiss Observatory in Neuchatel. The atomic clock was designed to maintain accuracy for 3000 years with only one second of error. The cesium-beam standard becomes the standard for international time. I had wondered what accuracy was obtained - i.e. how far was each nation out - and whether relativistic corrections had been needed for these flying clock tests. 1 sec/3000years is 1 part in 10^-11. The gravitational redshift is gh/c^2 (g is gravity acceln on earth, h the height of the flight, and c vel of light) which is 10^-12 -- ie below ( but not by much) the accuracy of the clock. The velocity correction is 1/2 v^2/c^2 which is again about 1 part in 10^12. Ie, both corrections are smaller (but not much) than the uncertainty in the clock rate. If the plane flew at Mach 2, rather than well below Mach 1, you could get that velocity correction up the accuracy and one would have to take special relativity into account. Since the flight probably lasted say 10 hr, which is 10 sec, th eclocks would have been out by about 1usec. Assuming that the clocks could then have been synchronized, that would mean that US and Switzerland time have been out by about 1usec. (Why they would fly from Palo Alto when the time standard is in Washington DC I have no idea). Probably because the clocks came out of the HP Palo Alto office? -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
