[Top][All Lists]

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

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

From: Harlan Stenn
Subject: Re: [gpsd-dev] Updated docs on NTP segment management
Date: Thu, 26 Feb 2015 21:57:35 +0000

"Gary E. Miller" writes:
> On Thu, 26 Feb 2015 20:24:17 +0000
> Harlan Stenn <address@hidden> wrote:
>> And putting the "version" in the mode field is a case where I wonder
>> if that should be in the per-unit data or in the preamble.  There are
>> pros/cons with each choice.
> Maybe an example would help?  Version needs to be per unit.

A version bump would seem to be required if we change the size of the
unit data structure, or if there is a backward-incompatible change to
the data layout.

> > > > I'm also wondering if the V2 SHM interface should include a
> > > > preamble structure before the per-unit structures, as that seems
> > > > to be a more efficient way to go.  Duplicating data in the
> > > > per-unit structures seems wasteful to me.
> > > 
> > > What is duplicated?  And how to handle multiple senders?
> > 
> > The version of the SHM protocol/data structure, for example.
> Or not.  For example, if linuxptp is send the nSec version and gpsd is
> sending the V2 version (at the same time!) there is not one preamble but
> two, or more.

No version bump is needed if some senders decide to provide nSec data
and some don't.  We made sure this was a "compatible" change.

If the V2 stuff is in the same size data structure then a version bump
is not required for that reason alone.  If the V2 data structure is the
same size, or if it's bigger and the stuff in the original data size is
compatible with the old stuff, then an "old" client can use this *if* it
communicates on Unit 0.

> > > > I also wonder if there is a good way (and a good reason) to
> > > > support:
> > > > 
> > > > - a mix of V1 and V2 SHM areas on the same shmid
> > > 
> > > Yes, but not at the same time.  :-)
> > 
> > Then that would be a "no" :)
> > 
> > This goes to multiple senders, or even a single sender that wants to
> > send V1 and V2 data to clients.
> Huh?  Things come 'from ' senders?  Unless the client can tell the
> sender what he supports?

No, the sender decides what to write in the unit data area.

An external mechanism is used to tell the client what unit they should
be paying attention to.

"He French Fried when he should have Pizza'd. If you French Fry when
you're supposed to Pizza, you're gonna have a bad time."

> > > > - more than 4 units' data structures in an SHM segment
> > > 
> > > Absolutely.  207 supported now.  With linuxptp and soon more senders
> > > talking NTP SHM this could grow large in the lab.

> > This is another candidate for a "preamble" data area - "how many units
> > are on this SHM segment?"
> Hmm, so you are saying, one SHM, that includes a primary header, followed
> by one or more unit headers?  Then there could still be multiple simultaeous
> SHMs each with multiple sources?

.. followed by the appropriate number of unit data areas.  I'm not sure
what a "unit header" is.

Right now, the code in NTP assumes all SHM beasts will use the same size
struct shmTime, and it calls shmget() on a per-unit basis.  That alone
might make it impossible to have a primary header followed by an array
of unit data.  Or we'd need to change the code, and understand what that
would do on older systems that used the "old way".

Like clients will need to know which unit(s) they want to pay attention
to, the senders will also need to know which unit(s) they should write

> Starting to sound like a tree.  I can't see saving a few bytes helps
> anyone and decisions about what is shared/not-shared would be frozen
> going forward.  Plus lots of imlications for configuration, unless
> there is a way to autoconfigure this.

autoconfigre?  It may be that we'd want to have some other mechanism to
manage SHM stuff, and have SHM data providers and data consumers
"rendezvous" with this mechanism to get their shmids.

More pros/cons...
Harlan Stenn <address@hidden> - be a member!

reply via email to

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