Direct-mode MRU

[Hal Murray]

> Hal, I couldn't think up a better UI than yours for direct mode. I don't
> like it much, but I think under our constraints you did as well as you
> could.

It might be simpler to describe if "direct" called mru rather than setting a 
flag.  It could also turn off hostnames since they don't make much sense if 
you are trying to grab data as fast as you can.  But it's probably not 
important since its use will probably be scripted.

It might help if there was a way to specify an output file.

> I've docmented it better, and also added a common section to the "known
> bugs" portions of the ntpq and ntpmon pages explaining the underlying
> problem.

Thanks.

> It's not obvious to me how we can do any better than this. The only other
> shot in my locker would be to reduce the client library's memory usage, but
> since that would uglify the code some I'm not going to actually do it until
> we have evidence that this is an actual blocker. 

I think there are two cases.  One is memory usage when the target system does 
not have a large MRU list.  With a few 10s of thousand slots, it only takes a 
few megabytes of memory.  Who cares?

On the other hand, if you want to track a busy pool server, there can easily 
be a million slots.  In my case, that's on a system without a lot of memory 
so a few gigabytes won't fit.  That's why I added the direct mode.

If you are going to process a million slots, you probably need to automate 
things.


-- 
These are my opinions.  I hate spam.