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 first place is tightly connected to the leap second controversy. So I have also published this over at the leap second list and prefer that any follow up is done over there. I am a rubbery seconds supporter myself. It is about time we realized that humans are not machines and like the idea of 86400 second days from here to the end of time. There is of course a need for precise SI time intervals and a time scale to go with, but that can be distributed alongside an 86400sec day UTC. The techno exists, we just need the will to say that we humans take precedence. UT1 rules. I’ll jump down from my drum and share some data which I have not seen here before. As most of you will already be aware, one of the results of the never-ending arguments about what to do with leap seconds, was that the IERS agreed to make available electronically UT1-UTC deltas with much greater precision than the GPS stream does (0.1 sec resolution). AFIK we don’t have that yet, but at the beginning of June 2015, Judah Levine at NIST announced that NIST would be distributing high resolution UT1 in NTP frames . See < http://www.nist.gov/pml/div688/grp40/ut1_ntp_description.cfm <http://www.nist.gov/pml/div688/grp40/ut1_ntp_description.cfm>>. As you can see from the document, the service was available to registered users with static IP addresses. My ISP only hands these out for $$$s so I registered with some of the cheaper VPN providers ones to test out the service over VPN links. Unfortunately there were such severe latency and jitter issues with all of those that I tried, that I abandoned my tests in August 2015. I also think I unfortunately pissed off Judah with my repeated requests for IP address registration as he stopped responding to mails. Sorry for that Judah if you are looking in. Anyway I forgot all about it until the other day when I was looking at the peerstat data of the server I was using for the tests and discovered that the UT1 server was alive and responding over my unregistered IP with half the latency and usec level jitter. Luckily I had left the address in place in my ntp.conf with noselect option. Here is the ntpq -pn data. mike@cubieez2:~/NIST_UT1_server_data$ ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== +192.168.1.23 .GPS. 1 u 61 64 377 0.173 -0.014 0.024 128.138.140.50 .NIST. 1 u 41 64 377 130.670 -225.01 0.102 You will also note from the NIST document and the NIST time server address links, that the UT1 NTP service will not respond to unregistered requests. NIST may or may not have opened the box deliberately. I don’t know, but if you wish to use the service please at least contact Judah before doing so. It would be a shame to have it going deaf. Anyway, here are the results from the data I collected. I have graphed the UT1 server offsets reported by the NTP peerstats data over the last 20 days and also the observed UT1-UTC deltas from IERS Bulletin A and the predicted UT1-UTC deltas for the same period from Bulletin A. See it at < http://stratum1.ddns.net:8080/timenuts-data/peerstats17677_128.138.140.50.png > As you can see, there is a systematic offset from the observed values reported in Bulletin A but the served value appears to track the predictions rather than the observed values. The resolution is much better than the 0.1s available via GPS but as the UT1 time is constant over the 24h day, it is not good enough to make a rubbery seconds clock. We need some interpolation. The 13/14th of July something strange was going on. I was not monitoring this system at the time and have no idea what it was. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw

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 any 5 second period from any single ip address. > The current algorithm on the server uses the UT1 offset from > Circular A with no interpolation. The value changes at 0 UTC every day. > I did not use any interpolation because the difference in the dUT1 > value from one day to the next is on the order of 1-2 ms, and I > considered that it was likely that the jitter and asymmetry of the > network connection to a typical user would limit the accuracy to a > larger value anyway so that interpolation would not actually improve > anything. However, I will certainly consider changing this. It would not > be a big deal to add interpolation if there were some good reason for > doing so. > > Best wishes, > > Judah Levine > /tvb

   The current algorithm on the server uses the UT1 offset from

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 reference ID to 'UT1' instead of 'NIST' (or maybe 'NUT1' since 'NIST-UT1' is too long?). 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... --jhawk@mit.edu John Hawkinson Tom Van Baak <tvb@LeapSecond.com> wrote on Fri, 22 Jul 2016 at 15:14:26 -0700 in <60BA6696E49A4C4FA9F6B5792176F81A@pc52>: > > The current algorithm on the server uses the UT1 offset from > > Circular A with no interpolation. The value changes at 0 UTC every day. > > I did not use any interpolation because the difference in the dUT1 > > value from one day to the next is on the order of 1-2 ms, and I > > considered that it was likely that the jitter and asymmetry of the > > network connection to a typical user would limit the accuracy to a > > larger value anyway so that interpolation would not actually improve > > anything. However, I will certainly consider changing this. It would not > > be a big deal to add interpolation if there were some good reason for > > doing so. > > > > Best wishes, > > > > Judah Levine

While fudging the reference ID would be nice, I don't think 

As for the frequency loop, even in well conditioned datacenter

--msa

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 reference ID would be nice, I don't think anyone is going to find this server without looking hard for it. Even if they did, they should be running multiple upstream reference clocks, and should filter out the shift pretty easily. As for the frequency loop, even in well conditioned datacenter environments there's a noticable diurnal shift in temperature, and the resulting shift in clock frequency. Your average PC clock is so bad, that I doubt running it against a UT1 server is terribly noticable. The rise of alternative schedulers, SMP, and cheap commodity hardware make for some jittery system clocks indeed. The daily shift in the provided time is well in that noise level. --msa

  The current algorithm on the server uses the UT1 offset from

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 <jhawk@MIT.EDU> wrote: > > 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 reference ID to 'UT1' > instead of 'NIST' (or maybe 'NUT1' since 'NIST-UT1' is too long?). > > > 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... > > --jhawk@mit.edu > John Hawkinson > > Tom Van Baak <tvb@LeapSecond.com> wrote on Fri, 22 Jul 2016 > at 15:14:26 -0700 in <60BA6696E49A4C4FA9F6B5792176F81A@pc52>: > > >>> The current algorithm on the server uses the UT1 offset from >>> Circular A with no interpolation. The value changes at 0 UTC every day. >>> I did not use any interpolation because the difference in the dUT1 >>> value from one day to the next is on the order of 1-2 ms, and I >>> considered that it was likely that the jitter and asymmetry of the >>> network connection to a typical user would limit the accuracy to a >>> larger value anyway so that interpolation would not actually improve >>> anything. However, I will certainly consider changing this. It would not >>> be a big deal to add interpolation if there were some good reason for >>> doing so. >>> >>> Best wishes, >>> >>> Judah Levine > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

  The current algorithm on the server uses the UT1 offset from

> Le 23 juil. 2016 à 00:23, John Hawkinson <jhawk@mit.edu> 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 undersatnding that it was. I think that it would get rejected as a falseticker in most circumstances. Worth looking at. I have just started an NTP client with just that server as a source.. The GPS based source is configured noselect. Sat Jul 23 01:00:27 CEST 2016 remote refid st t when poll reach delay offset jitter ============================================================================== 192.168.1.23 .GPS. 1 u 15 16 377 0.837 70.330 39.176 128.138.140.50 .NIST. 1 u 12 16 377 130.662 -153.05 35.809 Sat Jul 23 01:01:31 CEST 2016 remote refid st t when poll reach delay offset jitter ============================================================================== 192.168.1.23 .GPS. 1 u 7 16 377 0.825 106.345 40.264 128.138.140.50 .NIST. 1 u 12 16 377 130.652 -121.03 35.812 The system clock offset is slowly converging on the UT1 server. more later. > > Has there been thought to at least setting the reference ID to 'UT1' > instead of 'NIST' (or maybe 'NUT1' since 'NIST-UT1' is too long?). > I would prefer UT1 > > 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... > > --jhawk@mit.edu > John Hawkinson > > Tom Van Baak <tvb@LeapSecond.com> wrote on Fri, 22 Jul 2016 > at 15:14:26 -0700 in <60BA6696E49A4C4FA9F6B5792176F81A@pc52>: > > >>> The current algorithm on the server uses the UT1 offset from >>> Circular A with no interpolation. The value changes at 0 UTC every day. >>> I did not use any interpolation because the difference in the dUT1 >>> value from one day to the next is on the order of 1-2 ms, and I >>> considered that it was likely that the jitter and asymmetry of the >>> network connection to a typical user would limit the accuracy to a >>> larger value anyway so that interpolation would not actually improve >>> anything. However, I will certainly consider changing this. It would not >>> be a big deal to add interpolation if there were some good reason for >>> doing so. >>> >>> Best wishes, >>> >>> Judah Levine > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw

 The current algorithm on the server uses the UT1 offset from

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 doesn’t provoke a step. I don’t have too many data points but attach here a plot of the 0h transition last night. Note that the the x-axis has the seconds scaled as a percentage of the number of secs in a day as I couldn’t figure out how to do it otherwise. Have a good weekend, Mike > Le 23 juil. 2016 à 01:21, Mike Cook <michael.cook@sfr.fr> a écrit : > > >> Le 23 juil. 2016 à 00:23, John Hawkinson <jhawk@mit.edu> 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 undersatnding that it was. > > I think that it would get rejected as a falseticker in most circumstances. > Worth looking at. > > I have just started an NTP client with just that server as a source.. The GPS based source is configured noselect. > > Sat Jul 23 01:00:27 CEST 2016 > remote refid st t when poll reach delay offset jitter > ============================================================================== > 192.168.1.23 .GPS. 1 u 15 16 377 0.837 70.330 39.176 > 128.138.140.50 .NIST. 1 u 12 16 377 130.662 -153.05 35.809 > Sat Jul 23 01:01:31 CEST 2016 > remote refid st t when poll reach delay offset jitter > ============================================================================== > 192.168.1.23 .GPS. 1 u 7 16 377 0.825 106.345 40.264 > 128.138.140.50 .NIST. 1 u 12 16 377 130.652 -121.03 35.812 > > The system clock offset is slowly converging on the UT1 server. > > more later. > >> >> Has there been thought to at least setting the reference ID to 'UT1' >> instead of 'NIST' (or maybe 'NUT1' since 'NIST-UT1' is too long?). >> > I would prefer UT1 >> >> 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... >> >> --jhawk@mit.edu >> John Hawkinson >> >> Tom Van Baak <tvb@LeapSecond.com> wrote on Fri, 22 Jul 2016 >> at 15:14:26 -0700 in <60BA6696E49A4C4FA9F6B5792176F81A@pc52>: >> >> >>>> The current algorithm on the server uses the UT1 offset from >>>> Circular A with no interpolation. The value changes at 0 UTC every day. >>>> I did not use any interpolation because the difference in the dUT1 >>>> value from one day to the next is on the order of 1-2 ms, and I >>>> considered that it was likely that the jitter and asymmetry of the >>>> network connection to a typical user would limit the accuracy to a >>>> larger value anyway so that interpolation would not actually improve >>>> anything. However, I will certainly consider changing this. It would not >>>> be a big deal to add interpolation if there were some good reason for >>>> doing so. >>>> >>>> Best wishes, >>>> >>>> Judah Levine >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > "The power of accurate observation is commonly called cynicism by those who have not got it. » > George Bernard Shaw > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw

The current algorithm on the server uses the UT1 offset from

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 <michael.cook@sfr.fr> wrote: > > 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 doesn’t provoke a step. > > I don’t have too many data points but attach here a plot of the 0h transition last night. > Note that the the x-axis has the seconds scaled as a percentage of the number of secs in a day as I couldn’t figure out how to do it otherwise. > > > > > > Have a good weekend, > Mike > > >> Le 23 juil. 2016 à 01:21, Mike Cook <michael.cook@sfr.fr> a écrit : >> >> >>> Le 23 juil. 2016 à 00:23, John Hawkinson <jhawk@mit.edu> 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 undersatnding that it was. >> >> I think that it would get rejected as a falseticker in most circumstances. >> Worth looking at. >> >> I have just started an NTP client with just that server as a source.. The GPS based source is configured noselect. >> >> Sat Jul 23 01:00:27 CEST 2016 >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 192.168.1.23 .GPS. 1 u 15 16 377 0.837 70.330 39.176 >> 128.138.140.50 .NIST. 1 u 12 16 377 130.662 -153.05 35.809 >> Sat Jul 23 01:01:31 CEST 2016 >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 192.168.1.23 .GPS. 1 u 7 16 377 0.825 106.345 40.264 >> 128.138.140.50 .NIST. 1 u 12 16 377 130.652 -121.03 35.812 >> >> The system clock offset is slowly converging on the UT1 server. >> >> more later. >> >>> >>> Has there been thought to at least setting the reference ID to 'UT1' >>> instead of 'NIST' (or maybe 'NUT1' since 'NIST-UT1' is too long?). >>> >> I would prefer UT1 >>> >>> 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... >>> >>> --jhawk@mit.edu >>> John Hawkinson >>> >>> Tom Van Baak <tvb@LeapSecond.com> wrote on Fri, 22 Jul 2016 >>> at 15:14:26 -0700 in <60BA6696E49A4C4FA9F6B5792176F81A@pc52>: >>> >>> >>>>> The current algorithm on the server uses the UT1 offset from >>>>> Circular A with no interpolation. The value changes at 0 UTC every day. >>>>> I did not use any interpolation because the difference in the dUT1 >>>>> value from one day to the next is on the order of 1-2 ms, and I >>>>> considered that it was likely that the jitter and asymmetry of the >>>>> network connection to a typical user would limit the accuracy to a >>>>> larger value anyway so that interpolation would not actually improve >>>>> anything. However, I will certainly consider changing this. It would not >>>>> be a big deal to add interpolation if there were some good reason for >>>>> doing so. >>>>> >>>>> Best wishes, >>>>> >>>>> Judah Levine >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> >> "The power of accurate observation is commonly called cynicism by those who have not got it. » >> George Bernard Shaw >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > "The power of accurate observation is commonly called cynicism by those who have not got it. » > George Bernard Shaw > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

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. UT2 was the standard in the CCIR recommendations for radio broadcasts before UTC with leap seconds (and in fact it was specified as the underlying time scale in the first version of the CCIR leap second document) specifically because it was smoother than UT1 over the course of a year. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

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 > On Jul 23, 2016, at 11:52 AM, Steve Allen <sla@ucolick.org> wrote: > > 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. > > UT2 was the standard in the CCIR recommendations for radio broadcasts > before UTC with leap seconds (and in fact it was specified as the > underlying time scale in the first version of the CCIR leap second > document) specifically because it was smoother than UT1 over the > course of a year. > > -- > Steve Allen <sla@ucolick.org> WGS-84 (GPS) > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 > 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.