Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Tom Van Baak
Hi Mike, > Interesting plots. A couple of points. > 1. These look like the data points are taken at 0h and without intermediary > measurements as the data points are connected by straight line segments. > If we don’t know what the intermediary data points are, the plots, to my mind, > should be

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Steve Allen
On Sat 2016-07-23T12:36:21 -0700, Tom Van Baak hath writ: > I've always been curious about the conflict between accuracy and > stability with these various time scales. > > If the purpose of a UTx clock is long-term timekeeping, then I can > see that smoothing is helpful. OTOH, if the purpose of

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Mike Cook
> Le 23 juil. 2016 à 21:56, Tom Van Baak a écrit : > > To further clarify my question about which UTx timescale to use with NTP, or > if or how to interpolate the values I've attached two plots from IERS for the > past 60 days. > > BTW, notice last week we had another

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Tom Van Baak
To further clarify my question about which UTx timescale to use with NTP, or if or how to interpolate the values I've attached two plots from IERS for the past 60 days. BTW, notice last week we had another rare moment -- where the Earth had a near perfect 86400.0 second day! My question

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Tom Van Baak
lt;s...@ucolick.org> To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com> Sent: Saturday, July 23, 2016 8:52 AM Subject: Re: [time-nuts] NIST UT1 NTP server results > On Sat 2016-07-23T10:10:07 -0400, Bob Camp hath writ: >> Ok, so now what we need are

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Bob Camp
HI I agree that there are more considerations than simply changing the world over to UT1. My guess is that the TimeNuts list is unlikely to answer those questions. We *could* get a handful of servers running. Experimenting with them is likely a prerequisite to any change down the road. Bob >

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Steve Allen
On Sat 2016-07-23T10:10:07 -0400, Bob Camp hath writ: > Ok, so now what we need are at least 5 other public UT1 NTP servers so you > can properly > synch up to a set of them. If this turns into a serious thing then it deserves consideration whether such servers should be UT1, or instead UT2.

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Bob Camp
Hi Ok, so now what we need are at least 5 other public UT1 NTP servers so you can properly synch up to a set of them. Bob > On Jul 23, 2016, at 8:47 AM, Mike Cook wrote: > > As I suspected NTP client handles the UT1 data ok if there is just that > server configured. >

Re: [time-nuts] NIST UT1 NTP server results

2016-07-23 Thread Mike Cook
As I suspected NTP client handles the UT1 data ok if there is just that server configured. The only issue is that the current UT1 stream has steps at 0h which NTP takes time to sync to if slewing is enabled. About 2000s in fact. The step size is far less than the max offset allowed and so

Re: [time-nuts] NIST UT1 NTP server results

2016-07-22 Thread Mike Cook
> Le 23 juil. 2016 à 00:23, John Hawkinson a écrit : > > I have to wonder if it's really such a great idea to have this > as an open NTP server without huge red flags that it is not UTC. > One could imagine it leading to big problems if some people started > syncing to it without

Re: [time-nuts] NIST UT1 NTP server results

2016-07-22 Thread Bob Camp
Hi There have been a number of “unusual” NTP servers running over the years. The whole “how do we handle leap seconds” thing resulted in a lot of variation. Simple answer is still the same: Only connect to servers that you have checked out. Bob > On Jul 22, 2016, at 6:23 PM, John Hawkinson

Re: [time-nuts] NIST UT1 NTP server results

2016-07-22 Thread Majdi S. Abbas
On Fri, Jul 22, 2016 at 06:23:07PM -0400, John Hawkinson wrote: > With respect to interpolation and soforth, it seems like a lot of NTP > cares more about frequency than offset, and all this stepping presumably > wreaks havoc with the frequency? Maybe I'm wrong though... While fudging the

Re: [time-nuts] NIST UT1 NTP server results

2016-07-22 Thread John Hawkinson
I have to wonder if it's really such a great idea to have this as an open NTP server without huge red flags that it is not UTC. One could imagine it leading to big problems if some people started syncing to it without undersatnding that it was. Has there been thought to at least setting the

Re: [time-nuts] NIST UT1 NTP server results

2016-07-22 Thread Tom Van Baak
Hi Mike, A direct reply from Judah to the list: > > Hello, > Following a discussion with Felicitas Arias and a number of others, > I have removed the registration requirement for the ut1 time server. It > is now open access. Enjoy. Note the usual limitation -- no more than 3 > requests in

[time-nuts] NIST UT1 NTP server results

2016-07-22 Thread Mike Cook
I have started a new thread for this just in case anyone wants to comment and added a link to the stats plot as the png got removed from the first post. This really has more to do with timescale distribution rather than leap seconds but the fact that NIST put together a UT1 NTP server in the