Re: NIST unit rules and conventions
Paul Theodoropoulos via devel : > Uniformity of presentation seems like a desireable goal - are there any > objections to following these particular guidelines? Not fro me. Go to it. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pending tasks
Another item for your list.
Cleanup the table indexes in ntp_control
It has things like:
#define CS_USED_RBUF76
{ CS_USED_RBUF, RO, "used_rbuf" }, /* 76 */
That makes it a royal pain to insert or delete a slot.
We should be able to make a macro that does the #define and then builds the
slot.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: PYTOGO
On 09/18/2018 05:04 PM, Richard Laager wrote: > I'm doing some digging, and from what I can see Debian/Ubuntu added > support for shared linking Go libraries and then removed it a couple > years later. I'm asking in IRC to try to get a more > conclusive/authoritative answer. The response on IRC was that they gave up trying to maintain dynamic linking, due to too much ABI instability from upstream. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PYTOGO
Yo Richard! On Thu, 20 Sep 2018 17:44:03 -0500 Richard Laager via devel wrote: > On 09/18/2018 05:04 PM, Richard Laager wrote: > > I'm doing some digging, and from what I can see Debian/Ubuntu added > > support for shared linking Go libraries and then removed it a couple > > years later. I'm asking in IRC to try to get a more > > conclusive/authoritative answer. > The response on IRC was that they gave up trying to maintain dynamic > linking, due to too much ABI instability from upstream. Maybe debian/Ubuntu can just replace all Go programs with systemd? I looked more at Go programs on gentoo. Looks like 75% of them are fully static. The rest needed libpthread and libc. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpx4e6xYVyM4.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
SINGLEBUFFER
It's simple, at least conceptually. I'm embarrassed I didn't see it (much) sooner. The general idea with the old code is: >From several places deep in ntp_io read data into rb rb->receiver = xxx add_full_recv_buffer(rb) then way up in ntpd: rb = get_full_recv_buffer() (rb->receiver)(rb) freerecvbuf(rb) So all we have to do is remove the second chunk and replace the first chunk with: read data into rb xxx(rb) freerecvbuf(rb) The first chunk actually happens in several places, one for packets, another for refclocks, ... I've got it working. I'll push in a day or so. There is lots of checking and cleanup to do. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PYTOGO
Richard Laager via devel : > On 09/18/2018 05:04 PM, Richard Laager wrote: > > I'm doing some digging, and from what I can see Debian/Ubuntu added > > support for shared linking Go libraries and then removed it a couple > > years later. I'm asking in IRC to try to get a more > > conclusive/authoritative answer. > The response on IRC was that they gave up trying to maintain dynamic > linking, due to too much ABI instability from upstream. Very believable. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SINGLEBUFFER
Thank you Hal! On Thu, Sep 20, 2018 at 4:53 PM Hal Murray via devel wrote: > > It's simple, at least conceptually. I'm embarrassed I didn't see it > (much) > sooner. > > The general idea with the old code is: > > From several places deep in ntp_io > read data into rb > rb->receiver = xxx > add_full_recv_buffer(rb) > > then way up in ntpd: > rb = get_full_recv_buffer() > (rb->receiver)(rb) > freerecvbuf(rb) > > So all we have to do is remove the second chunk and replace the first > chunk > with: > read data into rb > xxx(rb) > freerecvbuf(rb) > > The first chunk actually happens in several places, one for packets, > another > for refclocks, ... > > I've got it working. I'll push in a day or so. There is lots of checking > and > cleanup to do. > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ntpq quirks
Anybody familiar with the retransmission code? It seems to hang occasionally. A wild guess, there is some backoff code in there that increases the retransmission timer. That's good. I'm guessing that my problem is that the timer gets too big. It's not actually hanging, just running very very very slowly. I have a script that grabs lots of data from a remote site. It should date a few minutes. It took 12 hours. That's 83K slots from the mru list. /usr/local/bin/ntpq -nc "mru mincount=1000 sort=avgint" -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
