t ntpd creating and owning the
> segment it reads timestamp data from would be an anti-pattern.
No process "owns" the SHM. Think of it just like a file.
> Can someone elaborate on which is implemented, and why?
I suggest that you just read the source. Look in gpsd as the sender
and
system shows: *SHM(0) .SHM.0 l3 16
> > > 3770.000 -0.728 1.356
> >
> > Which I assume had been running for months.
>
> Yes and no; the system was rebooted 4 days before.
But the adjtime file survives a reboot. And not as good as yo
t. The SiRF 4
is not very sensitive and uses fewer sats and constellations than the
u-blox
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
V
ntpd 22 does not.
RGDS
GARY
-------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it
p, but if the receiver is powered down long enough, the stored
GPS-UTC offset will become out of data.
RGDS
GARY
-----------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 85
a while.
After receiving the Almanac, which can take up to 25 minutes on some
older GPS, the current leap second offset is known. But now ntpd is
set in its ways, and will take a while to slew to the correct time.
RGDS
GARY
-------
Gary
ime, from another chimer, on your server
before starting ntpd?
RGDS
GARY
-------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos
> Eventually you remember an incident on 2016-01-26 where the UTC time
> provided by most GPS receivers was off by about 13 microseconds, which
> could also be seen by PPS slopes handled via an IRQ.
Yeah, nothing we can do when the GPS operators mess up
RGDS
GARY
---
tion until it has the
current ephemeris for the sats in the fix.
The almanac may take 12 to 24 mins to download, but the almanac is just
for predicting future GPS sat locations.
I'm sure there a few small cases where my simplification is not right,
but I've not seen PPS shift from the alm
laining about. His GPS was saying synced,
but was off by the UTC/GPS offset which had not been downloaded yet.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
the UTC
> correction parameters don't get lost while the system is powered off.
I guess some daemon could poll the GPS and hold off starting ntpd until the
ephemeris is downloaded.
RGDS
GARY
-----------
Gary E. Miller Rellim 10
099871 1502915840.82405 1502915841.0 0 -30
^C
Also, how are you starting gpsd and ntpd?
I do not know anyone using GPS over udp...
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
0::f7cd:fd97:139.149.65.161
Compr. v4inv6 address - fe80::f7cd:fd97:139.149.65.161
[IPV6 DNS]
Reverse DNS (ip6.arpa) -
1.a.1.4.5.9.b.8.7.9.d.f.d.c.7.f.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
RGDS
GARY
-------
Gary E. Mill
ribed it is still how it is wotking for me
now.
RGDS
GARY
-------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid es
Yo Marco!
On Mon, 3 Apr 2017 17:12:50 +0200
Marco Marongiu wrote:
> On 31/03/17 22:39, Gary E. Miller wrote:
> > Quick question, does anyone use either of these in ntp.conf?
> >
> > interface[listen | ignore | drop] [all | ipv4 | ipv6 | wildcard |
> > name | addr
he name of the interface?
RGDS
GARY
-------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If yo
16 matches
Mail list logo