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.
> cheers, Wiz!!