mrulist direct mode, monitoring pool servers
hmurray at megapathdsl.net
Thu Dec 22 02:28:07 UTC 2016
> 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.
> 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.
More information about the devel