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.
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.
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.
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.
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 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...
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 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.
On 06/25/21 17:28, Jim Pennino wrote:
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...
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
e access at all.
On 2021-06-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:A
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.
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.
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:
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.
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.
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 ?...
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.
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.
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.
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 2021-06-26, Jim Pennino <jimp@gonzo.specsol.net> wrote:
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 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.
On 2021-06-25, Jim Pennino <jimp@gonzo.specsol.net> wrote:
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.
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.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 185 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 04:58:32 |
| Calls: | 3,676 |
| Calls today: | 2 |
| Files: | 11,149 |
| Messages: | 3,447,353 |