gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals -


From: Gary E. Miller
Subject: Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?
Date: Mon, 6 May 2019 12:46:27 -0700

Yo Greg!

On Sun, 05 May 2019 10:57:10 -0400
Greg Troxel <address@hidden> wrote:

> I was mostly kidding about BeiDou/Galileo, but redundancy for bad
> skyview is good.  It's also good in terms of a failure of the GPS
> system, assuming that one of the other constellations is still ok.

I guess you want that if you are in a war zone and the Russians are
jamming GPS.

> > Ugh.  Ubuntu client is 3.17.  Many bugs fixed since then...  
> 
> Indeed, but I am trying to help organize a path for normals, and "take
> your system you installed, and then hand compile the latest version of
> all 2500 packages because each of them has new releases with bugs
> fixed" does not seem like a good path to success!

I'm only suggesting recompiling one: gpsd.  Better yet, get the
package maintainer off his butt.

> >> I see that systemd is listening on gpsd's port, and gpsd is not
> >> running.  
> >
> > Note that the systemd part is NOT from us, but from Ubuntu.  We have
> > no control over that POS.  
> 
> Certainly; I get it that you don't care for systemd, and it seems
> pretty clear that the default situation I found is not good.  But
> again, normal people install Ubuntu, and I'm trying to figure out a
> good path for them.

Fair enough.  Especially when give a does of advice to move to
a better distro...

> >> But, I wonder if this is expected to work for NTP?  Without -n, it
> >> seems it will not work.  
> >
> > Without -n, gpsd wakes up only for JSON clients.  So you are SOL
> > with NTP.   
> 
> So I really have to ask: why is gpsd's default behavior of waiting
> until open useful, for who, compared to the harm it causes?

To save power.  Period.  You might have notice that battery life is
a big deal these days.

> I pluggd the
> device into USB power, no computer (Anker lighter socket adaptor),
> and it started pulling 7-10 mA, and also started blinking.  So
> declining to open it does absolutely nothing useful.

10 mA is important to some.  It also matters, a lot, which power saving
mode you GPS is in.  Many report much larger power savings.

Did you measure the total system power?  remember that on an
ARM chip having gpsd processing is taking about 1% of a core.  That is
huge to some people.

> I can believe there are devices where it's useful.  But I wonder if
> anyone here actually has one?

They pop up here often to complain.

> >> The Time Service HOWTO does not talk about systemd,  
> >
> > Yup. systemd is not part of gpsd, and using it with gpsd is not, at
> > least by me, recommended.  Especially for time service.  If you feel
> > some crumb should be thrown to the poor enslaved systemd users, then
> > feel free to send a doc patch.  
> 
> Well, I don't know enough to write it.  But certainly, it should be
> explained.

I don't use systemd, so I can't do it.  Until some that does cares to do
it, it will not get done.

This is one of systemd biggest problems, few actually know how to use it.

> >> It should be easy for someone to setup up a system so that
> >> gpsd/ntpd works on boot.  I'm not sure of the way forward.  
> >
> > Sadly that is very distro dependent.  If you wanted to add an Ubuntu
> > 18 specific section to any of the howto's that might help other
> > people. The few that actually RTFM.  
> 
> I realize that's per-OS/distribution dependent.  But the HOWTO could
> outline the approach so that someone who isn't gpsd-clueful could
> implement it in the distribution.

Once again, patches welcome.

> > Way out of scope for us, but we try to help any distro maintainer
> > that is open to help.  
> 
> I know the maintainer of this one.  But he has never run gpsd, and I 

Maybe you can clue them in?

> I don't get this.  I see it as pretty easy:
> 
>   - make the -n behavior default

I tried, and failed.  If you can convince ESR then it is a done deal.

> How many people/systems are there that actually benefit from the -n
> behavior?  Does this matter on Android?

Not how many.  Who.  It matters, a lot, to embedded systems people.

Imagine a GPS on a Hawk.


> I am seeing fuzz of a few milliseconds.  I call that success; you may
> call it failure, depending on which accuracy requirements we have in
> mind.

As Hal pointed out, long term you can't expect accuracy (not jitter) to
be better than 100 mS.

> > Works for me.  better yet, splurge another $10 and get a USB GPS
> > with PPS.  I get about 1ms using USB GPS those.  
> 
> I looked at the hardware list and failed to come up with a "buy this
> part number which is in current production in the USB GPS mouse form
> factor".  There were two things that seemed usb-ish and had PPS listed
> and both were 404.

Once again, patches welcome.  But the Chinese now dominate the market
and their part numbers come and go in hours.

For USB, you want any GPS with an M8030 chip.  But that does not
do PPS.  For PPS you just have to search for u-blox 8 and PPS.

For PPS over USB, find a Navisys GR-601W or GR-801W.

> >> But it could be a high stratum with a
> >> 100 ms guess, so that it takes over with no other sources.  I
> >> realize this is likely controversial and for specific situations,
> >> so please take it as musing rather than recommendation.  
> >
> > Not controversial at all.  And way better than using the pool.  
> 
> I'm going with stratum 5 for now.

I think you misunderstand stratum.  Stratum has zero to do with
"precision".  Stratum is just the number of hops (think traceroute) to
a "primary" time server.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

Attachment: pgpw5QIthTUBa.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]