On 2021-06-26, David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 26/06/2021 00:12, William Unruh wrote:
>> Not at all sure what you are suggesting. DNS is a way of translating
>> names to IP addresses, which your machine MUST use to talk to a remote
>
> As already noted, there is no MUST about it. I'd put it as low as MAY,
> and it is definitely no more than SHOULD.

Sorry, I forgot the caveate, that you are using machine names, not IP
addresses, and MUST if you are using the pool.

>
>> machine not on your network. The remote machine has nothing to do with
>
> DNS can be used for local network machines, as well, and this is very
> common.
>
>> this. Now some remote machines will as for the name associated with the
>> IP address of machines sending the remote machine a query, to try to see
>> if someone is spoofing the IP address, but as far as I know ntpd does
>> not do that. Takes too much time and would make the time responses
>> really bad.
>
> ntpd doesn't care about who is sending it a query, and, in any case
> reverse DNS lookups often provide bad results, which won't match the
> preferred forward lookup, in the real world.

That does not mean that people do not still use reverse lookup.

On 2021-06-26, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> William Unruh <unruh@invalid.ca> wrote:
>> On 2021-06-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>>> chris <chris-nospam@tridac.net> wrote:
>>>> On 06/25/21 17:28, Jim Pennino wrote:
>>>
>> ...
>>>
>>> Actually what I plan to do is to put a $14 USB GPS on the machine that
>>> already has a PPS GPS attached and do away with ALL external machines.
>>>
>>> If there are two GPS receivers attached to the machine I have a backup
>>> if one receiver fails.
>>
>> Two is in general bad, because your machine has no idea which the better
>> one is and is likely to pick the GPS ratehr than the PPS.
>
> It will pick the one with PPS as the jitter is much better.
>
> Tested and verified.
>
>>> As GPS receivers are highly unlikely to fail in some wonky mode, e.g. time
>>> being off by some large amount, but to fail completely, there is no need
>>> for any other reference source while I replace the failed receiver.
>>
>> Since both are attached to the same machine, the probability of common
>> mode errors become high. The cleaner unpluggin the line which feeds both
>> receivers, etc.
>
> Common mode errors from what?

The cleaners coming in and pluggin their highly noisy machines into the
same plug as that computer. Someone unlugging the machine, or unplugging
the network cable. A power outage in the building, or a network outage,
etc.

>
> The GPS receivers connect to separte ports on different interal busses.
>
>>> Now if there is a Carrington-class coronal mass ejection or WWIII
>>> breaks out, I will lose all time references but I will have lots of
>>> other things to worry about that are much more important than the
>>> computer clock and it is likely that all internet access will also be
>>> down.
>>
>> That of course is a very very general common mode error, and is
>> extremely hard to counteract. More likely are those in your office, on
>> your floor, or in your building.
>
> The last time there was a Carrington-class coronal mass ejection that
> hit the Earth was 1859.

Yes, and the whole of the eastern US was shut down for three days
because of a much smaller ejection pulse hitting northern Quebec. Or
because of a heat wave causing the wires from a electrical generator to
sag and short out and blacking out the whole of NY. Ant those in the
last few decades, not centuries.

>
>>>
>>> Then on two other machines I attach two $14 USB GPS receivers and no
>>> external references.
>>
>> Remember pps is a factor of about 10000 more accurate than than NMEA
>> GPS.
>
> Yeah, so?
>
> How many times do I have to say I DO HAVE A GPS WITH REAL PPS?
>
>>> These three machines then provide time for all other machines on my
>>> network. The three machines will provide the redundancy needed for when
>>> one of those machines gets rebooted for updates/upgrades.
>>
>> Again, make sure they are all on separate electrical circuits,
>> prefereably also in separate buildings.
>
> Why?
>
> This is a hobby, not the New York Stock exchange.
>
>>> Done.
>>>
>>> The only foreseeable change to that I might ever make is if and when USB
>>> 3.0 GPS receivers with PPS become cheap and available, I might swap out
>>> the USB receivers with one of those just to see how well they work.
>>
>> The usb level is irrelevant. It is the PPS that is important. And pps
>> receivers are also coming down. In fact that UBLOCK probably has a PPS
>> output, which the manufacturer never bothered to hook upon the puck.
>> It is hard to feed ppd over usb with any accuracy. However a separate
>> pps line which you can attach to some irq line on the computer is
>> probably possible even for that cheap puck.
>
> Sigh, the USB level is highly relevant.
>
> There is nowhere in USB 2 interface to "hook up" a PPS signal.
>
> As USB does not have any lines other than serial data, any PPS signal
> would have to be emulated in the interface as two virtual serial ports
> and basically you can not do that with USB 2.
>
> With USB 3 you CAN have multiple virtual serial ports.
>
> Also, USB 3 is orders of magnitude faster than USB 2, which means the
> latency and jitter of the signals is much better.
>
>>> Yes, this scheme only gets my machines to within 10s of milliseconds to
>>> the actual time, but that is good enough for me.
>>>
>>> If I needed better, I would buy one of the $685 GPS GNSS Disciplined
>>> Rubidium clocks off ebay and get time to the nanosecond.
>>
>> There is still a wide gap between namosecond and 10s of milliseconds.
>> "If walking is too slow, I can always buy a X15 to get there." Actually
>> the difference there is far less than the difference between ns and msec.
>
>

William Unruh <unruh@invalid.ca> wrote:
> On 2021-06-26, Jim Pennino <jimp@gonzo.specsol.net> wrote:

<snip old stuff>

>> Common mode errors from what?
>
> The cleaners coming in and pluggin their highly noisy machines into the
> same plug as that computer. Someone unlugging the machine, or unplugging
> the network cable. A power outage in the building, or a network outage,
> etc.

If there is a power outage nothing works after the UPS runs out of
battery so it is a don't care for the GPS receivers.

Unplugging the network cable would have no effect on the GPS receivers.

A network outage would have no effect on the GPS receivers.

Since all this stuff is in my house, the rest of the stuff is a don't
care also.

<snip>

>> The last time there was a Carrington-class coronal mass ejection that
>> hit the Earth was 1859.
>
> Yes, and the whole of the eastern US was shut down for three days
> because of a much smaller ejection pulse hitting northern Quebec. Or
> because of a heat wave causing the wires from a electrical generator to
> sag and short out and blacking out the whole of NY. Ant those in the
> last few decades, not centuries.

And again, if there is a power outage nothing works after the UPS runs
out of battery so it is a don't care for the GPS receivers.

How about a zombie apocalypse, alien invasion, 10 mile diameter asteroid
hitting the Earth, 9.0 earthquake?

And yet again, if there is some sort of catastrophe, the accuracy of
computer clocks is going to be WAY down on my list of things to worry
about.

William Unruh <unruh@invalid.ca> wrote:
> On 2021-06-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:

<snip old stuff>

>> If a program has an IP address, as in put the IP address in ntp.conf,
>> then the program already has the IP address and does NOT need to do a
>> DNS query ever.
>
> Apparently I was not clear. Some systems are set up to do an inverse
> DNS, to see if the source of the packet really is the machine it claims
> to be, or is from a site that they want to allow in.

1. This has nothing to do with DNS queries from your systemi, i.e.
looking up the FQDNs in ntp.conf.
2. The ntp program does not do reverse lookups of network clients.

>> Using a IP address for ntp pools is a bad idea as someone else has said.
>
> ntp pool is a "DNS" that shoves out addresses-- semi randomized from the
> pool list. If you have the address, then you can use that. Now, that
> puts a burden on the person who is supplying that pool server, in that
> your requests always hit that particular server. Does this matter for
> one person? No. Does it matter if everyone starts doing it-- yes.
> Also, people can drop their servers out of, and into the pool without
> warning, and thus hardcoding the IP can leave you high and dry.
> However, If DNS is a problem for someone, using hard coded IP is a way
> out of the problem.

The ntp pools are FQDNs in the DNS servers for the domains of the DNS
servers. The address the server provides is rotated.

Using an IP address for a pool member compromises the load spreading of
the DNS address rotation.

I DNS is a problem, ALL network access is problematic.

<snip>

>> 1. I have a ntp server with a real PPS GPS attached which is good to
>> microseconds.
>
> Fine, except that still leaves you reliant on one machine.

How many times do I have to say I have THREE machines with an attached
GPS?

<snip>

>> As each will go into a separate plug, that is HIGHLY unlikely to happen.
>
> The plugs are not the problem. Those plugs, I assume, are all attached
> to the same machine, with the same CPU(s). Interrupt conflicts are thus
> possible, not matter how many plugs there are.
>
> Note again, that interrupt conflict is a problem at microsecond
> accuracy. At millisecond, it is not (unless someone coded ntpd really
> really badly). So this is for you curiosity, not for your need.

Before you say anything else, I HIGHLY suggest that you read:
https://en.wikipedia.org/wiki/USB

If what you said were true, nothing connected to USB would work worth a
crap.

The coding of ntp has NOTHING to do with interrupts, rather it relies on
the attached interface, be it serial, USB, ethernet, or WiFi.

If you are trying to run ntp on a home made computer based on a 8008
chip running CPM, you might have interrupt issues...

>> I never said anything about hanging three receivers on one machine,
>> as two receivers are more than sufficient for normal, i.e. WWIII isn't
>> happening, times.
>
> Two receivers can also produce interrupt conflicts. Again, microsecond,
> not millisecond.

Not bloody likely. See https://en.wikipedia.org/wiki/USB

<snip>

>> At one place I worked at where the computer room was in the basement and
>> they did care about accurate time, they bought a commercial ntp server
>> black box that cost several thousands of dollars and ran a cable to the
>> roof for the antenna.
>
> No idea why they would need a thousands of dollar box. On the other
> hand, if the roof is 5 stories up (50m up), that a microsecond delay in
> the antenna signal getting to the box.

1. At that time a commercial quality black box ntp server cost thousands
of dollars. Today they cost hundreds of dollars.

2. The building was 3 stories but irrelevent as the top of a building
does not change in height nor coax in length and a constant delay is
trivial to calibrate out.

<snip remaining>