I was checking the stability of a new USB GPS refclock on a server which
is configured to use the GPS, servers from the ntp pool, and another server
of mine that has a PPS GPS receiver.

I noticed that almost all the pool servers had disappeared.

I then checked other machines that use my "good" server and the ntp
pool; most all of the pool servers had also disappeared on those
machines.

This is a mix of PC linux, rasberry pi linux, rasberry pi buster, and
Windows 10 machines with Meinberg, all with the latest ntp from their distros.

Long story short: I realized I had had a network outage and tested the
theory that was the cause. It was.

It seems that any server in ntp.conf that is specified as a name, as
the pool servers are, will after a sufficiently long DNS outage just
disappear and not come back after the outage without restarting ntp.

It would seem to me that ntp should only need to do a DNS lookup on
startup and from then on continue to use the address found.

But that is not how ntp works.

Anyway, the bottom line is that if the pool is your only source of time
and if there is a DNS failure for a sufficiently long time, you will
lilely not have any source of time afterwards.

As for the USB GPS I was testing, it is called a VK-162 G-Mouse
available from Amazon for $14, uses the Windows 10 native driver so it
works with Meinberg ntp, and keeps the time within single digit
milliseconds without any other servers.

On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
....
>
> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
> available from Amazon for $14, uses the Windows 10 native driver so it
> works with Meinberg ntp, and keeps the time within single digit
> milliseconds without any other servers.

Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
after correction for the NMEA delay is probably in the 10s of ms, not
their claimed microsecond. But certainly for most people ms is more than
enough accuracy.

>
>

William Unruh <unruh@invalid.ca> wrote:
> On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> ...
>>
>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>> available from Amazon for $14, uses the Windows 10 native driver so it
>> works with Meinberg ntp, and keeps the time within single digit
>> milliseconds without any other servers.
>
> Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
> after correction for the NMEA delay is probably in the 10s of ms, not
> their claimed microsecond. But certainly for most people ms is more than
> enough accuracy.
>

Correct, no PPS.

From short term (day or so) testing looking at peerstats data:

Samples: 3914
Avg offset: -0.00190137
Std dev: 0.00921412

ntpq typically shows offset and jitter at about 1 and the satellites in
view are usually 14 or more with the puck in a window sill.

That is from a linux PC where there are more tools for testing things.

The reason I bought it is that it is advertised to work with the Windows
native USB driver, which produces a virtual com port, which makes it
usable with Meinberg ntp without any other drivers or software.

I have yet to do any Windows testing other than to verify it does work,
but I see no reason why Windows would be much different.

On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> William Unruh <unruh@invalid.ca> wrote:
>> On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>> ...
>>>
>>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>>> available from Amazon for $14, uses the Windows 10 native driver so it
>>> works with Meinberg ntp, and keeps the time within single digit
>>> milliseconds without any other servers.
>>
>> Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
>> after correction for the NMEA delay is probably in the 10s of ms, not
>> their claimed microsecond. But certainly for most people ms is more than
>> enough accuracy.
>>
>
> Correct, no PPS.
>
> From short term (day or so) testing looking at peerstats data:
>
> Samples: 3914
> Avg offset: -0.00190137
> Std dev: 0.00921412

The problem is that that does not test the accuracy, just jitter. Ie,
the time could be off by a century, but it is repeatable, so ntp says
that the offset and standard deviation is small.
You need to compare with another time source that is known to be more
accurate than yours. Typically nmea signals are delivered late and the
length of the signal is long delaying things still more, expecially if
you choose an nmea sentence which reports lots of information, not just
the time.
>
> ntpq typically shows offset and jitter at about 1 and the satellites in
> view are usually 14 or more with the puck in a window sill.

And that means that the processor in the gps receiver has to work harder
and delays the report of the NMEA even longer. Now of course you may not
care -- 100ms may be perfectly acceptable (It is far more accurate than
a wrist watch for example) and then my comments are entirely irrelevant.
If you want higher accuracy however, then they start to become relevant.
Hook it up to the network and use some of the low stratum sources to get
the time. That should be accurate probably to better than a ms. That
will allow you to calibrate your gps delay and tell ntp to subtract the
persistant offset from the gps signal, and improve your accuracy.

Again that is only important if you have some reason to care. Again, if
accuracy to the nearest second is good enough, ignore this.

>
> That is from a linux PC where there are more tools for testing things.
>
> The reason I bought it is that it is advertised to work with the Windows
> native USB driver, which produces a virtual com port, which makes it
> usable with Meinberg ntp without any other drivers or software.
>
> I have yet to do any Windows testing other than to verify it does work,
> but I see no reason why Windows would be much different.

Probably not. But again, testing it against some good network ntp
sources should give you an idea of how well it is doing, if that is
important.
Of course we all like our stuff to be better than others. My system,
using pps from a gps is probably goot to a few microseconds. Do I need a
few microsecond accuracy. No. Even ms accuracy would be way more than I
need. But I like seeing how far I can push stuff. My only defence is
"its a hobby".

>
>

William Unruh <unruh@invalid.ca> wrote:
> On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>> William Unruh <unruh@invalid.ca> wrote:
>>> On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>>> ...
>>>>
>>>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>>>> available from Amazon for $14, uses the Windows 10 native driver so it
>>>> works with Meinberg ntp, and keeps the time within single digit
>>>> milliseconds without any other servers.
>>>
>>> Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
>>> after correction for the NMEA delay is probably in the 10s of ms, not
>>> their claimed microsecond. But certainly for most people ms is more than
>>> enough accuracy.
>>>
>>
>> Correct, no PPS.
>>
>> From short term (day or so) testing looking at peerstats data:
>>
>> Samples: 3914
>> Avg offset: -0.00190137
>> Std dev: 0.00921412
>
> The problem is that that does not test the accuracy, just jitter. Ie,
> the time could be off by a century, but it is repeatable, so ntp says
> that the offset and standard deviation is small.
> You need to compare with another time source that is known to be more
> accurate than yours. Typically nmea signals are delivered late and the
> length of the signal is long delaying things still more, expecially if
> you choose an nmea sentence which reports lots of information, not just
> the time.

I didn't bother with the full story as I wanted to be brief unless
someone had specific questions.

A bit more detail:

For testing purposes, ntp was configured to use my machine that has a
real PPS GPS and about a half dozen public servers, most of them stratum 1.

I also enabled all the statistics files.

Initial, i.e. an hour or so, testing was with standard linux utilities,
i.e. ntpq, ntpstat, ntptime, for a sanity check and a tweek of the fudge
value, which came out to 0.027.

After several days I ran a pile of sed/awk scripts to look at the
statistics files and came to the conclusion that the absolute time error
was always less than about 5 ms and typically around 1 ms, which for $14 I
condider good enough.

FYI I have tested a several other generic USB GPS pucks and found the
jitter to be over an order of magnitude greater than this device with
fudge times in the order of 0.500 and time errors in the several 10s
of ms.

>>
>> ntpq typically shows offset and jitter at about 1 and the satellites in
>> view are usually 14 or more with the puck in a window sill.
>
> And that means that the processor in the gps receiver has to work harder
> and delays the report of the NMEA even longer. Now of course you may not
> care -- 100ms may be perfectly acceptable (It is far more accurate than
> a wrist watch for example) and then my comments are entirely irrelevant.
> If you want higher accuracy however, then they start to become relevant.
> Hook it up to the network and use some of the low stratum sources to get
> the time. That should be accurate probably to better than a ms. That
> will allow you to calibrate your gps delay and tell ntp to subtract the
> persistant offset from the gps signal, and improve your accuracy.
>
> Again that is only important if you have some reason to care. Again, if
> accuracy to the nearest second is good enough, ignore this.

See above.

I am assuming that the fudge time of 0.027 versus the typical generic GPS
puck time of 0.500 means this thing is processing things much faster.

FYI all this is done on a USB 2.0 interface.

>>
>> That is from a linux PC where there are more tools for testing things.
>>
>> The reason I bought it is that it is advertised to work with the Windows
>> native USB driver, which produces a virtual com port, which makes it
>> usable with Meinberg ntp without any other drivers or software.
>>
>> I have yet to do any Windows testing other than to verify it does work,
>> but I see no reason why Windows would be much different.
>
> Probably not. But again, testing it against some good network ntp
> sources should give you an idea of how well it is doing, if that is
> important.
> Of course we all like our stuff to be better than others. My system,
> using pps from a gps is probably goot to a few microseconds. Do I need a
> few microsecond accuracy. No. Even ms accuracy would be way more than I
> need. But I like seeing how far I can push stuff. My only defence is
> "its a hobby".

From my analysis of my real PPS GPS system, the absolue time on that
machine is typically accurate to about a microsecond with a standard
deviation of about 0.8 us.

The time accuracy I actually need for stuff I do is in the order of
about 50 ms, but like you, I too like seeing how far I can push stuff,
especially for $14.

On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> William Unruh <unruh@invalid.ca> wrote:
>> On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>>> William Unruh <unruh@invalid.ca> wrote:
>>>> On 2021-06-23, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>>>> ...
>>>>>
>>>>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>>>>> available from Amazon for $14, uses the Windows 10 native driver so it
>>>>> works with Meinberg ntp, and keeps the time within single digit
>>>>> milliseconds without any other servers.
>>>>
>>>> Looks like a nice cheap receiver-- no PPS I assume so that accuracy,
>>>> after correction for the NMEA delay is probably in the 10s of ms, not
>>>> their claimed microsecond. But certainly for most people ms is more than
>>>> enough accuracy.
>>>>
>>>
>>> Correct, no PPS.
>>>
>>> From short term (day or so) testing looking at peerstats data:
>>>
>>> Samples: 3914
>>> Avg offset: -0.00190137
>>> Std dev: 0.00921412
>>
>> The problem is that that does not test the accuracy, just jitter. Ie,
>> the time could be off by a century, but it is repeatable, so ntp says
>> that the offset and standard deviation is small.
>> You need to compare with another time source that is known to be more
>> accurate than yours. Typically nmea signals are delivered late and the
>> length of the signal is long delaying things still more, expecially if
>> you choose an nmea sentence which reports lots of information, not just
>> the time.
>
> I didn't bother with the full story as I wanted to be brief unless
> someone had specific questions.
>
> A bit more detail:
>
> For testing purposes, ntp was configured to use my machine that has a
> real PPS GPS and about a half dozen public servers, most of them stratum 1.

OK, sounds good.

>
> I also enabled all the statistics files.
>
> Initial, i.e. an hour or so, testing was with standard linux utilities,
> i.e. ntpq, ntpstat, ntptime, for a sanity check and a tweek of the fudge
> value, which came out to 0.027.

That is fast. Hardly enough time to send the nmea sentence. But it must
be working faster than 9600Bd (serial port speeds).

>
> After several days I ran a pile of sed/awk scripts to look at the
> statistics files and came to the conclusion that the absolute time error
> was always less than about 5 ms and typically around 1 ms, which for $14 I
> condider good enough.
>
> FYI I have tested a several other generic USB GPS pucks and found the
> jitter to be over an order of magnitude greater than this device with
> fudge times in the order of 0.500 and time errors in the several 10s
> of ms.

Yes, that is what I would expect.
>
>>>
>>> ntpq typically shows offset and jitter at about 1 and the satellites in
>>> view are usually 14 or more with the puck in a window sill.
>>
>> And that means that the processor in the gps receiver has to work harder
>> and delays the report of the NMEA even longer. Now of course you may not
>> care -- 100ms may be perfectly acceptable (It is far more accurate than
>> a wrist watch for example) and then my comments are entirely irrelevant.
>> If you want higher accuracy however, then they start to become relevant.
>> Hook it up to the network and use some of the low stratum sources to get
>> the time. That should be accurate probably to better than a ms. That
>> will allow you to calibrate your gps delay and tell ntp to subtract the
>> persistant offset from the gps signal, and improve your accuracy.
>>
>> Again that is only important if you have some reason to care. Again, if
>> accuracy to the nearest second is good enough, ignore this.
>
> See above.
>
> I am assuming that the fudge time of 0.027 versus the typical generic GPS
> puck time of 0.500 means this thing is processing things much faster.
>
> FYI all this is done on a USB 2.0 interface.

Certainly if it used the usb channel at its full speed, that should be
fine. I always thought that gps ran at serial port speeds, but clearly
that is not true.
>
>>>
>>> That is from a linux PC where there are more tools for testing things.
>>>
>>> The reason I bought it is that it is advertised to work with the Windows
>>> native USB driver, which produces a virtual com port, which makes it
>>> usable with Meinberg ntp without any other drivers or software.
>>>
>>> I have yet to do any Windows testing other than to verify it does work,
>>> but I see no reason why Windows would be much different.
>>
>> Probably not. But again, testing it against some good network ntp
>> sources should give you an idea of how well it is doing, if that is
>> important.
>> Of course we all like our stuff to be better than others. My system,
>> using pps from a gps is probably goot to a few microseconds. Do I need a
>> few microsecond accuracy. No. Even ms accuracy would be way more than I
>> need. But I like seeing how far I can push stuff. My only defence is
>> "its a hobby".
>
> From my analysis of my real PPS GPS system, the absolue time on that
> machine is typically accurate to about a microsecond with a standard
> deviation of about 0.8 us.
>
> The time accuracy I actually need for stuff I do is in the order of
> about 50 ms, but like you, I too like seeing how far I can push stuff,
> especially for $14.

Yes, it certainly is impressive.

>
>

William Unruh <unruh@invalid.ca> wrote:

<snip old stuff>

> Certainly if it used the usb channel at its full speed, that should be
> fine. I always thought that gps ran at serial port speeds, but clearly
> that is not true.

Well, stty -F /dev/ACM0, which is where this puck shows up as opposed to
the generic /dev/USB0, says speed 9600 baud.

I know of no way absent some sort of USB break out board and an
oscilloscope to determine if that is actually true.

<snip remaining old stuff>

Jim Pennino <jimp@gonzo.specsol.net> wrote:
> I was checking the stability of a new USB GPS refclock on a server which
> is configured to use the GPS, servers from the ntp pool, and another server
> of mine that has a PPS GPS receiver.
>
> I noticed that almost all the pool servers had disappeared.
>
> I then checked other machines that use my "good" server and the ntp
> pool; most all of the pool servers had also disappeared on those
> machines.
>
> This is a mix of PC linux, rasberry pi linux, rasberry pi buster, and
> Windows 10 machines with Meinberg, all with the latest ntp from their distros.
>
> Long story short: I realized I had had a network outage and tested the
> theory that was the cause. It was.
>
> It seems that any server in ntp.conf that is specified as a name, as
> the pool servers are, will after a sufficiently long DNS outage just
> disappear and not come back after the outage without restarting ntp.
>
> It would seem to me that ntp should only need to do a DNS lookup on
> startup and from then on continue to use the address found.
>
> But that is not how ntp works.
>
> Anyway, the bottom line is that if the pool is your only source of time
> and if there is a DNS failure for a sufficiently long time, you will
> lilely not have any source of time afterwards.
>
> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
> available from Amazon for $14, uses the Windows 10 native driver so it
> works with Meinberg ntp, and keeps the time within single digit
> milliseconds without any other servers.
Further testing shows the following:

I took a machine and ran watch -p -n 10 ntpq -pn to monitor ntp status.

I then pulled the network connection from the machine.

After about 7 minutes the pool servers started to disappear.

If the machine was reconnected to the network within about 15 minutes,
the pool servers would reappear.

If the machine was off the network for more than about 15 minutes, the
pool servers do NOT reappear until ntp is restarted.

On 2021-06-24, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> Jim Pennino <jimp@gonzo.specsol.net> wrote:
>> I was checking the stability of a new USB GPS refclock on a server which
>> is configured to use the GPS, servers from the ntp pool, and another server
>> of mine that has a PPS GPS receiver.
>>
>> I noticed that almost all the pool servers had disappeared.
>>
>> I then checked other machines that use my "good" server and the ntp
>> pool; most all of the pool servers had also disappeared on those
>> machines.
>>
>> This is a mix of PC linux, rasberry pi linux, rasberry pi buster, and
>> Windows 10 machines with Meinberg, all with the latest ntp from their distros.
>>
>> Long story short: I realized I had had a network outage and tested the
>> theory that was the cause. It was.
>>
>> It seems that any server in ntp.conf that is specified as a name, as
>> the pool servers are, will after a sufficiently long DNS outage just
>> disappear and not come back after the outage without restarting ntp.
>>
>> It would seem to me that ntp should only need to do a DNS lookup on
>> startup and from then on continue to use the address found.
>>
>> But that is not how ntp works.
>>
>> Anyway, the bottom line is that if the pool is your only source of time
>> and if there is a DNS failure for a sufficiently long time, you will
>> lilely not have any source of time afterwards.
>>
>> As for the USB GPS I was testing, it is called a VK-162 G-Mouse
>> available from Amazon for $14, uses the Windows 10 native driver so it
>> works with Meinberg ntp, and keeps the time within single digit
>> milliseconds without any other servers.
>
> Further testing shows the following:
>
> I took a machine and ran watch -p -n 10 ntpq -pn to monitor ntp status.
>
> I then pulled the network connection from the machine.
>
> After about 7 minutes the pool servers started to disappear.
>
> If the machine was reconnected to the network within about 15 minutes,
> the pool servers would reappear.
>
> If the machine was off the network for more than about 15 minutes, the
> pool servers do NOT reappear until ntp is restarted.
>

I suspect it is the number of times that ntpd tries to contact the
server and fails rather than the time that is important. You could try
putting the server offline and then online again (I use chrony so do not
remember if ntpd has that option).
>

William Unruh <unruh@invalid.ca> wrote:

<snip old stuff>

> I suspect it is the number of times that ntpd tries to contact the
> server and fails rather than the time that is important. You could try
> putting the server offline and then online again (I use chrony so do not
> remember if ntpd has that option).

No, it doesn't.

On 06/25/21 04:08, Jim Pennino wrote:
> William Unruh<unruh@invalid.ca> wrote:
>
> <snip old stuff>
>
>> I suspect it is the number of times that ntpd tries to contact the
>> server and fails rather than the time that is important. You could try
>> putting the server offline and then online again (I use chrony so do not
>> remember if ntpd has that option).
>
> No, it doesn't.
>

You could use a one line cron script to restart every day, week,
whenever...

chris <chris-nospam@tridac.net> wrote:
> On 06/25/21 04:08, Jim Pennino wrote:
>> William Unruh<unruh@invalid.ca> wrote:
>>
>> <snip old stuff>
>>
>>> I suspect it is the number of times that ntpd tries to contact the
>>> server and fails rather than the time that is important. You could try
>>> putting the server offline and then online again (I use chrony so do not
>>> remember if ntpd has that option).
>>
>> No, it doesn't.
>>
>
> You could use a one line cron script to restart every day, week,
> whenever...

Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a
public server that does not request use of DNS.

On 2021-06-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> chris <chris-nospam@tridac.net> wrote:
>> On 06/25/21 04:08, Jim Pennino wrote:
>>> William Unruh<unruh@invalid.ca> wrote:
>>>
>>> <snip old stuff>
>>>
>>>> I suspect it is the number of times that ntpd tries to contact the
>>>> server and fails rather than the time that is important. You could try
>>>> putting the server offline and then online again (I use chrony so do not
>>>> remember if ntpd has that option).
>>>
>>> No, it doesn't.
>>>
>>
>> You could use a one line cron script to restart every day, week,
>> whenever...
>
> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a
> public server that does not request use of DNS.

You could try specifying the server by IP rather than by name, so DNS is
not needed. Of course this rule out using pool, unless you put them in
by IP. DNS is just used to translate names to IP, so if you use IP, then
DNS is not needed.
>
>

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 04:08, Jim Pennino wrote:
>>>> William Unruh<unruh@invalid.ca> wrote:
>>>>
>>>> <snip old stuff>
>>>>
>>>>> I suspect it is the number of times that ntpd tries to contact the
>>>>> server and fails rather than the time that is important. You could try
>>>>> putting the server offline and then online again (I use chrony so do not
>>>>> remember if ntpd has that option).
>>>>
>>>> No, it doesn't.
>>>>
>>>
>>> You could use a one line cron script to restart every day, week,
>>> whenever...
>>
>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a
>> public server that does not request use of DNS.
>
> You could try specifying the server by IP rather than by name, so DNS is
> not needed. Of course this rule out using pool, unless you put them in
> by IP. DNS is just used to translate names to IP, so if you use IP, then
> DNS is not needed.

Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A
public server that does NOT request use of DNS which yields 3 sources of
time without using a pool or DNS lookups.

Or for $28/machine I could use 2 USB GPS receivers and my machine with
PPS GPS, which also provides 3 sources of time without any network
access at all.

On 06/25/21 17:28, Jim Pennino 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 04:08, Jim Pennino wrote:
>>>>> William Unruh<unruh@invalid.ca> wrote:
>>>>>
>>>>> <snip old stuff>
>>>>>
>>>>>> I suspect it is the number of times that ntpd tries to contact the
>>>>>> server and fails rather than the time that is important. You could try
>>>>>> putting the server offline and then online again (I use chrony so do not
>>>>>> remember if ntpd has that option).
>>>>>
>>>>> No, it doesn't.
>>>>>
>>>>
>>>> You could use a one line cron script to restart every day, week,
>>>> whenever...
>>>
>>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a
>>> public server that does not request use of DNS.
>>
>> You could try specifying the server by IP rather than by name, so DNS is
>> not needed. Of course this rule out using pool, unless you put them in
>> by IP. DNS is just used to translate names to IP, so if you use IP, then
>> DNS is not needed.
>
>
> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A
> public server that does NOT request use of DNS which yields 3 sources of
> time without using a pool or DNS lookups.
>
> Or for $28/machine I could use 2 USB GPS receivers and my machine with
> PPS GPS, which also provides 3 sources of time without any network
> access at all.
>
>

Your choice, but when I registered the ntp server here with the pool, I
just used the fixed ip address. That's what they ask for and it does
bypass dns altogether. The less translation the better, unless
you really need it...

chris <chris-nospam@tridac.net> wrote:
> On 06/25/21 17:28, Jim Pennino wrote:

<snip old stuff>

>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A
>> public server that does NOT request use of DNS which yields 3 sources of
>> time without using a pool or DNS lookups.
>>
>> Or for $28/machine I could use 2 USB GPS receivers and my machine with
>> PPS GPS, which also provides 3 sources of time without any network
>> access at all.
>>
>>
>
> Your choice, but when I registered the ntp server here with the pool, I
> just used the fixed ip address. That's what they ask for and it does
> bypass dns altogether. The less translation the better, unless
> you really need it...
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.

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.

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.

Then on two other machines I attach two $14 USB GPS receivers and no
external references.

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.

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.

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.

On 2021-06-25, 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 04:08, Jim Pennino wrote:
>>>>> William Unruh<unruh@invalid.ca> wrote:
>>>>>
>>>>> <snip old stuff>
>>>>>
>>>>>> I suspect it is the number of times that ntpd tries to contact the
>>>>>> server and fails rather than the time that is important. You could try
>>>>>> putting the server offline and then online again (I use chrony so do not
>>>>>> remember if ntpd has that option).
>>>>>
>>>>> No, it doesn't.
>>>>>
>>>>
>>>> You could use a one line cron script to restart every day, week,
>>>> whenever...
>>>
>>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and a
>>> public server that does not request use of DNS.
>>
>> You could try specifying the server by IP rather than by name, so DNS is
>> not needed. Of course this rule out using pool, unless you put them in
>> by IP. DNS is just used to translate names to IP, so if you use IP, then
>> DNS is not needed.
>
>
> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A
> public server that does NOT request use of DNS which yields 3 sources of
> time without using a pool or DNS lookups.

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
machine not on your network. The remote machine has nothing to do with
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.

>
> Or for $28/machine I could use 2 USB GPS receivers and my machine with
> PPS GPS, which also provides 3 sources of time without any network
>e access at all.

Sure. The problem of course is that that $28 onlybuys you a pretty bad
time source (pretty bad meaning milliseconds rather than microseconds or
nanoseconds), which for most of man's history on this earth is
absolutely astonishingly, and inconceivably good.

Note that hanging all three off of one machine can lead to conflict
between them as to interrupt processing, leading to degraded time
performance. But again that is at the microsecond level, not milli or
second level.
Of course if you machine is at the bottom of a mineshaft in mountains,
gps receivers are pretty useless. Or in the basement of a highrise
without windows.

>
>

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.

>
> 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.
>
> 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.

>
> 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.
>
> 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.

>
> 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.

>
> 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-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:A

<snip old stuff>

>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A
>> public server that does NOT request use of DNS which yields 3 sources of
>> time without using a pool or DNS lookups.
>
> 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
> machine not on your network. The remote machine has nothing to do with
> 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.

This is not quite correct.

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.

Using a IP address for ntp pools is a bad idea as someone else has said.

However, there are lists of publicly available ntp servers which list
the owners preference for DNS usage. Some servers want you to use the
fully qualified domain name and some servers don't care if you use the
IP address.

>> Or for $28/machine I could use 2 USB GPS receivers and my machine with
>> PPS GPS, which also provides 3 sources of time without any network
>>e access at all.
>
> Sure. The problem of course is that that $28 onlybuys you a pretty bad
> time source (pretty bad meaning milliseconds rather than microseconds or
> nanoseconds), which for most of man's history on this earth is
> absolutely astonishingly, and inconceivably good.

Except you are forgetting a few things:

1. I have a ntp server with a real PPS GPS attached which is good to
microseconds.
2. My actual real time requirement is in the 10s of millisecond range.
3. Any accuracy past the requirements of number 2 is purely out of
curiosity.

> Note that hanging all three off of one machine can lead to conflict
> between them as to interrupt processing, leading to degraded time
> performance. But again that is at the microsecond level, not milli or
> second level.

As each will go into a separate plug, that is HIGHLY unlikely to happen.

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.

> Of course if you machine is at the bottom of a mineshaft in mountains,
> gps receivers are pretty useless. Or in the basement of a highrise
> without windows.

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.

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 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.

>>
>> 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.

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.

> 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.

On 06/26/21 01:05, Jim Pennino 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 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.
>
>>>
>>> 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.
>
>

With all respect, you can't expect to get help with such an aggressive
attitude. People will help, but why ask if you know it all already ?...

chris <chris-nospam@tridac.net> wrote:

<snip old crap>

> With all respect, you can't expect to get help with such an aggressive
> attitude. People will help, but why ask if you know it all already ?...

I never asked for help with anything.

My original post was to report a verifiable observation of a phenomena
for which I could find no previous report.

From there the thread has wandered far off the original topic, e.g. the
specs for USB 2 versus USB 3.

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.
>
>> 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.

Quiet true.

Unless you are BIG and and have an entire IP block, most ISPs will
delegate your domain name, i.e. you have your own name servers under
your control, but will not delegate the reverse lookups, which means the
ISP's records are usually out of date if you can get them to update them
at all.

Want to see this in action, do a lookup of the machine I am posting
from, gonzo.specsol.net then do a reverse lookup of the address you get.

On 2021-06-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> William Unruh <unruh@invalid.ca> wrote:
>> On 2021-06-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:A
>
><snip old stuff>
>
>>> Or for $14/machine I could use a USB GPS, my machine with PPS GPS, and A
>>> public server that does NOT request use of DNS which yields 3 sources of
>>> time without using a pool or DNS lookups.
>>
>> 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
>> machine not on your network. The remote machine has nothing to do with
>> 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.
>
> This is not quite correct.
>
> 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.

>
> 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.

>
> However, there are lists of publicly available ntp servers which list
> the owners preference for DNS usage. Some servers want you to use the
> fully qualified domain name and some servers don't care if you use the
> IP address.
>
>>> Or for $28/machine I could use 2 USB GPS receivers and my machine with
>>> PPS GPS, which also provides 3 sources of time without any network
>>>e access at all.
>>
>> Sure. The problem of course is that that $28 onlybuys you a pretty bad
>> time source (pretty bad meaning milliseconds rather than microseconds or
>> nanoseconds), which for most of man's history on this earth is
>> absolutely astonishingly, and inconceivably good.
>
> Except you are forgetting a few things:
>
> 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.

> 2. My actual real time requirement is in the 10s of millisecond range.

Which is why I phrased it as I did.

> 3. Any accuracy past the requirements of number 2 is purely out of
> curiosity.

>
>> Note that hanging all three off of one machine can lead to conflict
>> between them as to interrupt processing, leading to degraded time
>> performance. But again that is at the microsecond level, not milli or
>> second level.
>
> 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.

>
> 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.

>
>> Of course if you machine is at the bottom of a mineshaft in mountains,
>> gps receivers are pretty useless. Or in the basement of a highrise
>> without windows.
>
> 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.

There was a huge kerfuffle a few years ago, caused by signal delay in
fibre optic cable from outside to a received in a mine. There was a
neutrino detector in the mine, and the delay in the time signal meant
that the time at the neutrino detector was delayed from that of the
source at a particle accelerator, meaning that the apparent time it took
from source to detector was smaller than it should be. They published a
paper claiming neutrinos travelled faster than light. Although they
thought they had compensated, it turned out there was a bad fibre optics
connection which introduced an extra delay.
This was however at the nano second level, which of course you are not
interested in. But an uncompensated 50m is at the microsecond level,
which they (or your curiosity) might be interested in.

>
>