Catching up omn unfixed bugs

[Eric S. Raymond]

I've been distracted the last couple of days by trying to spin up
another ICEI project that's on a tight deadline.  It seems I missed
replying on a couple of threads.  This is my attempt to carch up.

Hal Murray:
>How important is supporting gpsd on systems without SHM?

Realistically, not very.

We've given up on Windows until their ability to run Linux binaries is
fully deployed, which will pretty certainly make SHM a non-problem. (I
anticipate trouble around the clock-manipulation calls, however.)

I think Mac is the only platform without SHM we're actually
supporting, and I view it as a minor one.  Hobbyists may run NTP
service on it, but our real target audience is data centers and
you won't find Macs in those.  (On the other hand, one might find
*BSD.)

In any case, Gary has undertaken to rescue GPSD_JSON, so absence of SHM
may well become a non-problem.

>I think we need the concept of stability to be associated with various 
>features.  There should be a way to ship something without a promise of long 
>term support or that it will run on all systems or that all combinations of 
>options have been tested or ...

Some drivers are marked deprecated and likely to be removed in a
future release.  That is presently the only stability tag we have.

We could add an unstable/experimental tag.  GPSD_JSON is the only
place I can think of that might merit it, depending on Gary's degree
of success.

>How does SHM/JSON interact with the great refclockd proposal?

Right, you weren't at the Penguicon FTF meeting. The refclockd plan
is pretty dead at this point.  The tradeoffs driving it have shifted
as our driver inventory has shrunk.

The payoff from refclockd refactoring can be thought of as T
- S, where T is proportional to the complexity cost (LOC) of the
driver code removed and S is the fixed LOC cost of wrapping it in a
separare daemon.

As the driver inventory shrank, the result of this calculation has
been falling. We've turfed out more drivers than I was expecting;
we're at 19 now, which is less than half of the original inventory of
43.  There are principled reasons we might drop two more - Oncore
and GPSD_JSON.

Thus, I concluded about 6 months ago that refclockd was no longer
looking like much of a win.  Instead, further paring back the driver
inventory and possibly migrating some support into the generic driver
now seems like a better plan.

On the gripping hand, we escape one of the constraints if instead of
spinning up a refclockd, we were to move the refclock drivers into to
GPSD.  *That* framework is already paid for and the interface to ntpd
is well debugged.  Also, I think GPSD's PPS support is better than
ntpd's.

But nothing like, or refclockd for that matter, that can possibly
happen until we get enough test hardware to verify the drivers in
their new environment.  In effect all this is blocked until we can
spin up a hardware test lab.

>We could fix the ntpd side of the SHM interface to be read only.  That would 
>let multiple readers listen to the same source so you could fire up shmmon 
>while ntpd was running.  I think this would solve a protection problem.

I'd take that patch before 1.0 feature freeze, because if it breaks it
will break everywhere and obviously.

>Are we using POSIX SHM?  (How many SHM variants are there?)

We are not using POSIX SHM yet.  I know only two variants, the
(technically nonstandard) SHM we're using derived from old System V
and the POSIX version.  There's been no demand for the latter yet
and there is something I've forgotten about its API that made it look
like a pain.

>Would you be happy if we threw away the current code and you started
>from scratch?

Let's revisit that question if Gary's rescue fails.

>Would it help if the JSON interface was NTP centric rather than GPSD
>centric?  Maybe we should make a JSON-JSON translator to go between
>gpsd and ntpd.

These seem to me like ways to pile more complexity on top of a
problem that has already accreted too much.

>It would be nice if there was a clean interface for external drivers.
>I assume that each current driver would turn into a stand alone
>program that talked to ntpd via some new/wonderful interface.

We already have a framework for that kind of external driver.
It's called GPSD. :-)

That wasn't just a snarky answer.  

>The simple shared key crypto should support more than MD5 and SHA1.

Daniel has undertaken to do AES-CMAC.  I think that covers what will
be standardized in the foreseeable future.

>ntpq still fails when talking over a lossy link.  (There is a flake option in 
>restrict.  We should see if that tickles the problem.)

I fear I may offend you by saying that I don't see this as a major or
release-blocking problem - but in truth I have a hard time seeing ntpq
used for anything but local monitoring over a LAN as an important case.

Sure, I'd like to see this problem identified and fixed, because we're
perfectionists and I like it that way.  But, more important than the
tracker issues?  Not from where I'm sitting. Using ntpq over a WiFi
link seems pretty odd to me, because doing time sync over a link that
vulnerable to RFI and changes in the weather seems like a stunt that
nobody in serious production would want to try.

>ntpwait can't find its libraries in some environments.

I've replied to this one before. It's a distro-packager screwup.
There isn't any elegant fix other than not using distros that screw
up.

>Understanding the mysterious GPS rollover fixup is the top of my list.
>
>If I find that, I'll probably work on ntpq retransmissions.

Those are what *I'd* prefer you to be working on, anyway.  The only
other bug assigned to you is the very old one about drift at the rail.
If you can fix that one it's gravy.

You muttered something about possible overflow in the calculations.
I'd have investigated this, but I have zero experience at chasing
overflow bugs - I wouldn't have a clue what to look for.

Um, maybe the drift calculations need to use the new doubletime_t
(long double) type?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The right to buy weapons is the right to be free.
        -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942