> 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 cou
> 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 th
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 wha
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 SHMs
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
dev
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 ther
Yo Hal!
On Mon, 16 Sep 2019 19:50:24 -0700
Hal Murray wrote:
> CPU cycles aren't important for refclocks. (at least within reason)
Yup.
> The disadvantage of SHM is that there is no way to wake up a reader
> when new data is available. Readers have to poll.
Good point.
I'd like to cleanup
> 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 disadvantage
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 a
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 runni
> 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 som
> 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 or
-- 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 th
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 rem
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 consider:
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 getting
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 they
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 be
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?
Nop
21 matches
Mail list logo
