Hi, Some first tests of the NIST UT1 service recently announced. Forwarded comms with Judah Levine. I’d be interested to hear the experiences of others . Regards, Mike
> Début du message réexpédié : > > De: Mike Cook <michael.c...@sfr.fr> > Objet: NIST UT1 time service > Date: 21 juillet 2015 20:23:25 UTC+2 > À: ju...@jilau1.colorado.edu > > Judah, > First impressions: > Yesterday evening I started monitoring the server with ntpd , configuring it > with the « no select » directive to prevent ntpd using it as a reference. > > The other servers that were configured were all from the NTP pool with > request transiting the same static IP, which is in fact a VPN link. > > I have attached a graph of the offsets reported. It covers from 0h00m00s to > a couple of minutes ago: > > Some comments > The first wiggly bit is recorded with the ntp con as described above. The > servers sync to UTC at the time , being plus or minus 2ms , which could be > related to the very long poll interval I had configured at the time, and the > fact that I was running the VPN link. So at around 06:26 UTC I reconfigured > the server to use two local GPS sync’d servers. The local offset immediately > reduced to micro-seconds. Even though the delay for the UT1 server was around > 200ms, jitter was low, for example from 08:28 UTC: > > Tue Jul 21 10:28:09 CEST 2015 > remote refid st t when poll reach delay offset jitter > ============================================================================== > +192.168.1.23 .GPS. 1 u 12 64 377 0.410 -0.066 0.006 > 128.138.140.50 .NIST. 1 u 36 64 377 191.606 303.428 0.799 > *192.168.1.4 .PPS1. 1 u 10 64 377 0.630 0.010 0.014 > > As you can see above the reported UTC-UT1 delta is around 303ms and it > remained stable for some time. I had a look at the Bulletin A figures and it > is not far off for the days predicted value, but is nearer that of Jul26. I’d > be interested in knowing what you see locally. > > Around 11:48 UTC the jitter became high : > > Tue Jul 21 13:48:13 CEST 2015 > remote refid st t when poll reach delay offset jitter > ============================================================================== > +192.168.1.23 .GPS. 1 u 62 64 377 0.420 -0.109 0.021 > 128.138.140.50 .NIST. 1 u 48 64 377 201.419 298.414 3.392 > *192.168.1.4 .PPS1. 1 u 11 64 377 0.645 -0.040 0.018 > > I was doing some admin on that system (modifying a python app to send NTP > requests to take ntpd out of the loop) which required some file transfers. > Anyhow, as you can see, the reported offset dropped dramatically and on the > graph you can see that it has stayed unnaturally low. That said, factoring > in the jitter,delay we still have a ballpark figure close to the stable > value. However, not ideal. > > Your server is a long way from me. 155ms via a non VPN link and 200ms over > VPN. That shouldn’t affect things much unless I am getting an asymmetric > path, which is possible. > > Next test will be to so how the offset appears using a non ntpd polling. I’ll > let you know how I get on. > > Regards, > Mike > > PS. If my images don’t pass your firewall, you can check the cubieez2 > peerstats link on <http://stratum1.ddns.net:8080 > <http://stratum1.ddns.net:8080/> > > > > >> Le 20 juil. 2015 à 23:47, Judah Levine <judah.lev...@colorado.edu >> <mailto:judah.lev...@colorado.edu>> a écrit : >> >> Hello, >> Yes, I would be interested to learn what you find. My rough estimate is >> that the accuracy of NTP is typically not better than about 5% of the >> round-trip delay. >> >> Judah Levine >> >> >> On 7/20/2015 3:27 PM, Mike Cook wrote: >>> Thanks Judah, >>> >>> >>>> Le 20 juil. 2015 à 17:25, Judah Levine <judah.lev...@colorado.edu >>>> <mailto:judah.lev...@colorado.edu>> a écrit : >>>> >>>> >>>> Hello, >>>> Your address is registered and should be ready to go. I am sure that you >>>> understand that the accuracy of the time messages will depend on the >>>> stability of the network connection from your system back to Boulder. >>> Yes, that is understood. If you are interested in what I see as a client in >>> my neck of the woods and any comments I may have, I will update you. >>> >>>> I have a number of ideas about the second point, but I have no requests >>>> so far, and I am waiting to see if anybody actually requests that service. >>>> There are a number of questions about the details that I would discuss >>>> with real users. >>> Understandable. >>> >>> Regards, >>> Mike >>> >>>> Best wishes, >>>> >>>> Judah Levine >>>> Time and Frequency Division >>>> NIST Boulder >>>> >>>> >>>> On 7/20/2015 2:09 AM, Mike Cook wrote: >>>>> Hi Judah, >>>>> Could you please register IP 77.78.103.22 for me. Thanks >>>>> I don’t have domain name registered with it at the moment. >>>>> reverse DNS returns >>>>> >>>>> 22.103.78.77.in-addr.arpa name = assigned-77-78-103-22.dc3.cz. >>>>> >>>>> On the second proposed service described in >>>>> <http://www.nist.gov/pml/div688/grp40/ut1_ntp_description.cfm >>>>> <http://www.nist.gov/pml/div688/grp40/ut1_ntp_description.cfm>> I would >>>>> just mention a couple of approaches that you may be aware of already and >>>>> discussed at length by contributors to the leaps...@leapsecs.com >>>>> <mailto:leaps...@leapsecs.com> mailing list with test implementations. >>>>> The threads are somewhat dispersed however. >>>>> >>> "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une >>> petite et provisoire sécurité, ne méritent ni liberté ni sécurité." >>> Benjimin Franklin >> >> -- >> Judah Levine >> JILA >> University of Colorado >> Boulder > > "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une > petite et provisoire sécurité, ne méritent ni liberté ni sécurité." > Benjimin Franklin > "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin _______________________________________________ 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.
