Re: [ntp:questions] Comparison between ntpd and TSCclock
"David L. Mills" <[EMAIL PROTECTED]> writes: >Bill, >Who, me? Paper reviewers are supposed to anonymous. Let's just say I >agree with your assessment. Ah. OK. the anonymity is a consideration. Of course you could have come up with your objections to the paper entirely independently of that anonymous referee, and your agreement was just that any true thinkers would have agreed! >I've seen a number of papers like this; some I have reviewed. They are >written by folks with computer science backgrounds and are not well >trained in physics and engineering principles and even less in the >physical properties of real oscillators. You (and others) might not like >the NTP mitigation and discipline algorithms, but each one is based on >thorough analysis with respect to sound physics and engineering >principles as confirmed by measurement over a wide body of scenarios. >Unruh wrote: >> "David L. Mills" <[EMAIL PROTECTED]> writes: >> >> >>>Gene, >> >> >>>I've seen and reviewed the paper; however, reviews are private to the >> >> >> Their paper is public. It is posted on the web. >> >> >>>authors. Someone else should take a close look at what they are actually >>>measuring and assess the dynmaics of the discipline loop. >> >> >> Did you do so? If so, your analysis would be of interest. And I cannot see >> why the analysis of a public paper should be kept private. >> >> >> >>>Dave >> >> >>>[EMAIL PROTECTED] wrote: >>> Developers at the University of Melbourne have produced a time-sync client called "TSCclock" which exchanges standard NTP packets with a NTP server. They assert that TSCclock, which runs on FreeBSD and at least two flavors of Linux (Ubuntu and Fedora), provides substantially better synchronization than ntpd both on a LAN and over the Internet. The following info is some of what is available: 1. The TSCclock page at the University of Melbourne: http://www.cubinlab.ee.unimelb.edu.au/tscclock/ 2. A paper titled "Ten Microseconds Over LAN, for Free", originally presented at the 2007 International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication. This is available at http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/ISPCS07_camera.pdf It includes a general description of their approach and results for both ntpd and TSCclock obtained in their testbed. 3. A one-hour Google Tech Talk: http://www.youtube.com/watch?v=o3nXgeh7v_U All of the info on TSCclock that I have run across has originated with the group at the University of Melbourne. Does anyone know of an independent comparison between ntpd and TSCclock? Thanks, Gene ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Comparison between ntpd and TSCclock
Bill, Who, me? Paper reviewers are supposed to anonymous. Let's just say I agree with your assessment. I've seen a number of papers like this; some I have reviewed. They are written by folks with computer science backgrounds and are not well trained in physics and engineering principles and even less in the physical properties of real oscillators. You (and others) might not like the NTP mitigation and discipline algorithms, but each one is based on thorough analysis with respect to sound physics and engineering principles as confirmed by measurement over a wide body of scenarios. Unruh wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > > >>Gene, > > >>I've seen and reviewed the paper; however, reviews are private to the > > > Their paper is public. It is posted on the web. > > >>authors. Someone else should take a close look at what they are actually >>measuring and assess the dynmaics of the discipline loop. > > > Did you do so? If so, your analysis would be of interest. And I cannot see > why the analysis of a public paper should be kept private. > > > >>Dave > > >>[EMAIL PROTECTED] wrote: >> >>>Developers at the University of Melbourne have produced a time-sync >>>client called "TSCclock" which exchanges standard NTP packets with a >>>NTP server. They assert that TSCclock, which runs on FreeBSD and at >>>least two flavors of Linux (Ubuntu and Fedora), provides substantially >>>better synchronization than ntpd both on a LAN and over the Internet. >>> >>>The following info is some of what is available: >>> >>>1. The TSCclock page at the University of Melbourne: >>>http://www.cubinlab.ee.unimelb.edu.au/tscclock/ >>> >>>2. A paper titled "Ten Microseconds Over LAN, for Free", originally >>>presented at the 2007 International IEEE Symposium on Precision Clock >>>Synchronization for Measurement, Control and Communication. This is >>>available at >>>http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/ISPCS07_camera.pdf >>>It includes a general description of their approach and results for >>>both ntpd and TSCclock obtained in their testbed. >>> >>>3. A one-hour Google Tech Talk: http://www.youtube.com/watch?v=o3nXgeh7v_U >>> >>>All of the info on TSCclock that I have run across has originated with >>>the group at the University of Melbourne. Does anyone know of an >>>independent comparison between ntpd and TSCclock? >>> >>>Thanks, >>>Gene ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP slow to start correction after a drift
Bill, You seem to have a tack up your tail about the clock filter algorithm. First, you didn't respond to my message about sampling at twice the Nyquist rate, even if a burst of seven samples is lost. Second, look at the clock filter algorithm code and comments. Samples older than the Allan intercept (default 2000 s) are effectively discarded. Thus, only the latest sample is used and the next older used only to compute the peer jitter. Third, if you recall my recent message about the poll algorithm, you know the jiggle counter is reduced if the (combined) clock offset exceeds twice the clock jitter. With the constants revealed in my prior message, and if the clock frequency is yanked 1 PPM by a Grue, all it takes is two samples and the poll interval/time constant drops by half. Dave Unruh wrote: > Mike K Smith <[EMAIL PROTECTED]> writes: > > >>On 12 May, 15:16, "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote: >> >>>Mike K Smith wrote: > > Looks like I should be reducing maxpoll. I guess the design of NTP is optimised for clocks with predictable drift rates, and a sudden variation in drift rate takes longer to correct. >>> >>>You DO know that NTPD adjusts the poll interval to fit the current >>>conditions??? =A0It will increase the poll interval to MAXPOLL only when >>>the clock is stable and very close to being correct. =A0The default values= > > >>>of MINPOLL and MAXPOLL are correct for all but the weirdest cases. > > >>I know that ntpd adjusts the poll interval to fit the current >>conditions, but I am describing a case where the current conditions >>changed. The clock had been stable for around a week, and the polling >>interval had increased to 1024 seconds, then something changed. It >>looks like the clock started drifting by about 2ppm, the poll interval >>didn't change for three hours causing a 15ms offset before beginning >>to correct the drift. > > > with a poll interval of 1024 the actual poll is about 8000 sec ( after the > clock filter which throws away about 7 out of 8 data points). That is about > 2 hours, so it is impossible for the system to even recognize that > something has happened in less than about 2 hours. It can then try to start > correcting and start to try to reduce the poll interval. Why does it throw > away all that data? It is believed that the gain in using the minimum delay > out of 8 is more than the loss in responsiveness, and in accuracy. (The > procedure is to try to get rid of data which might have a large assymetric > drift. ) This means that if the clock is 10ms out and the delay is .1ms, it > may still be thrown out since that .1 ms is greater than the .095 ms > achieved 7 poll intervals ago, despite the fact that the data shows > incontrovertably that the clock is having far more problems than could > ever be hidden in the delay. > > >>I initiated this thread to help me understand why ntpd took so long to >>respond. I had expected to see the poll interval decrease and the >>offset swing back towards zero after the first couple of polls showed >>the increased offset. > > >>>Are you operating your machines in a controlled (temperature) >>>environment? =A0If the temperature bounces around, so will your clock. >>>NTPD will correct it but if the temperature drops five degrees in five >>>minutes when the air conditioning kicks in, NTPD may have a little >>>difficulty keeping up. > > >>The systems are in air-conditioned equipment rooms, I wasn't expecting >>to frequency changes due to temperature. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] frequency adjusting only
Evandro, We didn't account for gravity and time dilation, as the errors in the extrapolated ephemeris data dominated the error budget. I am told accurate spacecraft navigation needs time to the nanosecond. In principle, the Proximity-I protocol and NTP onwire protocol can do that, I don't think the transceiver clocks and onboard rover clocks are anywhere near that caliber. Dave Evandro Menezes wrote: > On May 4, 2:37 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > >>On symmetry, etc. There are both gravitational and velocity corrections >>relative to both Earth and solar system barycentric time amounting to >>some 15 ms, but current space missions don't worry much about that. The >>mission times are relative to a clock onboard the spacecraft; nothing >>else matters. Our Earth-Mars simulations didn't worry about these >>effects either. I suspect disciplining an orbiter/rover clock to these >>corrections will be dominated by the frequency noise of affordable >>oscillators. Maybe not. > > > Just curious, but did you have to deal with relativistic effects of > relative time dilation as the craft speed increased? > > TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Comparison between ntpd and TSCclock
Unruh wrote: > "Brian Garrett" <[EMAIL PROTECTED]> writes: > >> Are they planning an implementation for Windoze anytime soon? > > HOw would you get good results when you have no means of controlling > the clock except stepping? Are you sure? Windows provides a rate adjustment, as well as stepping. David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Comparison between ntpd and TSCclock
"David L. Mills" <[EMAIL PROTECTED]> writes: >Gene, >I've seen and reviewed the paper; however, reviews are private to the Their paper is public. It is posted on the web. >authors. Someone else should take a close look at what they are actually >measuring and assess the dynmaics of the discipline loop. Did you do so? If so, your analysis would be of interest. And I cannot see why the analysis of a public paper should be kept private. >Dave >[EMAIL PROTECTED] wrote: >> Developers at the University of Melbourne have produced a time-sync >> client called "TSCclock" which exchanges standard NTP packets with a >> NTP server. They assert that TSCclock, which runs on FreeBSD and at >> least two flavors of Linux (Ubuntu and Fedora), provides substantially >> better synchronization than ntpd both on a LAN and over the Internet. >> >> The following info is some of what is available: >> >> 1. The TSCclock page at the University of Melbourne: >> http://www.cubinlab.ee.unimelb.edu.au/tscclock/ >> >> 2. A paper titled "Ten Microseconds Over LAN, for Free", originally >> presented at the 2007 International IEEE Symposium on Precision Clock >> Synchronization for Measurement, Control and Communication. This is >> available at >> http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/ISPCS07_camera.pdf >> It includes a general description of their approach and results for >> both ntpd and TSCclock obtained in their testbed. >> >> 3. A one-hour Google Tech Talk: http://www.youtube.com/watch?v=o3nXgeh7v_U >> >> All of the info on TSCclock that I have run across has originated with >> the group at the University of Melbourne. Does anyone know of an >> independent comparison between ntpd and TSCclock? >> >> Thanks, >> Gene ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Comparison between ntpd and TSCclock
"Brian Garrett" <[EMAIL PROTECTED]> writes: >Are they planning an implementation for Windoze anytime soon? HOw would you get good results when you have no means of controlling the clock except stepping? >Brian ><[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> Developers at the University of Melbourne have produced a time-sync >> client called "TSCclock" which exchanges standard NTP packets with a >> NTP server. They assert that TSCclock, which runs on FreeBSD and at >> least two flavors of Linux (Ubuntu and Fedora), provides substantially >> better synchronization than ntpd both on a LAN and over the Internet. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Comparison between ntpd and TSCclock
[EMAIL PROTECTED] writes: >Developers at the University of Melbourne have produced a time-sync >client called "TSCclock" which exchanges standard NTP packets with a >NTP server. They assert that TSCclock, which runs on FreeBSD and at >least two flavors of Linux (Ubuntu and Fedora), provides substantially >better synchronization than ntpd both on a LAN and over the Internet. >The following info is some of what is available: >1. The TSCclock page at the University of Melbourne: >http://www.cubinlab.ee.unimelb.edu.au/tscclock/ >2. A paper titled "Ten Microseconds Over LAN, for Free", originally >presented at the 2007 International IEEE Symposium on Precision Clock >Synchronization for Measurement, Control and Communication. This is >available at >http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/ISPCS07_camera.pdf >It includes a general description of their approach and results for >both ntpd and TSCclock obtained in their testbed. The paper suffers from talking nonesense. NTP is certainly better than 1ms on a lan, and their data shows that the jitter is around .1-.2 ms. Exagerating the difference does not do them any favours. Note that chrony ( a 10 year old system) already gives 10usec for free on the lan. Futhermore their poll interval for their system is much higher than that of ntp. I get about .05 msec jitter for ntp on a lan, at least on my testbed. The ideas are interesting ( certainly their attempt to compensate for network jitter, their chief difference from ntp, is far superior to the clock filter approach of ntp, and I suspect superiour to the "weighting" approach of chrony ( the data is weighted by the inverse of the delay) >3. A one-hour Google Tech Talk: http://www.youtube.com/watch?v=o3nXgeh7v_U >All of the info on TSCclock that I have run across has originated with >the group at the University of Melbourne. Does anyone know of an >independent comparison between ntpd and TSCclock? >Thanks, >Gene ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP slow to start correction after a drift
Mike K Smith <[EMAIL PROTECTED]> writes: >On 12 May, 15:16, "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote: >> Mike K Smith wrote: >> > Looks like I should be reducing maxpoll. I guess the design of NTP is >> > optimised for clocks with predictable drift rates, and a sudden >> > variation in drift rate takes longer to correct. >> >> You DO know that NTPD adjusts the poll interval to fit the current >> conditions??? =A0It will increase the poll interval to MAXPOLL only when >> the clock is stable and very close to being correct. =A0The default values= >> of MINPOLL and MAXPOLL are correct for all but the weirdest cases. >I know that ntpd adjusts the poll interval to fit the current >conditions, but I am describing a case where the current conditions >changed. The clock had been stable for around a week, and the polling >interval had increased to 1024 seconds, then something changed. It >looks like the clock started drifting by about 2ppm, the poll interval >didn't change for three hours causing a 15ms offset before beginning >to correct the drift. with a poll interval of 1024 the actual poll is about 8000 sec ( after the clock filter which throws away about 7 out of 8 data points). That is about 2 hours, so it is impossible for the system to even recognize that something has happened in less than about 2 hours. It can then try to start correcting and start to try to reduce the poll interval. Why does it throw away all that data? It is believed that the gain in using the minimum delay out of 8 is more than the loss in responsiveness, and in accuracy. (The procedure is to try to get rid of data which might have a large assymetric drift. ) This means that if the clock is 10ms out and the delay is .1ms, it may still be thrown out since that .1 ms is greater than the .095 ms achieved 7 poll intervals ago, despite the fact that the data shows incontrovertably that the clock is having far more problems than could ever be hidden in the delay. >I initiated this thread to help me understand why ntpd took so long to >respond. I had expected to see the poll interval decrease and the >offset swing back towards zero after the first couple of polls showed >the increased offset. >> Are you operating your machines in a controlled (temperature) >> environment? =A0If the temperature bounces around, so will your clock. >> NTPD will correct it but if the temperature drops five degrees in five >> minutes when the air conditioning kicks in, NTPD may have a little >> difficulty keeping up. >The systems are in air-conditioned equipment rooms, I wasn't expecting >to frequency changes due to temperature. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] frequency adjusting only
On May 4, 2:37 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > > On symmetry, etc. There are both gravitational and velocity corrections > relative to both Earth and solar system barycentric time amounting to > some 15 ms, but current space missions don't worry much about that. The > mission times are relative to a clock onboard the spacecraft; nothing > else matters. Our Earth-Mars simulations didn't worry about these > effects either. I suspect disciplining an orbiter/rover clock to these > corrections will be dominated by the frequency noise of affordable > oscillators. Maybe not. Just curious, but did you have to deal with relativistic effects of relative time dilation as the craft speed increased? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual Mixer Time Difference (DMTD) instruments sought
In article <[EMAIL PROTECTED]>, jlevine <[EMAIL PROTECTED]> wrote: > > I may need a Dual Mixer Time Difference (DMTD) instrument, to measure > > picosecond changes in electrical length in a coax plus amplifier time > > reference signal distribution system with total delays in the hundreds > > of nanoseconds, currently operating at 10 MHz (sinewave), but with 100 > > MHz likely at some future date. > > > > What DMTD instruments are commercially available? A google search was > > not successful - all noise no detectable signal, probably because DMTD > > instruments are not that common, and many people build their own. > >We use dual-mixer systems in our primary time scale and also to > calibrate and evaluate oscillators and timing hardware. So far as I > know, the only units that are commercially available are made by Timing > Solutions, which was recently acquired by Symmetricom. There > are a number of different configurations, depending how how many > devices you want to measure, whether they all run at the same > frequency, etc. That's been what I'm finding, and now this is being confirmed. I don't know why Symmetricom keeps the 5120 under their hat. It's really a strange story - the only way to find out that the 5120 is a DMTD instrument (done up in all-digital DSP form) was by knowing that TSC used to make an analog DMTD instrument, and following TSC's (and specifically Dr Stein's) trail in the literature. >It is possible to build these devices on your own, but it is not > trivial to get pico-second resolution and stability. Almost everything > is temperature sensitive at this level of resolution. I think such instruments are also sensitive to user mood. While it's unlikely that I will soon get to build such an instrument, I am quite interested in how they are built, if only to understand what can happen and why. Can you suggest some articles and/or books and/or patents delving into both the theory and the practicalities of building DMTD instruments? Thanks, Joe Gwinn ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual Mixer Time Difference (DMTD) instruments sought
In article <[EMAIL PROTECTED]>, Uwe Klein <[EMAIL PROTECTED]> wrote: > Joseph Gwinn wrote: > > > OK. It sounds like what the 5120 does. I be that there are a lot of > > details to get *exactly* right, though. > Right. > > But with having a ten year old Cray in every laptop ... Computational power must be harnessed to be useful. I'm talking about the considerable human effort required for the harnessing. Joe Gwinn ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual Mixer Time Difference (DMTD) instruments sought
> I may need a Dual Mixer Time Difference (DMTD) instrument, to measure > picosecond changes in electrical length in a coax plus amplifier time > reference signal distribution system with total delays in the hundreds > of nanoseconds, currently operating at 10 MHz (sinewave), but with 100 > MHz likely at some future date. > > What DMTD instruments are commercially available? A google search was > not successful - all noise no detectable signal, probably because DMTD > instruments are not that common, and many people build their own. We use dual-mixer systems in our primary time scale and also to calibrate and evaluate oscillators and timing hardware. So far as I know, the only units that are commercially available are made by Timing Solutions, which was recently acquired by Symmetricom. There are a number of different configurations, depending how how many devices you want to measure, whether they all run at the same frequency, etc. It is possible to build these devices on your own, but it is not trivial to get pico-second resolution and stability. Almost everything is temperature sensitive at this level of resolution. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
