Re: nts and ntske log files
>Expires February 2036 minus the current date >is about 12 years and 5 months maybe ish... The context is a duration of time rather than time of day. eg the result of sub_tspec() How many seconds did it take to do X? The current date has nothing to do with it. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: nts and ntske log files
On Aug 28, 2023 18:10, James Browning wrote:On Aug 28, 2023 17:10, Hal Murray wrote: James Browning said: > The NTP solution would be to convert the mess to l_fp which > will work for a bit less than 13 years. Thanks. l_fp is the right answer. How did you get 13 years? I get 136. Did you drop/typo the 6?Expires February 2036 minus the current dateis about 12 years and 5 months maybe ish...Oh, wait I am supposed to use rollover funcs tocompensate for throwing away more than halfof the epoch at the beginning. > My joke would be to have it as a long long of micro-seconds which would be > good for hundreds of thousands of years. l_fp has 32 bits of fraction. micro takes 20 bits. So using micro seconds would gain 12 bits. So that would be 557xxx years.My revised guess would've been around 54400.___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: nts and ntske log files
James Browning said: > The NTP solution would be to convert the mess to l_fp which > will work for a bit less than 13 years. Thanks. l_fp is the right answer. How did you get 13 years? I get 136. Did you drop/typo the 6? > My joke would be to have it as a long long of micro-seconds which would be > good for hundreds of thousands of years. l_fp has 32 bits of fraction. micro takes 20 bits. So using micro seconds would gain 12 bits. So that would be 557xxx years. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: nts and ntske log files
> On 08/28/2023 3:08 PM PDT Hal Murray via devel wrote: > > > I just pushed the first cut. > > No documentation yet. > > Like sysstats and usestats, ntsstats and ntskestats get logged every hour. > > If you look at the output from ntpq -c nts, the counters fall into two > clumps, > one for NTS and one for NTS-KE. All the counters get logged in the same > order. > > Should we add counters for IPv4 and IPv6? > I think I'll merge the CPU usage. (getrusage provides separate user and > system CPU slots) > > There are 3 cases for the server side of NTS-KE: > OK: Worked > Failed: SSL got started but something didn't work (http?) > NoSSL: SSL didn't get started (telnet?) > I think I'll add wall/CPU counters for the no-SSL case. > > Should we split things client/server rather than NTS/NTS-KE? With the > current > split, you can't get NTS packets per NTS-KE without looking in two separate > files. > > What's the right type/units for wall time and CPU time? The current code is > double and seconds. That won't ever overflow, but some day in the far future > a very busy KE server might drop low bits. We could solve that by using > timespec. Should I switch to timespec now so we never have to think about > this again? Can ntpq handle timespecs as elapsed times rather than time of > day? ... It probably should be at the point where a double is inadequate to represent current time as a double due to leaking nanoseconds. The NTP solution would be to convert the mess to l_fp which will work for a bit less than 13 years. My joke would be to have it as a long long of micro-seconds which would be good for hundreds of thousands of years. > I'd like ntpq to display both the total and recent counters like sysstats > does. > > The code that does hourly logging has to remember the totals when it prints > things so it can subtract them off from the new totals next time. It's easy > for me to return the old values but slightly inconvenient to do the subtract. > > How hard is it to do the subtract in ntpq? I didn't do it in ntpq. I wrote a macro that builds a couple of getters per attribute (in ntpd/ntp_proto.c), and abused it. Then a wrapper abusing the getters was added in 'ntpd/ntp_control.c'. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
nts and ntske log files
I just pushed the first cut. No documentation yet. Like sysstats and usestats, ntsstats and ntskestats get logged every hour. If you look at the output from ntpq -c nts, the counters fall into two clumps, one for NTS and one for NTS-KE. All the counters get logged in the same order. Should we add counters for IPv4 and IPv6? I think I'll merge the CPU usage. (getrusage provides separate user and system CPU slots) There are 3 cases for the server side of NTS-KE: OK: Worked Failed: SSL got started but something didn't work (http?) NoSSL: SSL didn't get started (telnet?) I think I'll add wall/CPU counters for the no-SSL case. Should we split things client/server rather than NTS/NTS-KE? With the current split, you can't get NTS packets per NTS-KE without looking in two separate files. What's the right type/units for wall time and CPU time? The current code is double and seconds. That won't ever overflow, but some day in the far future a very busy KE server might drop low bits. We could solve that by using timespec. Should I switch to timespec now so we never have to think about this again? Can ntpq handle timespecs as elapsed times rather than time of day? ... I'd like ntpq to display both the total and recent counters like sysstats does. The code that does hourly logging has to remember the totals when it prints things so it can subtract them off from the new totals next time. It's easy for me to return the old values but slightly inconvenient to do the subtract. How hard is it to do the subtract in ntpq? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
