Re: Proposed argument changes to ntpq (fixing bug #319)
Yo Eric! On Wed, 7 Jun 2017 22:46:42 -0400 "Eric S. Raymond" wrote: > Gary E. Miller via devel : > > Just make the filename optional. So -l or -l filename > > Sadly, not practical with any varint of C or Python getopt. We'd have > to roll our own, and that way madnes lies. man geetopt: "If such a character is followed by a colon, the option requires an argu‐ ment, so getopt() places a pointer to the following text in the same argv-element, or the text of the following argv-element, in optarg. Two colons mean an option takes an optional arg;" 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 pgpO0sSufhe0Z.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
Can anybody confirm that Solaris really doesn't have time stamps? I thought we decided that all modern OSes did. That's why we could rip out the SIGIO stuff. I took a quick google and couldn't find any mention of anything that looked like a time stamp in a Solaris man page for setsockopt. But some of the stuff I was looking at was surprisingly old. If Solaris doesn't support time stamps, I would expect ntp_packetstamp to die on a #error. What happened with it? If it does support time stamps, how are we supposed to read them? There are a bunch of CMSG macros over in ntp_packetstamp. They are useless without those missing symbols so it should have barfed there too. > So the fix is prolly to revert Commit a893edc7fa5fdf05b7558c46b2e83db9c7a0881 > b. I think we should try to go forward. That commit made time stamps work in most other OSes. I think we really want that. The rest of the code is somewhat prepared for this. If an OS doesn't support time stamps, we can go back to using the time-after-select without a lot of work. I think we want to document which OSes are broken. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
If you are looking at ntpq, it would be nice if there was a simple way to see the packets sent/received and not much else. A few of the packets have binary data. It may be as simple as only assoc IDs are in binary. Everything else is raw ascii so it doesn't need any complicated parsing or reformatting. We need wire packets rather than logical/assembled packets. This won't show fragmentation on the wire, but there is a reassembly layer in ntpq and I want to see the packets below that layer. [Context is retransmission bugs in ntpq.] -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
On 06/08/2017 03:22 AM, Hal Murray wrote: If you are looking at ntpq, it would be nice if there was a simple way to see the packets sent/received and not much else. A few of the packets have binary data. It may be as simple as only assoc IDs are in binary. Everything else is raw ascii so it doesn't need any complicated parsing or reformatting. We need wire packets rather than logical/assembled packets. This won't show fragmentation on the wire, but there is a reassembly layer in ntpq and I want to see the packets below that layer. [Context is retransmission bugs in ntpq.] I've been considering something like this as well, context of creating tests for the packet handling code. -- In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys. -- Andrew Ryan ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
Gary E. Miller via devel : > Yo Eric! > > On Wed, 7 Jun 2017 22:46:42 -0400 > "Eric S. Raymond" wrote: > > > Gary E. Miller via devel : > > > Just make the filename optional. So -l or -l filename > > > > Sadly, not practical with any varint of C or Python getopt. We'd have > > to roll our own, and that way madnes lies. > > man geetopt: > > "If such a character is followed by a colon, the option requires an > argu‐ ment, so getopt() places a pointer to the following text in the > same argv-element, or the text of the following argv-element, in optarg. > Two colons mean an option takes an optional arg;" man getopt gets you the documentation of the *shell* getopt. Not useful here. Mind you I didn't know it had this capability, so I learned something. -- http://www.catb.org/~esr/";>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. signature.asc Description: PGP signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
Hal Murray via devel : > Can anybody confirm that Solaris really doesn't have time stamps? I thought > we decided that all modern OSes did. That's why we could rip out the SIGIO > stuff. > > I took a quick google and couldn't find any mention of anything that looked > like a time stamp in a Solaris man page for setsockopt. But some of the > stuff I was looking at was surprisingly old. > > If Solaris doesn't support time stamps, I would expect ntp_packetstamp to die > on a #error. What happened with it? I factored the code so that if waf configure doesn't find a way to get packet arrival times from the UDP layer it uses the arrival time collected in userspace (ntp_packetstamp() isn't called or even built). So the loss is exactly the lag in the network stack. -- http://www.catb.org/~esr/";>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
Yo Eric!
On Thu, 8 Jun 2017 15:01:55 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Yo Eric!
> >
> > On Wed, 7 Jun 2017 22:46:42 -0400
> > "Eric S. Raymond" wrote:
> >
> > > Gary E. Miller via devel :
> > > > Just make the filename optional. So -l or -l filename
> > >
> > > Sadly, not practical with any varint of C or Python getopt. We'd
> > > have to roll our own, and that way madnes lies.
> >
> > man geetopt:
> >
> > "If such a character is followed by a colon, the option requires an
> > argu‐ ment, so getopt() places a pointer to the following text in
> > the same argv-element, or the text of the following argv-element,
> > in optarg. Two colons mean an option takes an optional arg;"
>
> man getopt gets you the documentation of the *shell* getopt. Not
> useful here.
Correct, I actually did 'man -a getopt' which shows both getopt(1) and
getopt(3). I hard code the -a into my 'man'. My snippet was from
getopt(3p).
> Mind you I didn't know it had this capability, so I learned something.
Well, more to be learned, my getopt(3p) is not the same as what I see on
unix.com. The online copy did not include the snippet I quoted. You
can confirm on the POSIX site for getopt(3P):
http://www.unix.com/man-page/posix/3p/getopt/
But they both had this snippet:
"A (':') shall be returned if getopt() detects a missing
argument and the first character of optstring was a (':')."
So optional optarg can be valid POXIX.
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
pgpKZPoy87GE5.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
>> If Solaris doesn't support time stamps, I would expect >> ntp_packetstamp to die on a #error. What happened with it? > I factored the code so that if waf configure doesn't find a way to get > packet arrival times from the UDP layer it uses the arrival time collected > in userspace (ntp_packetstamp() isn't called or even built). So the loss is > exactly the lag in the network stack. The "lag" is only under light load. Round up if a second packet arrives while ntpd is working on the first packet (or refclock) or the OS scheduler decides it has something more important to do. I can't find any hints of that sort of test in wscript or ntpd/wscript. There was a blizzard of ifdefs in ntp_packetstamp that would do what you describe. I think. The code was close to impossible to understand but there wasn't anything else it could do. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
Hal Murray : > > >> If Solaris doesn't support time stamps, I would expect > >> ntp_packetstamp to die on a #error. What happened with it? > > > I factored the code so that if waf configure doesn't find a way to get > > packet arrival times from the UDP layer it uses the arrival time collected > > in userspace (ntp_packetstamp() isn't called or even built). So the loss is > > exactly the lag in the network stack. > > The "lag" is only under light load. Round up if a second packet arrives > while ntpd is working on the first packet (or refclock) or the OS scheduler > decides it has something more important to do. True. The packet-processing path is pretty fast, though. Jitter due to the scheduler probably dominates. I judged this was acceptable at modern tick rates, though it would not have been when ntpd was built. > I can't find any hints of that sort of test in wscript or ntpd/wscript. > > There was a blizzard of ifdefs in ntp_packetstamp that would do what you > describe. I think. The code was close to impossible to understand but there > wasn't anything else it could do. You're right. I had forgotten that waf isn't doing this directly. -- http://www.catb.org/~esr/";>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
Gary E. Miller via devel :
> Well, more to be learned, my getopt(3p) is not the same as what I see on
> unix.com. The online copy did not include the snippet I quoted. You
> can confirm on the POSIX site for getopt(3P):
>
> http://www.unix.com/man-page/posix/3p/getopt/
>
> But they both had this snippet:
>
> "A (':') shall be returned if getopt() detects a missing
> argument and the first character of optstring was a (':')."
>
> So optional optarg can be valid POXIX.
I didn't know that. Thanks.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
signature.asc
Description: PGP signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
On 06/08/2017 02:48 PM, Eric S. Raymond via devel wrote:
Gary E. Miller via devel :
Well, more to be learned, my getopt(3p) is not the same as what I see on
unix.com. The online copy did not include the snippet I quoted. You
can confirm on the POSIX site for getopt(3P):
http://www.unix.com/man-page/posix/3p/getopt/
But they both had this snippet:
"A (':') shall be returned if getopt() detects a missing
argument and the first character of optstring was a (':')."
So optional optarg can be valid POXIX.
I didn't know that. Thanks.
Unfortunately the documentation / StackOverflow questions / library code
I've been able to find indicate that this feature does not exist in
python's getopt.
--
In the end; what separates a Man, from a Slave? Money? Power?
No. A Man Chooses, a Slave Obeys. -- Andrew Ryan
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | ntpq: -d -d != -D2 (#319)
Yo Ian! On Thu, 08 Jun 2017 20:27:50 + Ian Bruene wrote: > The "DNS[...]" bug is fixed in !483, the rest of the fix requires > change in the debugging flags. Once some sort of agreement is arrived > at on the devlist. So, what do you think is still unresolved? 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 pgpGna7AGSoSl.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
Yo Ian!
On Thu, 8 Jun 2017 15:29:19 -0500
Ian Bruene via devel wrote:
> >> "A (':') shall be returned if getopt() detects a missing
> >> argument and the first character of optstring was a (':')."
> >>
> >> So optional optarg can be valid POXIX.
> > I didn't know that. Thanks.
>
> Unfortunately the documentation / StackOverflow questions / library
> code I've been able to find indicate that this feature does not exist
> in python's getopt.
NTPsec does not use Python's getopt(). It uses argparse().
https://docs.python.org/3/library/argparse.html
Of interest is Argumentparser.add_argument():
https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument
Check out the second bullit under 16.4.3.3 nargs:
"'?'. One argument will be consumed from the command line if possible,
and produced as a single item. If no command-line argument is present,
the value from default will be produced. "
Then example code for what I suggested.
Simplied example code here:
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--foo', nargs='?', const='c', default='d')
_StoreAction(option_strings=['--foo'], dest='foo', nargs='?', const='c',
default='d', type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args(['--foo', 'YY'])
Namespace(foo='YY')
>>> parser.parse_args(['--foo'])
Namespace(foo='c')
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
pgpc3Cy68Jp5D.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | ntpq: -d -d != -D2 (#319)
On 06/08/2017 05:18 PM, Gary E. Miller via devel wrote: So, what do you think is still unresolved? At this point I think we have solved it, simply by eliminating the alternatives. It's all part of the ntpq flag discussion. -- In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys. -- Andrew Ryan ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | ntpq: -d -d != -D2 (#319)
Yo Ian! On Thu, 8 Jun 2017 17:31:01 -0500 Ian Bruene via devel wrote: > On 06/08/2017 05:18 PM, Gary E. Miller via devel wrote: > > So, what do you think is still unresolved? > > At this point I think we have solved it, simply by eliminating the > alternatives. It's all part of the ntpq flag discussion. I think we are out of sync email-wise. I sent how to use Python argparse to implement optional arguments. 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 pgpjkDSpPRqrh.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
On 06/08/2017 05:29 PM, Gary E. Miller via devel wrote: NTPsec does not use Python's getopt(). It uses argparse(). So the real alternatives here are: 1. Have the dual -l/-L flags 2. Convert ntpq from getopt to argparse -- In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys. -- Andrew Ryan ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
Yo Ian! On Thu, 8 Jun 2017 17:34:27 -0500 Ian Bruene via devel wrote: > On 06/08/2017 05:29 PM, Gary E. Miller via devel wrote: > > NTPsec does not use Python's getopt(). It uses argparse(). > > So the real alternatives here are: > > 1. Have the dual -l/-L flags Yuck. Non orthogonal to ntpd. Allows conflicting options on same command line. > 2. Convert ntpq from getopt to argparse Which I've wanted for a while, it is vastly better than Python getopt. Python getopt confuses people that expect it to behave like POSIX getopt. arparse is already used in these programs: contrib/ntpheatusb contrib/ntpheat ntpclients/ntplogtemp ntpclients/ntpviz ntpclients/ntploggps A big win is that argparse automagically creates usage() for you. Another is the ability to put options in a command file. 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 pgpQYmxkJ30vR.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
✘Solaris ?
Yo Hal! Can you please look at issue #343? Your commit broke the Solaris build. https://gitlab.com/NTPsec/ntpsec/issues/342 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 pgpsOyS2yv5JC.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
On Thu, Jun 08, 2017 at 12:26:21AM -0700, Hal Murray via devel wrote: > Can anybody confirm that Solaris really doesn't have time stamps? I thought > we decided that all modern OSes did. That's why we could rip out the SIGIO > stuff. > > I took a quick google and couldn't find any mention of anything that looked > like a time stamp in a Solaris man page for setsockopt. But some of the > stuff I was looking at was surprisingly old. > > If Solaris doesn't support time stamps, I would expect ntp_packetstamp to die > on a #error. What happened with it? If it does support time stamps, how are > we supposed to read them? There are a bunch of CMSG macros over in > ntp_packetstamp. They are useless without those missing symbols so it should > have barfed there too. Newer versions of Solaris support SO_TIMESTAMP per: https://docs.oracle.com/cd/E19957-01/820-0724/gcoqs/index.html http://www.theptpguy.net/posts/2017/05/25/ptpd-on-legacy-systems-solaris-10-part-1-how-we-got-there https://docs.oracle.com/cd/E36784_01/html/E36875/setsockopt-3socket.html#REFMAN3Bsetsockopt-3socket This matches what I see in the Solaris 11u3 VM that I have connected to Buildbot. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
Yo Matthew! On Thu, 8 Jun 2017 20:47:51 -0400 Matthew Selsky via devel wrote: > Newer versions of Solaris support SO_TIMESTAMP per: So why does the compile failt on buildbot? Is buildbot on an old version? 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 pgpSnIG1ewvOr.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposed argument changes to ntpq (fixing bug #319)
Ian Bruene via devel : > > > On 06/08/2017 05:29 PM, Gary E. Miller via devel wrote: > >NTPsec does not use Python's getopt(). It uses argparse(). > > So the real alternatives here are: > > 1. Have the dual -l/-L flags > > 2. Convert ntpq from getopt to argparse Ian, I'm going to mutter that I think argparse is overengineered and baroque, and then assign you to 1. do an evaluation of the alternatuves to devel list, and 2. make a decision and explain it. This is a training exercise; you will need to learn to navigate these kinds of tradeoffs (KISS vs. featurefulness) in the future. I am less concerned with what decision you make than with the quality of your fact-gathering and reasoning. It is possible that I will override your decision, but unlikely: one of the things that makes this a good exercise is that it is not a slam-dunk in either direction. -- http://www.catb.org/~esr/";>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SolarisMime-Version: 1.0
> Can you please look at issue #343? Your commit broke the Solaris build. > https://gitlab.com/NTPsec/ntpsec/issues/342 I'll respond under the Re: USE_PACKET_TIMESTAMP thread. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: USE_PACKET_TIMESTAMP
Thanks for fixing this. Can you verify that it works as well as builds? > Newer versions of Solaris support SO_TIMESTAMP per: > https://docs.oracle.com/cd/E19957-01/820-0724/gcoqs/index.html That has a link to a setsockopt man page which says: SunOS 5.11 Last Revised 21 Jan 2007 It doesn't say anything about SO_TIMESTAMP The recvmsg man page SunOS 5.11 Last Revised 27 Feb 2006 It has some info about SO_TIMESTAMP, but I don't see any hints about the CMSG macros. -- Can somebody give me a lesson in Solaris. Are we interested in supporting any versions that are not new enough to support SO_TIMESTAMP? Are there any other OSes/distros that we are likely to have troubles with? Do we have a list of OSes/distros and versions that we are known to work on? How old is the oldest one? ... What should I be asking? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
