Re: [ntp:questions] custom ntp PPS driver

2021-04-19 Thread Gary E. Miller
Yo Kent!

On Sat, 17 Apr 2021 23:05:11 -0400
Kent Dorfman  wrote:

> I put a guy to work on making our GPIO/UDP TATT function available to
> our embedded linux boxes the other day as an authoritative source for
> ntpd.  My assumption was that I could write a source program that
> received TATT messages over UDP, then forward the TATT message to a
> kernel driver (he's writing) via ioctl() and that kernel driver would
> simply unblock the reading of a /dev/pps device file when the GPIO
> signal is asserted.  The tatt message is sent ~0.5 sec before the GPIO
> and the value of TATT is what the time will be upon assertion.

Why?  Just let the PPS happen from the kernel, and validate that it is
expected in the userland client.

> I had hoped that it would be trivial to configure ntpd to do a
> blocking read of /dev/pps and when it unblocks the value read from the
> node would be the authoritative time.

Just use the standard KPPS calls as they are intended to be used.

> He tells me that from what he can find, a shared memory interface
> between the source and ntpd is simpler to implement.

Apples and Oranges.  For example, gpsd, reads /dev/pps0, validates
that the PPS is valid, then stuffs the time data in the shared memory
slot.

> What we are
> unclear of at present is who "owns" the shared memory segment.

"ipcs" tells you that.  "root" owns them.  The first two are permissions
600, the rest are 666

-- Shared Memory Segments 
keyshmid  owner  perms  bytes  nattch status  
0x4e545030 0  root   60096 2   
0x4e545031 1  root   60096 2   
0x4e545032 2  root   66696 3   
0x4e545033 3  root   66696 1   
0x4e545034 4  root   66696 1   
0x4e545035 5  root   66696 1   
0x4e545036 6  root   66696 1   
0x4e545037 7  root   66696 1   



> I
> would speculate that the sender should create and own the segment as
> the "server" of the data, and that ntpd creating and owning the
> segment it reads timestamp data from would be an anti-pattern.

No process "owns" the SHM.  Think of it just like a file.

> Can someone elaborate on which is implemented, and why?

I suggest that you just read the source.  Look in gpsd as the sender
and ntpd as the receiver.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpDGRyfFsRzS.pgp
Description: OpenPGP digital signature
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] custom ntp PPS driver

2021-04-19 Thread folkert
> He tells me that from what he can find, a shared memory interface
> between the source and ntpd is simpler to implement.  What we are
> unclear of at present is who "owns" the shared memory segment.  I
> would speculate that the sender should create and own the segment as
> the "server" of the data, and that ntpd creating and owning the
> segment it reads timestamp data from would be an anti-pattern.

ntpd creates the segment.
Anyone with enough rights can then write to it, if required.
The other way around may also work but make sure it has the correct
size and access rights.
Personally I would ntpd create it and then check yourself if at least
the size of it is what you expect.

Please note that I'm not an authoritative source. I did wrote a few
applictions that interface with ntpd that way though.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


[ntp:questions] custom ntp PPS driver

2021-04-19 Thread Kent Dorfman
I put a guy to work on making our GPIO/UDP TATT function available to
our embedded linux boxes the other day as an authoritative source for
ntpd.  My assumption was that I could write a source program that
received TATT messages over UDP, then forward the TATT message to a
kernel driver (he's writing) via ioctl() and that kernel driver would
simply unblock the reading of a /dev/pps device file when the GPIO
signal is asserted.  The tatt message is sent ~0.5 sec before the GPIO
and the value of TATT is what the time will be upon assertion.

I had hoped that it would be trivial to configure ntpd to do a
blocking read of /dev/pps and when it unblocks the value read from the
node would be the authoritative time.

He tells me that from what he can find, a shared memory interface
between the source and ntpd is simpler to implement.  What we are
unclear of at present is who "owns" the shared memory segment.  I
would speculate that the sender should create and own the segment as
the "server" of the data, and that ntpd creating and owning the
segment it reads timestamp data from would be an anti-pattern.

Can someone elaborate on which is implemented, and why?

Thanks!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions