Re: Heads up: USE_PACKET_TIMESTAMP tangle

2017-06-06 Thread Mark Atwood via devel
That is worth filing a bug against BSD for. On Mon, Jun 5, 2017 at 9:41 PM Hal Murray via devel wrote: > > FreeBSD supports both SO_BINTIME and SO_TIMESTAMP > > SO_BINTIME provides 32 bits of fractions of a second. > SO_TIMESTAMP provides microseconds - timeval. > > So the code is setup to prefe

Re: ✘HPUX ??

2017-06-06 Thread Mark Atwood via devel
Hilariously, I don't know where we can get a HPUX lab machine. I want to support it, but I also want us to stick to "POSIX only, unless it's really important". How much HPUX only code is there? What does it do? ..m On Tue, Jun 6, 2017 at 6:42 PM Gary E. Miller via devel wrote: > Yo All! > >

Fwd: New Defects reported by Coverity Scan for ntpsec

2017-06-06 Thread Mark Atwood via devel
- Original message - From: scan-ad...@coverity.com Subject: New Defects reported by Coverity Scan for ntpsec Date: Tue, 06 Jun 2017 15:06:19 -0700 Hi, Please find the latest report on new defect(s) introduced to ntpsec found with Coverity Scan. 1 new defect(s) introduced to ntpsec found

✘HPUX ??

2017-06-06 Thread Gary E. Miller via devel
Yo All! Does NTPsec support HPUX? I see some code that only applies to HPUX. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Verit

Re: Are we interested in supporting low resolution system clocks?

2017-06-06 Thread Eric S. Raymond via devel
Hal Murray via devel : > > > I have run tests removing the fuzz code. Never found any change with or > > without the clock fuzz. I was too scared to remove it. > > It's scattered all over the place so I'm impressed if you really removed it > all. > > The code that I was looking at in ntp_pack

Re: Are we interested in supporting low resolution system clocks?

2017-06-06 Thread Gary E. Miller via devel
Yo Hal! On Tue, 06 Jun 2017 17:23:56 -0700 Hal Murray wrote: > > I have run tests removing the fuzz code. Never found any change > > with or without the clock fuzz. I was too scared to remove it. > > It's scattered all over the place so I'm impressed if you really > removed it all. I did n

Re: Are we interested in supporting low resolution system clocks?

2017-06-06 Thread Hal Murray via devel
> I have run tests removing the fuzz code. Never found any change with or > without the clock fuzz. I was too scared to remove it. It's scattered all over the place so I'm impressed if you really removed it all. The code that I was looking at in ntp_packetstamp had a run time test. if

Re: Are we interested in supporting low resolution system clocks?

2017-06-06 Thread Eric S. Raymond via devel
Gary E. Miller via devel : > Yo Hal! > > On Tue, 06 Jun 2017 16:49:57 -0700 > Hal Murray via devel wrote: > > > ntpd has a lot of ugly code to fuzz the clock. I don't really > > understand that area. I think it makes sense if the clock has big > > ticks. Do we want to support those systems?

Re: Are we interested in supporting low resolution system clocks?

2017-06-06 Thread Gary E. Miller via devel
Yo Hal! On Tue, 06 Jun 2017 16:49:57 -0700 Hal Murray via devel wrote: > ntpd has a lot of ugly code to fuzz the clock. I don't really > understand that area. I think it makes sense if the clock has big > ticks. Do we want to support those systems? If not, I think we can > clean up a lot of

Re: Heads up: USE_PACKET_TIMESTAMP tangle

2017-06-06 Thread Gary E. Miller via devel
Yo Hal! On Tue, 06 Jun 2017 16:24:42 -0700 Hal Murray via devel wrote: > I just pushed a big cleanup. Nice. > Please test and don't be too surprised > if something breaks. I can't test with Solaris or Apple. I just tested on an up to date macOS. Breif testing looks good. RGDS GARY

Are we interested in supporting low resolution system clocks?

2017-06-06 Thread Hal Murray via devel
Old old systems just bumped the time in big steps on a timer interrupt. Most modern OSes use something like the Intel TSC for timekeeping so the clock ticks in nanosecond scale steps. ntpd has a lot of ugly code to fuzz the clock. I don't really understand that area. I think it makes sense i

Re: Heads up: USE_PACKET_TIMESTAMP tangle

2017-06-06 Thread Hal Murray via devel
I just pushed a big cleanup. Please test and don't be too surprised if something breaks. I can't test with Solaris or Apple. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/

Re: New state of the debug flags

2017-06-06 Thread Gary E. Miller via devel
Yo Ian! On Tue, 6 Jun 2017 17:10:13 -0500 Ian Bruene via devel wrote: > After consolidating the relevant macros into ntp_debug.h and cleaning > up all of the simple if(debug)s I have done another grep through the > codebase. It appears that there aren't anymore cases where it is > worth creatin

Re: New state of the debug flags

2017-06-06 Thread Eric S. Raymond via devel
Ian Bruene via devel : > > After consolidating the relevant macros into ntp_debug.h and cleaning up all > of the simple if(debug)s I have done another grep through the codebase. It > appears that there aren't anymore cases where it is worth creating a macro > for debugging. What's left is either b

New state of the debug flags

2017-06-06 Thread Ian Bruene via devel
After consolidating the relevant macros into ntp_debug.h and cleaning up all of the simple if(debug)s I have done another grep through the codebase. It appears that there aren't anymore cases where it is worth creating a macro for debugging. What's left is either blocks of custom computation,