[HECnet] A USNO GPS network time server is now in operation at Digital Equipment Corporation, Palo Alto, CA

[Peter Lothberg]

W have stratum-1 server on our UTC timescale in Stockholm, it's 
8 * 10GE and all the NTP processing is done in the FPGA that also is the 
Ethernet MAC. 

-P 

> From: "tommytimesharing" <tommytimesharing at gmail.com>
> To: "hecnet" <hecnet at Update.UU.SE>
> Sent: Thursday, November 25, 2021 3:29:18 PM
> Subject: Re: [HECnet] A USNO GPS network time server is now in operation at
> Digital Equipment Corporation, Palo Alto, CA

> Oh... Well, what's a 'whoops' between hackers? (the good olde fashioned kind)

> I went to the web page and, of course, understood the working solution to put
> the 'disappeared' host names into the /etc/hosts . That's a standard thing to
> do on Windows and any Unix flavor I can think of. Personally, I think it is a
> win. The one place where you can't do it as easily is on a PANDA Tops-20
> distribution, which will check the domain first and wait for that resolve to
> time out before checking the local hosts file ( SYSTEM:HOSTS.TXT ).

> So that means you have to wait for the time out, which, whatever duration that
> happens to be is far too long for me. It's quite infuriating, actually. SYSTAT
> immediately knows, yet finger appears to hang and mail delivery slows to a
> crawl. You can't know how to remediate unless you happen to be familiar with
> the source code. Humph...

> Avoiding the time out means you have to put whatever host you want into the
> domain files, the format of which is both arcane and poorly documented. And
> then whack the resolver. Now you have two files to keep in sync. That was one
> argument that I never won with MRC as having it the other way around seemed to
> me to be easiest for everyone.

> I finally edited my local copy of HSTNAM to not drive me crazy and also gave
> DECnet hosts priority, which then turned up a gap in Tops-20. HSTNAM really
> wants the node number, even though the average user can't do a blessed thing
> with it. If it doesn't get a number, then it...well, makes something up. Of
> course, fixing all this broke something else in MMAILR, which is another rabbit
> hole I have yet to get myself out of.

> This all being said, would the correct assumption be that HP is looking to pull
> its Stratum-1 server or just cut down traffic? I can't remember where I read
> this, but apparently Stratum-1 servers get a lot of traffic, so maybe HP didn't
> want to burn that bandwidth any more. Or...?

>> On 11/25/21 7:39 AM, David Moylan wrote:

>> This is my fault. I checked that NTP was running on 204.123.2.72 and then just
>> googled it to find the name.

>> I found a hit on a page on ntp.org with the name usno.hpl.hp.com and just
>> assumed it was valid.

>> Turns out it has no name. This was a Stratum 1 server originally, but the page
>> found by google is not actively linked on the official ntp.org.list

>> This appears to have happened in more recent times. I can find references to it
>> from 2019 where it appears it may have been in the process of being phased out.

>> [ https://mm.icann.org/pipermail/tz/2019-July/028303.html |
>> https://mm.icann.org/pipermail/tz/2019-July/028303.html ]

>> cheers, Wiz!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211125/17c6df2c/attachment-0001.htm>