mrulist direct mode, monitoring pool servers

[Hal Murray]

> I can't find any commit that looks like it involvs a 'direct' flag. Did you
> push this, or is it a private set of changes?  If the latter, I'd like to
> see the patch and play with it. 

Sigh.  I forgot to push last night.  I just fixed that.

My cron jobs worked last night.


esr at thyrsus.com said:
>> If we can't go fast enough, we should be able to get some of the
>> data and/or some estimates of how much we are missing.

> Some of the data, yes.  As the Mode 6 protocol is designed I don't see how
> to get good estimates.

> On the other hand, I can imagine an inexpensive protocol extension that
> would help a lot - adding a tag to the front of each span that reports the
> MRU-list size at the time of transmission.  If your client sees this number
> rising rather than falling during a span sequence then you can at least be
> warned that you're probably in a losing race. 

The size of the list isn't what you want.  If slots are getting recycled, the list size will be constant.

I think we can get the numbers we need, not through the mru protocol but by through something like monstats.  It doesn't have what we need, but we can fix that.

[memoryusage]
> Can't easily see it being a big problem in the normal mode either, frankly.
> By definition the client memory usage has to be linearly related to the
> memory usage on the server, and even in Python I don't think the constant of
> proportionality can be very large. I'd guess around 2x-3x. 

The context is running on a cloud server where they charge for memory.  The server has a lot of that.  A few experiments showed that collecting needed more than was available.  I'll try to get more data if you think it's important.


>> Any suggestions for a UI/CLI?
> Not before seeing the patch, no.

Current UI is a "direct" command to ntpq that sets a flag which gets passed in to the worker code which then prints each batch out on the fly.



-- 
These are my opinions.  I hate spam.