visiting the todo list

[Hal Murray]

devel at ntpsec.org said:
> IIRC gpsd has a read-only monitor program. I'm not sure how much of the code
> could be applied to revise ntpd/refclock_shm.c, but I think that quite a bit
> of it could. Which with it hopefully being read-only addresses a couple of
> bullet points. I also seem to remember that some PTP software can export via
> the same SHM struct which would drag in a third.

gpsmon uses a TCP connection to gpsd.  There is no shared memory involved.

What sort of monitor do you have in mind?
With only a little hacking, we could make NMEA sentences available.


> I had a foolish notion for a revised SHM driver but it just dropped off the
> list.

There is a way for the client/reader to be read only.  Fixing this has been on 
my list for years.

The idea is to use two counters.  Call them X and Y.  The writer does:
  Bump X
  update data
  Y = X
The reader does
  grab Y
  grab data
  grab X
if grabbed X and Y are equal, data is valid.
The key is that the reader references X and Y in the opposite order from how 
the writer updates them.  If the reader and writer are accessing the data at 
the same time, the reader gets the old Y and new X.


> Replacing the once per second timer would be nice for power saving. How about
> an unbalanced binary tree for event tracking.

Threads.

I'm still planning to threadify the server side.  I'm stalled half on other 
things and half waiting for Eric to get free so we can cleanup the ntpq stuff.

Once that is done, we can threadify the refclocks and server stuff.  (and 
implement port randomization)



-- 
These are my opinions.  I hate spam.