[LEAPSECS] current / future state of UT1 access?

Rob Seaman seaman at lpl.arizona.edu
Tue Mar 20 15:03:56 EDT 2018


Hi all,

I have no explanation for the behavior attempting to connect to the NIST
UT1 server from the University of Arizona. Other servers in that rack
are accessible from this end, and the host itself is reachable:


    # traceroute 128.138.140.50
        ...
    22  phys-engr.colorado.edu (128.138.81.35)  122.026 ms *  112.765 ms
    23  ut1-time.colorado.edu (128.138.140.50)  64.843 ms  64.229 ms 
    64.087 ms

The NTP servers Judah mentions at WWV are not reachable from this end,
however:


    # traceroute 132.163.97.1
        ...
    15  * 65.154.0.170 (65.154.0.170)  26.693 ms !X *

and for numbers 2-4:

    # traceroute 132.163.97.2
        ...
    13  65.154.0.170 (65.154.0.170)  27.203 ms  26.721 ms  27.314 ms
    14  * * *
    15  * * *
        ...
    29  * * *
    30  * * *

The "!X" means "communication administratively prohibited", so perhap
University of Arizona IPs are being blacklisted by WWV? At any rate, the
two issues may not be connected. Alternately I would be happy to blame
the issue on our end if the other servers in the UT1 rack weren't
accessible to us:

    $ ntpq -p
         remote           refid      st t when poll reach   delay  
    offset  jitter
    ==============================================================================
    +india.colorado. .NIST.           1 u  472 1024  373   64.233  
    -0.220   0.379
    *utcnist2.colora .NIST.           1 u  405 1024  377   64.286   
    0.131   0.246
     ut1-time.colora .INIT.          16 u    - 1024    0    0.000   
    0.000   0.000
     time-a-wwv.nist .INIT.          16 u    - 1024    0    0.000   
    0.000   0.000
     time-b-wwv.nist .INIT.          16 u    - 1024    0    0.000   
    0.000   0.000
     time-c-wwv.nist .INIT.          16 u    - 1024    0    0.000   
    0.000   0.000
     time-d-wwv.nist .INIT.          16 u    - 1024    0    0.000   
    0.000   0.000

where

    server 128.138.140.44 minpoll 10 maxpoll 10
    server 128.138.141.172 minpoll 10 maxpoll 10
    server 128.138.140.50 minpoll 10 maxpoll 10 noselect
    server 132.163.97.1 minpoll 10 maxpoll 10
    server 132.163.97.2 minpoll 10 maxpoll 10
    server 132.163.97.3 minpoll 10 maxpoll 10
    server 132.163.97.4 minpoll 10 maxpoll 10


By all means tell me what I'm doing wrong other than the obvious
(temporary) oversubscription to the NIST servers. On campus we use the
campus NTP pool. At the telescopes we use local GNSS reference clocks
(for NTP as well as IRIG time capture) since the network traverses an
unreliable and asymmetric radio link.

At this point the exercise is pure curiosity regarding the utility and
scalability of future remote UT1 NTP services. Those who want to argue
that UTC ought be degraded or eliminated as an approximation to UT1
might first build NTP capacity for a replacement that is not necessary
now, but would be critical to various communities later.

Best,

Rob
--

On 3/20/18 11:18 AM, Tom Van Baak wrote:
> Reply from Judah below:
> /tvb
>
> ----- Original Message ----- 
> From: Levine, Judah Dr. (Fed) 
> Sent: Tuesday, March 20, 2018 6:49 AM
> Subject: Re: [Non-DoD Source] Re: [LEAPSECS] current / future state of UT1 access?
>
>
> Dear colleagues,
>    The current UT1 time server has 550 users and is receiving about 10 requests per second. These are both extremely small numbers compared to my other servers. I cannot explain Rob Seaman’s experience. I routinely monitor all of the servers and do not see this problem. I have not received any other complaints about the service. 
>   In spite of all of this, there is no difficulty in adding a second UT1 time server at another location. From my perspective, the easiest solution would be to add the second UT1 server at WWV. The IP address of the new server would be 132.163.97.x. There are already 4 servers at this site with addresses 132.163.97.1-4, and I encourage the community to verify that these servers are available from a network perspective. 
>
>
> Judah Levine
>
>
>
>
>
> On: 19 March 2018 11:33, "Matsakis, Demetrios N CIV NAVOBSY, N3TS" <demetrios.matsakis at navy.mil> wrote:
>
> FYI.
>
> If you wish me to relay a message to this group, I'd be willing to.
> ________________________________
> From: LEAPSECS [leapsecs-bounces at leapsecond.com] on behalf of Rob Seaman [seaman at lpl.arizona.edu]
> Sent: Monday, March 19, 2018 1:30 PM
> To: leapsecs at leapsecond.com
> Subject: [Non-DoD Source] Re: [LEAPSECS] current / future state of UT1 access?
>
>
> I appreciate the feedback from everybody on the UT1 NTP issue. I have yet to successfully connect from campus and possibly Martin's comment applies since there are a lot of telescopes and astronomers here working for several observatories. Somebody else on this end may be bogarting the NIST UT1 (though we get through fine to their UTC servers).
>
> The issue has come up now since a colleague asked about best practices for access to UT1. In the mean time he's implemented yet another internet retrieval of Bulletin A. Perhaps it needs to be stressed again, astronomers require access to both Universal Time and Atomic Time.
>
> The NIST UT1 server is not currently useful for our purposes. Perhaps a UT1 pool will make sense at some point? If the NIST servers are all loaded "sky high", is there any plan to mitigate this through data center / networking best practices? We have seen their other servers' reach faltering at this end, too.
>
> Thanks!
>
> Rob
>
> --
>
>
> On 3/19/18 7:43 AM, Martin Burnicki wrote:
>
> Please note you need to take care if you have several nodes behind a NAT
> router that poll the same server. From the server's point of view it
> looks like all the requests from the nodes behind the router seem to
> come from the same (public) IP address, so a particular node on the NAT
> subnet may receive even less replies.
>
> On 3/19/18 9:48 AM, Poul-Henning Kamp wrote:
>
> You can simply test this if you run "ntpdate -d -p1 <hostname>"
> repeatedly. When I try this for a NIST server here from Germany I only
> receive a reply occasionally, and in most cases I don't.
>
>
> Last I heard about it, the packet load on the NIST servers were
> sky high so I am not the least surprised...
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20180320/9a036dce/attachment-0001.html>


More information about the LEAPSECS mailing list