Re: Can we assume SIGQUIT and friends are defined?

Hal Murray : > What's the story with HAVE_IO_COMPLETION_PORT? Do we know what that is for? Yes, though I could't have told you that yesterday. An IO completion part is a place where a process doing asynchronous I/O can look to see which such requests have completed,

Re: NTPsec's longer-term objectives

we are not making Rust part of NTPsec right now. but maybe in a year or so, at this pace On Mon, Sep 12, 2016, 12:54 PM Hal Murray wrote: > > e...@thyrsus.com said: > > Every Unix-like system, for sure. Checking...Rust has a Windows port. So > > does Go. Are there

Re: Can we assume SIGQUIT and friends are defined?

make sure they are defined by the posix level we are targeting On Mon, Sep 12, 2016, 4:01 PM Eric S. Raymond wrote: > Hal Murray : > > > > Our current code has ifdefs for SIGQUIT and several others. That may > have > > been leftover from Windows. > >

Re: Can we assume SIGQUIT and friends are defined?

Hal Murray : > > Our current code has ifdefs for SIGQUIT and several others. That may have > been leftover from Windows. > > man 7 signal says: >First the signals described in the original POSIX.1-1990 standard. > > > Can we remove those ifdefs? If not, what

Re: -g screqup (from IRC)

g...@rellim.com said: >> logconfig =syncall +clockall +peerall +sysall > sysall not in the ntp.conf man page. I also do not see anything related to > allow_panic that would log when the options is taken: ntp_loopfilter.c The logging stuff goes through a subroutine, one for each of the 4

Re: -g screqup (from IRC)

[to get clock-step logging] > Can you tell me which logging? Then I can test for this case. It's part of: logconfig =syncall +clockall +peerall +sysall I think it's in sysall, but I'm not sure. - >> The -g switch is supposed to be very simple. It allows a large >> initial step.

Re: -g screqup (from IRC)

Yo Hal! On Mon, 12 Sep 2016 13:26:38 -0700 Hal Murray wrote: > > 12:09:40gemiller > > | "killall ntpd; sleep 1; ntpd -N -g" > > | screws up the clock for over a day, > > | much better without the -g

-g screqup (from IRC)

> 12:09:40gemiller > | "killall ntpd; sleep 1; ntpd -N -g" > | screws up the clock for over a day, > | much better without the -g You have either found a very interesting bug or you are on a wild goose chase. The -g switch is

Re: NTPsec's longer-term objectives

e...@thyrsus.com said: > Every Unix-like system, for sure. Checking...Rust has a Windows port. So > does Go. Are there any other tarhets you're worried about? Mostly just curious. I've never used either. I see go on FreeBSD and NetBSD. I see rust on FreeBSD but not on NetBSD. -- These

Can we assume SIGQUIT and friends are defined?

Our current code has ifdefs for SIGQUIT and several others. That may have been leftover from Windows. man 7 signal says: First the signals described in the original POSIX.1-1990 standard. Can we remove those ifdefs? If not, what environment are we considering that doesn't have them?

Re: NTPsec's longer-term objectives

Hal Murray : > > e...@thyrsus.com said: > > While this is in some ways a tempting thought, I think the energy we might > > spend on this would be better directed towards a newer language that *is* > > suitable for soft realtime and has good provability properties for

Re: NTPsec's longer-term objectives

Hal Murray : > It's worth considering writing something like a ntp-lite in Python. It would > probably take a handful of shims to get at OS calls that Python doesn't > support directly. > > Consider a client-only, no refclocks implementation. The timing parts are't

Re: NTPsec's longer-term objectives

e...@thyrsus.com said: > Going forward, one of the improvements I intend to pursue is moving > everything in the suite other than ntpd itself into Python. I'd move ntpd, > too, if it were practical, but Python's virtues do not include being any > good for realtime work. It's worth considering