gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Updated docs on NTP segment management


From: Gary E. Miller
Subject: Re: [gpsd-dev] Updated docs on NTP segment management
Date: Sat, 7 Mar 2015 12:26:49 -0800

Yo Harlan!

On Sat, 07 Mar 2015 12:07:20 -0800
Harlan Stenn <address@hidden> wrote:

> Your patch uses clock_gettime() to get the time for the tvc structure.

Eric supplies an alternate clock_gettime() for OS that do not have it, or
that name it something else.

> That's not sufficiently portable for us.

Other than Windows I think the portablility fallback is now known good.

If you know how to get nSec time in Windows we can add that.

> From what I can see, the tvc structure and its predecessor code in the
> old driver only care about how many seconds have passed, in order to
> do a check against up->max_delay.

Eric decided to remove a lot of the half-way good enough time functions
and just go to nSec all the time for consistency.  Now gpsd only needs
to support one universal system time function, not a bunch of them.

It also removed a ton of time conversion, comparision and display
functions, greatly simplifying the code, and remove a lot of odd ball
corner case failures.

Also gspd has had a history of developers taking low resolution time and
later using it in high resolution contexts.  Put another way, a lot
of speccial caing to fit the exact precision needs has been problematic, so
we have been moving to just always doing things in the most precise way.

> Do you have future plans for the tvc structure where higher-resolution
> information will be useful?

Well, timespec_t is the best standard we can find.  gpsd tries to stick
to the standards.  The "General Timestamp API' project looks like a good
next step, but it looks to be paused?

As for that secific instance of tvc, we have a lot off people clamoring
for 5Hz, 10Hz and 20Hz, PPS.  When that happens we will need the extra
precision.

>  Otherwise I'm inclined to revert the
> patch in that area to go back to a time() call, as that easily gives
> us the "seconds" we're looking for.

Please do not.  For the reasons stated above.  Plus, time() can't return
an error.  Also, time() returns an int and will be harder to deal with
for 2038, and thus is on the POSIX warning list.

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



reply via email to

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