> Can you get them to specify exactly what they want?
One thing to add to the list if you are going to collect NTP data...
If you know that the clocks at both ends are accurate, rawstats will give you
the transit times in each direction.
NTP assumes the transit times in each direction are
Mark Atwood, Project Manager :
> Oh, believe me, cloud scale devops shops know what to do with all the
> timing information.
Can you get them to specify exactly what they want?
--
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel
> This would actually be pretty easy to do, mechanically speaking. The
hard question is what you do with this timing information once you have it.
Oh, believe me, cloud scale devops shops know what to do with all the
timing information.
On Sun, Jul 14, 2019 at 3:19 PM Eric S. Raymond wrote:
>
> It's...hm...maybe a good way to put it is that the structure of the NTPsec
> state space and sync algorithms is extremely hostile to testing.
I still don't have a good understanding of why TESTFRAME didn't work. I can't
explain it to somebody.
We've got
code mutations
hidden variables
Mark Atwood :
> I want to encourage Hal to think of ways of cracking these problems.
>
> Especially the idea of verifying key parts of the state space, even if
> we can't verify it all.
I wish him the best of luck...
> And especially if there was a way to usefully log the relative timing
> of
> Especially the idea of verifying key parts of the state space, even if we
> can't verify it all. And especially if there was a way to usefully log the
> relative timing of various important state transitions. (That is something
> on the wishlist of the AWS NTP Kronos team.)
What are they
