hmurray at megapathdsl.net
Thu Mar 22 20:22:55 UTC 2018
> I've never tried do describe that kind of testing because it's not easy to
> tell people without prior experience running the clients what a success/
> failure indication looks like. Of course alarm bells would go off on a
> crash, but the most definite thing I could say otherwise is "suspect a
> problem if the number don't look lilke they usually do".
I think it's worthwhile to include some rough sanity checks in a
get-ready-for-a-release document. Another time when that sort of check would
be useful is before the push when making a significant change.
Yes, it's hard to describe what success looks like. But the context is we
are getting ready for a release or doing a big update, so the target audience
is wizards rather then newbies.
> I always do ntpmon first, as that test excerises the packet library pretty
> well and would be more difficult to test jig than others becuse of the
> ncurses otput.
> I dump clock and system variables using ntpq to check that they look sane.
> I test ntpdig and ntpwait.
Good list. I'd put ntpq -p in there too.
We should be explicit about how to "dump clock and system variables". I'm
thinking of chunks you can copy-paste.
Any objections if I write the text? Where should it go?
These are my opinions. I hate spam.
More information about the devel