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 16:23:47 -0700

Yo Greg!

On Mon, 06 May 2019 18:59:58 -0400
Greg Troxel <address@hidden> wrote:

> "Gary E. Miller" <address@hidden> writes:
> 
> >> 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.  
> 
> Time to watch Red Dawn again :-) 

A fave of mine!

> > I'm only suggesting recompiling one: gpsd.  Better yet, get the
> > package maintainer off his butt.  
> 
> I know you are suggesting only one.  The other package maintainers
> will want their package updated too; everybody thinks their child is
> special. It seems that 3.17 was current on 2018-04 when the 18.04 LTS
> started, so it doesn't seem broken of them to still be on it.

At least they are not RHEL shipped 6 year old known broken stuff.

> >> 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 really meant "for which setups does it actually save power, and are
> those normal enough to control the default, vs the people with the
> setups where it matters being the one to set the option".

Given how many people run their Ubuntu laptops on battery the number
could be quite large.  The last thing was want is for someone to
install gpsd on a whim, get crappy battery life, and remove it before
reading, and understanding, the documentation.

I had not thought of the laptop argument before, but that convinces
me the default is correct.

> >> 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.  
> 
> My point is that this is the power with no gpsd, and thus I would
> expect with gpsd without -n.  I am not seeing the behavior of the
> device being in sleep mode until DTR is asserted.

You keep mentioned DTR.  I know of no GPS in the last 10_ years uses
DTR.

But the laptop argument hinges on the power wasted because gpsd is not
letting the laptop sleep.

> >> 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.  
> 
> I really have to wonder if that's true with modern ublox.

Depends on the u-blox, how it is connected, and how it is configured.

So, you can do a lot better, but not without the right GPS configured
the right way.

You wanted a generic worst case and 100 ms is a good number for modern
GPS.

I encourage you NOT to take my word, or Hal's word, but to run your
own tests.  Simple, just compare your setup to a local NTP running
with PPS.

"Trust but verify."

> > 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.  
> 
> Thanks.  I have a GR-601W.  Looking for those did not seem to turn up
> anything readily purchasable.  i did find a GR-701W on etsy.

Yes.  Mark Atwood sells them.  You can also order direct from Navisys,
but they have a minimum order quantity.

> >> 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.  
> 
> I do understand.   I'm abusing it to bias the selection so that if
> there are normal network peers they are likely to control time.

Low stratum is mostly for loop detection, not for accuracy grouping.

> Given lack of PPS, I would prefer to use the net if present, and the
> non-PPS GNSS receiver if there is no net.

Which should happen naturally, after warmup.  To ensure the net NTP
is picked first, set it to iburst so it gets a good time before the
GPS.  Otherwise the GPS might get picked if it shows valid time first.

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: pgpB_JmXC3EnE.pgp
Description: OpenPGP digital signature


reply via email to

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