> So you are correct that some clients may use the SHM protocol in rw mode.
> Can't imagine why...
Does gpsd write in mode 0 or mode 1?
In mode 0, the reader has to turn off the valid flag so needs writing.
Mode 1 isn't solid. It's only got one counter. Clean read-only operation
needs 2
> gpsd installs gps.h, the header for libgps, in $PREFIX/include/gps.h
> I would assume similar for NTPsec: $PREFIX/include/ntpsec.h
That would work, but it shows that ntpsec owns the SHM interface.
I was trying to split it out to emphasize that ntpsec can't just change it
without a lot of
Yo Daniel!
On Mon, 16 Sep 2019 23:05:55 -0400
Daniel Franke wrote:
> On Mon, Sep 16, 2019, 22:50 Hal Murray via devel
> wrote:
>
> >
> > The disadvantage of SHM is that there is no way to wake up a reader
> > when new
> > data is available. Readers have to poll.
> >
>
> This is exactly
Yo Hal!
Let me make a quick retraction below:
> On Mon, 16 Sep 2019 14:09:45 -0700
> Hal Murray wrote:
>
> > I think we should put the current stuff on the back burner and make
> > a new SHM interface where the clients are read only.
>
> ntpshmmon, from gpsd, is already read-only on the
On Mon, Sep 16, 2019, 22:50 Hal Murray via devel wrote:
>
> The disadvantage of SHM is that there is no way to wake up a reader when
> new
> data is available. Readers have to poll.
>
This is exactly what futexes are for.
>
___
devel mailing list
Mark Atwood via devel :
> On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote:
> > I think we should put the current stuff on the back burner and make a new
> > SHM
> > interface where the clients are read only.
> >
> > Is shmget/shmat the right API to use? I remember discussions of
> Another is that you can allow anyone on the localhost to read the SHM without
> any risk of them messing up the SHM data.
Good point.
> It is also fast since it is memory mapped. No system call overhead.
CPU cycles aren't important for refclocks. (at least within reason)
The
Yo Hal!
On Mon, 16 Sep 2019 14:09:45 -0700
Hal Murray wrote:
> devel@ntpsec.org said:
> > I'd like to see "struct shmTimme" cleaned up and move into a header
> > file for system use.. Right now it is not in any header file, so
> > clients like gpsd need their own copies.
>
> Assume we had
Yo Hal!
On Mon, 16 Sep 2019 17:42:24 -0700
Hal Murray via devel wrote:
> > Are UNIX domain sockets available on all OSes? If so, that's worth
> > considering.
>
> One advantage of the read-only SHM mode is that it supports multiple
> readers. So you could run shmmon while ntpd is also
> Are UNIX domain sockets available on all OSes? If so, that's worth
> considering.
One advantage of the read-only SHM mode is that it supports multiple readers.
So you could run shmmon while ntpd is also running.
--
These are my opinions. I hate spam.
> - a multicast DNS broadcaster for NTS.
> - additions to the DNS code to allow non-A/ pools. (cname/srv probably)
> - Additions to the DNS code to allow for mdns monitoring.
I'm not a DNS wizard. That area is slightly ugly in that the DNS work is done
in a separate thread so there is
> I always liked the idea of moving to a shm or a local socket "clockd"
> interface.
My comment and Gary's was only to clean up the existing SHM interface. No
changes outside refclock_shm.c (and whatever it takes to support a new/clean
header file)
> (Under the hood, a UNIX domain socket
-- Forwarded message -
From: James Browning
Date: Mon, Sep 16, 2019 at 4:07 PM
Subject: Re: Future directions
To: Mark Atwood
On Mon, Sep 16, 2019 at 3:24 PM Mark Atwood via devel
wrote:
> On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote:
> > I think we should put
On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote:
> I think we should put the current stuff on the back burner and make a new SHM
> interface where the clients are read only.
>
> Is shmget/shmat the right API to use? I remember discussions of there being
> a
> wrong API but don't
I like both of those, port randomization and better transmit timing. Plus it
will make the IETF people happy.
..ѥѸђ
Mark Atwood
Project Manager of the NTPsec Project
+1-206-604-2198
On Mon, Sep 16, 2019, at 03:00, Eric S. Raymond via devel wrote:
> Hal Murray :
> >
> > Two areas to
devel@ntpsec.org said:
> I'd like to see "struct shmTimme" cleaned up and move into a header file for
> system use.. Right now it is not in any header file, so clients like gpsd
> need their own copies.
Assume we had a nice header file. Where would it live? What are the
mechanics of
Yo All!
Consider the a wishlist item as changes would be a bit jarring.
I'd like to see "struct shmTimme" cleaned up and move into a header file
for system use.. Right now it is not in any header file, so clients
like gpsd need their own copies.
Here is the current definition from attic/sht.c
Hal Murray :
>
> Two areas to consider:
>
> Port randomization:
> https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04
>
> The basic idea is for the client side to use a random port number when
> sending
> packets so bad guys have a harder time attacking with junk packets if
Hal Murray via devel :
> wscript and friends have various things like:
> if ctx.env.DEST_OS in ["freebsd", "openbsd"]:
> ctx.env.PLATFORM_INCLUDES = ["/usr/local/include"]
>
> I think the PLATFORM_ part is leftover from an old old version of waf.
>
> ctx.env.PLATFORM_INCLUDES works
Hal Murray via devel :
>
> There are various #ifdefs testing RLIMIT_MEMLOCK and friends
>
> The Linux man page for setrlimit says:
>getrlimit(), setrlimit(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
> So I think we can assume it exists and remove the #ifdefs.
>
> Any reason not to?
Two areas to consider:
Port randomization:
https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04
The basic idea is for the client side to use a random port number when sending
packets so bad guys have a harder time attacking with junk packets if they
can't monitor the traffic to
21 matches
Mail list logo
