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.c...@sfr.fr> a écrit : > > >> Le 23 juil. 2016 à 00:23, John Hawkinson <jh...@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... >> >> --jh...@mit.edu >> John Hawkinson >> >> Tom Van Baak <t...@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.
