Re: [ntp:questions] Updating the leapseconds file -- how to signal ntpd
On 27/01/2013 01:56, Garrett Wollman wrote: In article , Hal Murray wrote: I suggest submitting a feature request at https://support.ntp.org/bugs/index.cgi with a link back to the above bug since it will be the same area of code. Too many hoops to jump through. Maybe someone who already has an account at that site can do it. -GAWollman I've added that for you: https://support.ntp.org/bugs/show_bug.cgi?id=2339 but please get an account, Garrett, so that you can contribute to the discussion. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using NTP to calibrate sound app
"Maurice Janssen" wrote in message news:5103d110$0$6943$e4fe5...@news.xs4all.nl... > Maarten Wiltink wrote: >> Which is exactly why hardcoding pool.ntp.org _is_ allowable, in my >> opinion - and in fact indicated in such a case as this. > > In my opinion, it's not. > Please read http://www.pool.ntp.org/en/vendors.html . I stand corrected. Indeed getting and using .pool.ntp.org is superior. At that point, however, it strikes me that using time..tld serves the vendor even better, what with having actual control over the domain and all. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Updating the leapseconds file -- how to signal ntpd
Garrett, NTP 4.2.7 has been in development for over 6 months and is very stable, yet, yes, it's still in development. Regards, Ed > > 2013/1/27, Garrett Wollman : > > In article > > , > > Michael Tatarinov wrote: > >>I know only one way. > >>ntpq -c 'config: leapfile LEAPFILE" > > > > That was what I was looking for! In my version of ntpq, at least, > > it's spelled ':config' rather than 'config:', but that did it. > > > > Unfortunately, this still doesn't get me anywhere, because the > > "passwd" command in ntpq 4.2.6 doesn't take any arguments. Looks like > > this is fixed in ntp-dev 4.2.7, so I'll have to wait until 4.2.7 > > becomes the official stable version. > > you can try to use ntpq 4.2.7 with ntpd 4.2.6 > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using NTP to calibrate sound app
Wow, 10 responses in one day. Thanks to everyone. @David Woolley: Perhaps you are right about SNTP vs. NTP. My app in iPhones and Android devices cannot have access to kernel timing modification, as a well-behaved app. And the system timing crystal in a smartphone is usually not the same one that runs the audio sampling clock. So the audio sampling clock needs to be compared to NTP time/frequency directly. @unruh: You are exactly right. Whatever network jitter there is I just need to have a calibration run sufficiently long so that the derived frequency is close enough. Given infinite time I can make arbitrarily precise frequency measurements. Of course the limiting factor is user bother in putting up with a long calibration run. I hope to mitigate that problem by the following: 1. This calibration is only needed once when the user installs my app. 2. The calibration, once initiated, will run unattended. So the user will be instructed to start the calibration and then leave the smartphone alone. During that time our app will have to be running continuously, so we will recommend that the user leave the phone plugged in to a charger, preferably overnight. When he wakes in the morning the calibration will have been completed. Unfortunately the calibration software cannot be interrupted by a phone call. So if it is interrupted the user will just be notified that the calibration was aborted because of the interruption and he will have to start the calibration run over again. But I don't see that as a big problem. My estimates of the time span now, based on expected network jitter, is about one hour. It is not that hard to have one hour of uninterrupted time, especially if the user starts the calibration run just before retiring for the night. @Maarten Wiltink and Maurice: OK, I will read up on using .pool.ntp.org to select my time server. But is there any problem trying to use the same time server (or servers) at the beginning and the end of the calibration run? I don't need to access the time servers in the middle of the run, just and the beginning and the end. Or is there even any advantage to trying to use the same servers on both ends? After all the network delays could change quite a bit over the course of an hour, or even from one sample to the next. And the protocol is supposed to factor out symmetric delays anyway. @David Woolley: Your comment about phone networks being digital is a concern I have been wondering about too, especially regarding Skype. Since Skype relies on indeterminately delayed Internet data, the timing of the reproduced audio is bound to be a function of the local computer's sound system oscillator, maybe soft locked to the Internet data stream. But calibrating for the reproduced sound sampling rate in Skype is no easier than the problem I am facing. So I suspect that short-term frequency variations in Skype-reproduced audio is inevitable. With my old method of calibrating to NIST tones over the phone I advise my users to avoid any form of Internet phone service. But I think cell phones are probably OK because they can be tightly locked to the cell towers' timing, which as you say is usually very precise. However I have seen desktop computer sound cards whose actual audio sampling rate is off from nominal by as much as 6 parts per thousand, which is strange because I know that even the cheapest quartz crystals are rated for better accuracy than that. In case you are wondering, my app is a professional piano tuning app. The standard in this industry is that tuning devices should be accurate to 12 parts per million. I know that is probably overkill for tuning pianos, but that is what the professionals expect from their equipment. Robert Scott Hopkins, MN ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Updating the leapseconds file -- how to signal ntpd
In article <31033FCF05BEE64695655345F1E94EF015FFDD21@BHW-MBX-02>, Mischanko, Edward T wrote: >NTP 4.2.7 has been in development for over 6 months and is very stable, > yet, yes, it's still in development. And when it ceases to be "in development" and the FreeBSD net/ntp port becomes 4.2.7 instead of 4.2.6, then I will run it. Not before. -GAWollman -- Garrett A. Wollman| What intellectual phenomenon can be older, or more oft woll...@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using NTP to calibrate sound app
On 2013-01-27, no-...@no-place.org wrote: > @unruh: You are exactly right. Whatever network jitter there is I > just need to have a calibration run sufficiently long so that the > derived frequency is close enough. Given infinite time I can make Well, no. the problem is that as time goes on, the clock itself has frequency shifts ( temperature changes, crystal aging,...) > arbitrarily precise frequency measurements. Of course the limiting > factor is user bother in putting up with a long calibration run. I > hope to mitigate that problem by the following: > > 1. This calibration is only needed once when the user installs my app. > 2. The calibration, once initiated, will run unattended. So the user > will be instructed to start the calibration and then leave the > smartphone alone. During that time our app will have to be running > continuously, so we will recommend that the user leave the phone > plugged in to a charger, preferably overnight. When he wakes in the > morning the calibration will have been completed. See above. After a few days, the sound crystal frequency will have drifted ( whether enough to bother you I do not know). There is a concept of the Allen minimum which gives essentially the ideal time between calibrations. ntp has this problem and tries to alter the calibration time scale to get to that minimum. > > Unfortunately the calibration software cannot be interrupted by a > phone call. So if it is interrupted the user will just be notified > that the calibration was aborted because of the interruption and he > will have to start the calibration run over again. But I don't see > that as a big problem. My estimates of the time span now, based on > expected network jitter, is about one hour. It is not that hard to > have one hour of uninterrupted time, especially if the user starts the > calibration run just before retiring for the night. > > > In case you are wondering, my app is a professional piano tuning app. > The standard in this industry is that tuning devices should be > accurate to 12 parts per million. I know that is probably overkill > for tuning pianos, but that is what the professionals expect from > their equipment. Ah. I would expect 1 cent, which is more like 500PPM. > > Robert Scott > Hopkins, MN ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Updating the leapseconds file -- how to signal ntpd
Garrett, I didn't realize that my comment would be so offensive to you. Please accept my apology for trying to be helpful. Regards, Ed > In article <31033FCF05BEE64695655345F1E94EF015FFDD21@BHW-MBX-02>, > Mischanko, Edward T wrote: > > >NTP 4.2.7 has been in development for over 6 months and is very stable, > > yet, yes, it's still in development. > > And when it ceases to be "in development" and the FreeBSD net/ntp port > becomes 4.2.7 instead of 4.2.6, then I will run it. Not before. > > -GAWollman > > -- > Garrett A. Wollman| What intellectual phenomenon can be older, or more > oft > woll...@bimajority.org| repeated, than the story of a large research > program > Opinions not shared by| that impaled itself upon a false central > assumption > my employers. | accepted by all practitioners? - S.J. Gould, 1993 > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using NTP to calibrate sound app
On 27/01/2013 19:33, unruh wrote: On 2013-01-27, no-...@no-place.org wrote: [] In case you are wondering, my app is a professional piano tuning app. The standard in this industry is that tuning devices should be accurate to 12 parts per million. I know that is probably overkill for tuning pianos, but that is what the professionals expect from their equipment. Ah. I would expect 1 cent, which is more like 500PPM. 1% (10,000 ppm) is a 4.4 cycles per second beat at 440 Hz! Completely unacceptable. You want an imperceptible beat, ideally, well under 1 Hz. Agreed that 12 ppm is overkill. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using NTP to calibrate sound app
David Taylor wrote: > On 27/01/2013 19:33, unruh wrote: >> On 2013-01-27, no-...@no-place.org wrote: > [] >>> In case you are wondering, my app is a professional piano tuning app. >>> The standard in this industry is that tuning devices should be >>> accurate to 12 parts per million. I know that is probably overkill >>> for tuning pianos, but that is what the professionals expect from >>> their equipment. >> >> Ah. I would expect 1 cent, which is more like 500PPM. > > 1% (10,000 ppm) is a 4.4 cycles per second beat at 440 Hz! Completely > unacceptable. You want an imperceptible beat, ideally, well under 1 Hz. > Agreed that 12 ppm is overkill. The general rule of thumb for metrology is that your instrument should be at least an order of magnitude better than the allowable error, i.e. if your allowed error is 1%, your instrument should be capable of measuring to an accuracy of at least 0.1% for the measurement to be meaningful. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using NTP to calibrate sound app
On 2013-01-27, David Taylor wrote: > On 27/01/2013 19:33, unruh wrote: >> On 2013-01-27, no-...@no-place.org wrote: > [] >>> In case you are wondering, my app is a professional piano tuning app. >>> The standard in this industry is that tuning devices should be >>> accurate to 12 parts per million. I know that is probably overkill >>> for tuning pianos, but that is what the professionals expect from >>> their equipment. >> >> Ah. I would expect 1 cent, which is more like 500PPM. > > 1% (10,000 ppm) is a 4.4 cycles per second beat at 440 Hz! Completely > unacceptable. You want an imperceptible beat, ideally, well under 1 Hz. > Agreed that 12 ppm is overkill. I agree that 1% is pretty bad-- that is 1/6 of a semitone, which is clealy preceptible. However 1 cent, 1/100 of a semitone, is the limit of audibility, and it is VERY hard to tune a piano string to 1 cent (pin slippage and adjustment, frequency coupling between the various strings which play the same note, anharmonicity of the string)-- it is not even clear what that means for the above reasons. 1 cent (NOT 1 percent-- a cent is 1/100 of a semitone) is about 1.0006 frequency ratio (.06%). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Updating the leapseconds file -- how to signal ntpd
"Mischanko, Edward T" writes: > Garrett, > > NTP 4.2.7 has been in development for over 6 months and is very stable, > yet, yes, it's still in development. 4.2.7 is in a code-freeze pending the release of 4.2.8. There are <20 small bugs remaining to be fixed, and these issues have mosly been around for quite a while, so they are likely problem with 4.2.6. If 4.2.6 has been good for you, recent ntp-dev should be at least as good, and often better. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Updating the leapseconds file -- how to signal ntpd
On 2013-01-27, Garrett Wollman wrote: > And when it ceases to be "in development" and the FreeBSD net/ntp port > becomes 4.2.7 instead of 4.2.6, then I will run it. The next FreeBSD net/ntp "port" will be 4.2.8 http://support.ntp.org/Main/ReleaseNumberingScheme explains why. Stable releases have an even Minor Release number Development releases have an odd Minor Release number The curent release numbering scheme syntax is Protocol_Version.Major_Version.Minor_Version[Release_Tags] -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using NTP to calibrate sound app
On 2013-01-27 23:43, unruh wrote: On 2013-01-27, David Taylor wrote: On 27/01/2013 19:33, unruh wrote: On 2013-01-27, no-...@no-place.org wrote: [] In case you are wondering, my app is a professional piano tuning app. The standard in this industry is that tuning devices should be accurate to 12 parts per million. I know that is probably overkill for tuning pianos, but that is what the professionals expect from their equipment. Ah. I would expect 1 cent, which is more like 500PPM. 1% (10,000 ppm) is a 4.4 cycles per second beat at 440 Hz! Completely unacceptable. You want an imperceptible beat, ideally, well under 1 Hz. Agreed that 12 ppm is overkill. I agree that 1% is pretty bad-- that is 1/6 of a semitone, which is clealy preceptible. However 1 cent, 1/100 of a semitone, is the limit of audibility Not really. A cent is simply 1/100th of a semitone, no more, no less. It's true that few if any should be able to distinguish a note from a note that's one cent off when heard in isolation, but the cent is not some sort of biological limit, as far as I know. When played together, a difference of one cent between notes is certainly audible in the beating (at least on artificial waves, I have no idea if the same is true for physical pianos). Whether you can even physically tune a piano that accurately is another matter altogether. Even if you can't, you should still like to be able to tell that you didn't. Even if you consider accurate detection of 1 cent to be good enough for tuning purposes, your measuring equipment still needs to be an order of magnitude better. A 0.1 cent difference is 57.8 ppm. 12 ppm is 0.02 cent, which isn't excessive if you're going for 0.2 cent accuracy. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
