On Tue, Jul 06, 2021 at 12:18:26PM -0500, Richard Laager via devel wrote:
> On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote:
> > > There is a close-to-RFC to handle this area. "Interleave" is the
> > > buzzword. I
> > > haven't studied it. The idea is to grab a transmit time stamp, then
> >
On Mon, Mar 22, 2021 at 02:24:50PM -0700, Hal Murray via devel wrote:
>
> Since you mentioned PTP, can we use the PTP time stamping stuff to get better
> time stamps for NTP packets? (without dragging in any/much PTP stuff)
NTP can make use of some of the features that PTP hardware supports.
NT
On Mon, Jun 15, 2020 at 11:54:57PM -0700, Hal Murray via devel wrote:
>
> They are up to alpha3. I've been trying it.
>
> I added a tweak to wscript to support this, and some notes in HOWTO-OpenSSL
> That recipe also works for getting 1.1.1 on old systems so they can use NTS.
>
> -
>
>
On Fri, Oct 25, 2019 at 01:26:53AM -0700, Hal Murray via devel wrote:
> I haven't seen any examples of OpenSSL on distros that are so old that they
> don't support TLS 1.2
TLS 1.2 got added in 1.0.1, which was released in 2012. I'm
guessing there are some old redhat versions that are still
suppor
On Sat, Mar 30, 2019 at 08:05:41PM -0700, Hal Murray wrote:
> > A sockaddr is not meant to store the address, ...
>
> But the API wants a sockaddr.
>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
> There is no hint in the man page that an IPv6 address won't fit.
>
> so
On Sat, Mar 30, 2019 at 02:35:18PM -0700, Hal Murray via devel wrote:
> I just pushed a fix. It was an interesting quirk. The API for accepet
> includes a pointer and length to a place to put the IP Address of the remote
> site. The type of that place is struct sockaddr. sockaddr is generic,
On Mon, Mar 25, 2019 at 04:00:23AM -0700, Hal Murray via devel wrote:
>
> I thought it had been removed.
>
> Job #183497467 ( https://gitlab.com/NTPsec/ntpsec/-/jobs/183497467 )
>
> Stage: build
> Name: debian-oldoldstable-refclocks
> Trace: Err http://deb.debian.org oldoldstable-updates/main am
On Sun, Mar 03, 2019 at 03:30:53PM -0800, Gary E. Miller via devel wrote:
> Yo Kurt!
>
> On Mon, 4 Mar 2019 00:19:44 +0100
> Kurt Roeckx via devel wrote:
>
> > > Actually getting timestamps from the NIC is fairly involved. The NIC
> > > has its own clock and
On Sun, Mar 03, 2019 at 05:59:11PM -0500, Daniel Franke wrote:
> On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote:
> > On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
> > >
> > > k...@roeckx.be said:
> > > > If this is something you&#x
On Sun, Mar 03, 2019 at 10:25:31PM +0100, Achim Gratz via devel wrote:
> Kurt Roeckx via devel writes:
> > I don't see how it can work with the current pool system. You look
> > something up like pool.ntp.org and get some IP addresses. But none
> > of those will have a ce
On Sun, Mar 03, 2019 at 08:56:55PM +0100, Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > There is no security in the pool anyway, so let's put that discussion
> > aside for a while.
>
> I'd take exception with that statement. If the pool was upgraded to use
> NTS one way or the o
On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > If this is something you're worried about, this can be solved with the
> > interleave mode, which was removed.
>
> How well does it work?
It works great, the errors are much smaller when it's enabled.
> Is
On Sat, Mar 02, 2019 at 09:23:51PM -0800, Hal Murray via devel wrote:
> *) There is actually one interesting point that authentication makes more
> interesting. On receive, we get a time stamp when the packet arrives. We
> can
> take all day to inspect the packet and run authentication code.
On Wed, Feb 06, 2019 at 10:31:39PM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > Please use 0 instead of TLS_MAX_VERSION, it means the same. I've marked
> > TLS_MAX_VERSION for deprecation.
>
> Thanks for the heads up.
>
> Is there any documentation on that? (man page?)
There is SSL_C
On Wed, Feb 06, 2019 at 02:05:27PM -0800, Hal Murray via devel wrote:
>
> float mintls = 1.2; /* minimum TLS version allowed */
> float maxtls; /* maximum TLS version allowed */
>
> Floats? The API to OpenSSL doesn't work in floats. We'll have to translate
> those
On Sun, Feb 03, 2019 at 03:15:55PM -0600, Richard Laager via devel wrote:
> On 2/3/19 1:01 PM, Eric S. Raymond wrote:
> > I guess it will have to be an empty string that disables encryption.
>
> I'm not sure if you wrote this before the recent messages on the NULL
> ciphers. But you said you were
On Sat, Feb 02, 2019 at 05:52:25PM -0500, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
> > "Eric S. Raymond via devel" wrote:
> >
> > > NEVER CONFIGURE WHAT YOU CAN DISCOVER
> > >
> > > These are from nts.adoc:
> > >
> > > *tls1
and to increase unpredictability.
[Paul Dale, Benjamin Kaduk, Kurt Roeckx, Rich Salz, Matthias St. Pierre]
(I guess I need to change this, the last line is not true
anymore.)
The RAND_keep_random_devices_open manpage can be seen here:
https://www.openssl.org/docs/manmaster/man3/RAND_k
On Fri, Jul 06, 2018 at 01:27:30PM -0700, Hal Murray via devel wrote:
> Also, it didn't check the return code. That raises an interesting question.
> What should we do if there isn't enough entropy?
>
> How much entropy is there in a typical system? Can a malicious user use it
> all up? Coul
On Tue, May 29, 2018 at 03:15:15PM -0400, Eric S. Raymond via devel wrote:
> [[interface]]
> +interface+ [+listen+ | +ignore+ | +drop+] [+all+ | +ipv4+ | +ipv6+ |
> +wildcard+ | 'name' | 'address'[/'prefixlen']]::
> This command controls which network addresses +ntpd+ opens, and
> whether inpu
On Fri, Jan 05, 2018 at 02:41:39PM -0800, Hal Murray wrote:
>
> > I have no idea how it's used in NTP. But I understand it's some kind of
> > shared password? You should clearly look in how it's being used and if that
> > actually makes sense. Maybe it needs more than just replacing the hash
> > a
On Fri, Jan 05, 2018 at 04:24:01PM -0500, Eric S. Raymond wrote:
> Kurt Roeckx :
> > On Fri, Jan 05, 2018 at 10:04:44AM -0500, Eric S. Raymond via devel wrote:
> > > > MD5 is no longer considered safe.
> > > > Is SHA1 considered safe? What other types shoul
On Fri, Jan 05, 2018 at 10:04:44AM -0500, Eric S. Raymond via devel wrote:
> > MD5 is no longer considered safe.
> > Is SHA1 considered safe? What other types should we test and/or suggest
> > people use?
>
> No, SHA1 is no longer considered safe. The first collision was generated
> early last
On Sun, Dec 03, 2017 at 02:43:04PM -0500, Eric S. Raymond via devel wrote:
> All hands alert. We have our first, or maybe second depending on how
> you count, serious bug. About 33% of the time, NTPsec is eliciting bad
> packets from Amazon time service. Classic does not have this problem.
I woul
On Sat, Nov 25, 2017 at 01:26:18AM -0800, Hal Murray via devel wrote:
> (gdb) bt
> #0 0x76ebf104 in futex_wake (private=0, processes_to_wake=2147483647,
> futex_word=0x76eaf618) at ../sysdeps/unix/sysv/linux/futex-internal.h:231
> #1 __pthread_once_slow (once_control=0x76eaf618, init_routine
On Sat, Nov 25, 2017 at 05:09:02AM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > This means that when we initialize a global variable we use the
> > pthread_once() function, which internally uses the futex to do that. It's
> > not using threads itself, it's just making sure that if you use
On Mon, Apr 24, 2017 at 10:07:47AM -0700, Gary E. Miller wrote:
> frequency offset:
> The difference between the ntpd calculated frequency and the local system
> clock frequency (usually in parts per million, ppm)
> jitter, dispersion:
> The short term change in a value
For me jitter is a
On Mon, Apr 24, 2017 at 12:36:17PM -0400, Eric S. Raymond wrote:
> Having almost recovered from post-viral fatigue syndrome, I have
> enough energy to work now and am attempting to clear out my old
> project-related mail. I'd like to have my decks cleared for the
> face-to-face team meeting this c
On Mon, Apr 17, 2017 at 06:41:01PM -0700, Hal Murray wrote:
> I think we can kill two birds with one stone.
>
> The first step is to change the code that uses __DATE__ to use the time stamp
> from autorevision.
Have you seen
https://reproducible-builds.org/specs/source-date-epoch/ ?
Kurt
On Fri, Mar 31, 2017 at 07:30:05PM -0400, Eric S. Raymond wrote:
> Kurt Roeckx :
> > > One might expect this to be available via a CMSG lookup into recmvsg's
> > > per-package auxiliary headers, analogously to the way we now get the
> > > packet-arrival ti
On Thu, Mar 30, 2017 at 12:06:36PM -0400, Eric S. Raymond wrote:
> Head up, Mark! Policy issue.
>
> I fear the wildcard-socket simplification, last of our pre-1.0 major
> ambitions, has just hit a wall.
>
> The problem is not with the code simplification itself. The problem is
> that there is a
On Sun, Jan 29, 2017 at 10:44:49PM +0100, Kurt Roeckx wrote:
> On Sun, Jan 29, 2017 at 09:09:56PM +, Greg Rubin wrote:
> > Mind running the timings with the legacy interfaces as well? We may
> > determine that the speed benefits are outweighed by the risks and
> > complex
On Sun, Jan 29, 2017 at 09:09:56PM +, Greg Rubin wrote:
> Mind running the timings with the legacy interfaces as well? We may
> determine that the speed benefits are outweighed by the risks and
> complexities of an older API, but it would be good to have the data so we
> can make an informed d
On Sat, Jan 28, 2017 at 12:48:34PM -0800, Gary E. Miller wrote:
> Yo Hal!
>
> On Sat, 28 Jan 2017 12:39:02 -0800
> Hal Murray wrote:
>
> > Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
> > Stdlib: 100 calls to rand() took 0.021 microseconds each
> > Sodium: 100 calls to randombytes_buf() took
On Fri, Jan 27, 2017 at 03:00:42PM -0800, Hal Murray wrote:
>
> fallenpega...@gmail.com said:
> > How hard would the following be?
> > Just go ahead and add SHA256 to NTPsec then Write an I-D modifying the NTP4
> > protocol documenting it. then Write a patch to NTP classic for it.
> > (yes, I know
On Fri, Jan 27, 2017 at 03:42:09PM -0500, Eric S. Raymond wrote:
> Daniel Franke :
> > Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
> > support any time soon? That's inconceivable to me.
>
> I think it was either Achim Gratz or Kurt Roecx (I can't easily search to fin
On Fri, Jan 27, 2017 at 08:38:06PM +0100, Achim Gratz wrote:
> Eric S. Raymond writes:
> > It depends on which MAC algorithms we want to support, a question I've
> > opened
> > in a recent email. It looks like libsodium's support for hash functions in
> > our set is limited to SHA-2, so libsodium
On Wed, Jan 25, 2017 at 01:14:50PM -0500, Eric S. Raymond wrote:
> Kurt Roeckx :
> > All my real amd64 boxes show:
> > [0.540511] Switched to clocksource hpet
> > [3.327348] Switched to clocksource tsc
> >
> > But my armel shows:
> >
On Tue, Jan 24, 2017 at 10:38:50PM +0100, Achim Gratz wrote:
> sys_fuzz (which whitens the quantization noise on the clock reading)
> doesn't make a difference or you might not. But presumably Dave Mills
> didn't put it in there just because he was trying to add useless code.
So it seems to me th
On Wed, Jan 25, 2017 at 02:12:05AM -0800, Hal Murray wrote:
> I think kernels went through 3 stages:
>
> Old old kernels were very coarse. They bumped the clock on an interrupt.
> End of story.
>
> Old kernels use the TSC (or equivalent) to interpolate between interrupts.
> (A comment from M
On Fri, Jan 20, 2017 at 05:39:37PM -0800, Gary E. Miller wrote:
> Yo Kurt!
>
> On Sat, 21 Jan 2017 01:23:47 +0100
> Kurt Roeckx wrote:
>
> > On Fri, Jan 20, 2017 at 12:44:38PM -0800, Gary E. Miller wrote:
> > > Imagine in front of you are two handheld voltmeter
On Fri, Jan 20, 2017 at 12:44:38PM -0800, Gary E. Miller wrote:
> Imagine in front of you are two handheld voltmeters, and a super
> precision voltage source.
So let me correct all those terms to what people normally use them
for.
You have a voltmeter those shows volt with 3 digits behind the
dec
On Thu, Jan 19, 2017 at 05:03:29PM -0800, Gary E. Miller wrote:
> > > > > A signal on a USB 2.0 bus can only have a resolution of about 1
> > > > > micro Second, but that can be locked to a PPS to 100 micro
> > > > > Seconds jitter.
> > > >
> > > > I'm not sure what you're trying to say.
> >
On Thu, Jan 19, 2017 at 02:40:08PM -0800, Gary E. Miller wrote:
> > > I'm worried about 1 micro Second or less. And one should not
> > > confuse accuracy with resolution. A PPS signal only has a
> > > resolution of one Second, but can eaaily have an accuracy of 10
> > > nano seconds.
> >
> > P
On Thu, Jan 19, 2017 at 01:00:50PM -0800, Gary E. Miller wrote:
> Yo Kurt!
>
> On Thu, 19 Jan 2017 21:20:23 +0100
> Kurt Roeckx wrote:
>
> > On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote:
> > > Gary E. Miller :
> > > > &
On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote:
> Gary E. Miller :
> > > - to fuzz the low-order bits of the clock.
> >
> > Hmm, can you expand on this a bit? Which clock? How much fuzz?
> > Does this degrade anything?
>
> Whenever ntpd polls the system clock, it fuzzes the low
On Thu, Jan 19, 2017 at 01:32:20PM -0500, Eric S. Raymond wrote:
> > INSTALL says:
> > Debian: libsodium
> >
> > apt-get install on my debian box says:
> > E: Unable to locate package libsodium
>
> Running Wheezy, I take it?
It's libsodium-dev
Kurt
_
On Mon, Jan 09, 2017 at 08:22:42PM +0100, Achim Gratz wrote:
> Eric S. Raymond writes:
> > Good idea. I'd do it something like this:
> >
> > 1. Every time we ship a packet, take timestamps at the beginning and end of
> > the
> > critical region.
>
> If it is possible to get the actual time the p
On Sun, Jan 08, 2017 at 04:53:57PM -0800, Gary E. Miller wrote:
> Yo All!
>
> On Mon, 9 Jan 2017 01:30:30 +0100
> Kurt Roeckx wrote:
>
> > > That said, I continue to admire your cut right to the heart of the
> > > issue. ntpd spends enough time in I/O waits
On Sun, Jan 08, 2017 at 03:51:13PM -0800, Hal Murray wrote:
>
> We should measure the time from grabbing the time stamp to sending the
> packet. That might include some crypto. We might get better results by
> adjusting the time stamp to compensate for that.
Adjusting the timestamp to when yo
On Sun, Jan 08, 2017 at 06:02:36PM -0500, Eric S. Raymond wrote:
> Hal Murray :
> > We don't care about the timing in most of the code. The only critical
> > section is the chunk between grabbing the time and sending the packet.
> > That
> > chunk is likely to involve crypto.
> >
> > We could
On Sun, Jan 08, 2017 at 02:37:43PM -0800, Hal Murray wrote:
>
> >> OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon
> >> then the daemon can tolerate 'some' jitter.
>
> > In normal operation we can expect lots of pairs of small allocations at UDP
> > datagram sizes with dea
On Sun, Jan 08, 2017 at 03:59:51PM -0500, Eric S. Raymond wrote:
> Susan and I have decided to revive an old idea we were originally going
> to do in Python and implement it in Rust instead - a better IRC
> server. Susan has years of field experience with IRC servers written
> in C and says they'r
On Sun, Jan 08, 2017 at 02:12:21PM -0500, Eric S. Raymond wrote:
> Kurt Roeckx :
> > I had a quick look at some of the stats of my peers over internet,
> > and most actually seem to have an average jitter in the order of
> > around 100 microseconds. Some are lower, some are h
On Sun, Jan 08, 2017 at 07:11:22PM +0100, Kurt Roeckx wrote:
> On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote:
> > On the other hand, I don't consider requiring a runtime to be an
> > *intrinsic* disqualifier. The real question is, in my view, the
> >
On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote:
> On the other hand, I don't consider requiring a runtime to be an
> *intrinsic* disqualifier. The real question is, in my view, the
> 95th-percentile length of latency-inducing stop-the-world stalls.
> If it's below 100 microseconds
On Sun, Jan 08, 2017 at 06:35:58AM -0800, Hal Murray wrote:
>
> >> Using the term PLL.
> > But that's how the code is organized. In the absence of a PLL it doesn't
> > slew. Or am I missing something here?
>
> (at least) One of us is confused.
>
> The text from the blog:
> > There are two kin
On Sun, Jan 08, 2017 at 12:40:45AM -0500, Eric S. Raymond wrote:
> Hal Murray :
> >
> > I don't understand your section about the PLL. I think it's tangled up in
> > some bogus terminology. If you say a bit more, I'll try to sort things out.
>
> Alas, "say more" is not really actionable advice
On Fri, Jan 06, 2017 at 11:43:01PM -0500, Eric S. Raymond wrote:
> (mutt hiccupped. You might see this twice.)
>
> Kurt Roeckx :
> > On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote:
> > > and the other is ripping out all
> > > the interface-scannin
On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote:
> and the other is ripping out all
> the interface-scanning stuff so we lose the dependency on
> getifaddrs(3) and use wildcard interfaces only.
Are you sure this is going to work? As far as I know there are (or
were) good reasons to
On Sat, Dec 17, 2016 at 07:03:16PM -0800, Gary E. Miller wrote:
> Yo All!
>
> On Sat, 17 Dec 2016 17:56:32 -0800
> "Gary E. Miller" wrote:
>
> > # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:"
> >
> > And I do indeed get odd results. Some on my local network...
>
> To f
On Mon, Nov 21, 2016 at 02:11:12PM -0900, Royce Williams wrote:
>
> If those minimal changes are turned into a compile-time option, this
> would enable adding fuzzing to the rolling test suite, perhaps using
> some of Susan's resources.
Google also provides resources via oss-fuzz. If you can read
On Fri, Sep 23, 2016 at 01:41:07PM -0500, Joel Sherrill wrote:
> On Fri, Sep 23, 2016 at 1:08 PM, Gary E. Miller wrote:
>
> > Yo Eric!
> >
> >
> > > These are valid because the invention and major uses of u_long in this
> > > codebase predate the 64-bit transition - it may look like we're
> > > n
On Wed, Sep 14, 2016 at 06:00:45PM -0400, Eric S. Raymond wrote:
> Dan Drown :
> > Quoting "Eric S. Raymond" :
> > >Achim Gratz :
> > >>…or move the refclocks out of ntpd altogether and use some shared memory
> > >>or mailbox system to have ntpd have a look at the timestamp stream from
> > >>each r
On Wed, Sep 14, 2016 at 04:40:57PM -0500, Dan Drown wrote:
>
> This page from cloudflare does a nice job of describing the limitations of a
> single process UDP receive model:
> https://blog.cloudflare.com/how-to-receive-a-million-packets/
>
> The limit they hit with their hardware was around 370
On Mon, Aug 15, 2016 at 01:26:31PM -0700, Hal Murray wrote:
>
> k...@roeckx.be said:
> > However, I already get a /usr/share/zoneinfo/leap-seconds.list from the
> > tzdata package that updates the timezone information and I should probably
> > look into using that file to update things. Those file
On Mon, Aug 15, 2016 at 11:14:10AM -0400, Eric S. Raymond wrote:
> Mark Atwood :
> > Let's do that! Hal, others, do you happen to have copies of all the past
> > leap files, so we can synthesize a git history for it?
>
> We don't need all the past leap files. The data is only ever modified by
> a
On Mon, Aug 15, 2016 at 08:37:14AM -0400, Eric S. Raymond wrote:
> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > While I accept this as a general principle, is there anything about the
> > > new
> > > ntpleapfetch that inflicts a heavier load than the old ntpleapfetch has
> > > been
> > > ca
On Sun, Aug 14, 2016 at 03:49:15PM -0700, Hal Murray wrote:
> Matt Selsky is working on Pythonizing the script that grabs a new leap second
> file. The idea is to run a cron job that keeps it up to date. That opens an
> interesting can of worms.
I've been pondering about using ntp-classic's sc
On Sat, Jun 25, 2016 at 06:13:56PM -0400, Eric S. Raymond wrote:
> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > 1. Apply Classic's workaround for the problem, which I don't remember the
> > > details of but involved some dodgy nonstandard linker hacks done through
> > > the
> > > build syste
On Sat, Jun 25, 2016 at 11:00:39AM -0400, Eric S. Raymond wrote:
>
> While this did enable me to recover from my errors, it also turned up
> a serious problem. The combination of the buggy async-DNS code we
> inherited from Classic and use of pool servers causes *very* frequent
> crashes.
Can yo
On Tue, May 24, 2016 at 02:38:23PM -0700, Gary E. Miller wrote:
> Yo Eric!
>
> On Tue, 24 May 2016 17:33:06 -0400
> "Eric S. Raymond" wrote:
>
> > Hal Murray :
> > >
> > > e...@thyrsus.com said:
> > > > See my reply to Gary and your text about NATs and firewalls.
> > > > Nobody has convinced
On Mon, May 23, 2016 at 02:38:42PM -0700, Hal Murray wrote:
>
> fallenpega...@gmail.com said:
> > There should be a tag in gitlab. If there is not, it is my mistake, and I
> > will fix it this evening. ..m
>
> k...@roeckx.be said:
> > There are also no releases on ftp://ftp.ntpsec.org/pub/rel
On Mon, May 23, 2016 at 08:51:06PM +, Mark Atwood wrote:
> There should be a tag in gitlab. If there is not, it is my mistake, and I
> will fix it this evening. ..m
There are also no releases on ftp://ftp.ntpsec.org/pub/releases/,
0.9.1 is the latest.
Kurt
___
On Mon, Mar 21, 2016 at 09:47:27PM +0100, Kurt Roeckx wrote:
> A few things that I think you can improve is a download link
> somewhere on the website. It would also be nice if you provide a
> SHA256 sum of that, and that someone signs the release.
You probably also want to make the
On Mon, Mar 21, 2016 at 04:20:38PM -0400, Eric S. Raymond wrote:
> Mark Atwood :
> > Speaking of which, the next cadence point release is going to be next
> > Tuesday, the day after tomorrow, while I will literally be standing before
> > the LF CII making the case for our work. So, this is a real
On Sun, Mar 13, 2016 at 10:52:17PM +, Mark Atwood wrote:
> Hello Kurt,
>
> We have not yet had that discussion yet.
>
> As someone from a distribution, what would you like from NTPsec?
In the ideal world, we'd like to have some releases supported for
something like 5 years. And if you indic
On Sun, Mar 13, 2016 at 08:31:04PM +, Mark Atwood wrote:
> Hi!
>
> One of the policy mistakes that was killing MySQL 5.0, back in the day, is
> that they would not make a point release until a target feature for that
> point release was done. This was killing them/us, because of the standard
On Mon, Feb 22, 2016 at 03:39:58AM -0800, Hal Murray wrote:
>
> There are two interesting corner cases that should get documented someplace.
>
> Reading the RTC only gives you an answer to the second. You can actually get
> a lot better than that if you spin and wait for it to tick. (I careful
On Mon, Feb 22, 2016 at 03:16:54AM -0800, Hal Murray wrote:
>
> dfoxfra...@gmail.com said:
> > I've seen "precision" used both ways by different authors, but I think
> > you're right that resolution is a better choice of terminology because it
> > avoids that ambiguity.
>
> A good glossary would
On Fri, Feb 19, 2016 at 05:56:04PM -0500, Daniel Franke wrote:
> At a high level, a clock is characterized by the answers to three questions:
I guess that should be four ...
> # II - What drives it?
>
> A typical PC has several oscillators. In addition to the main one,
> which sends clock interr
On Fri, Feb 19, 2016 at 03:19:01PM -0800, Gary E. Miller wrote:
> Yo Daniel!
>
> On Fri, 19 Feb 2016 18:12:52 -0500
> Daniel Franke wrote:
>
> > On 2/19/16, Gary E. Miller wrote:
> > > No, resolution is the smallest time increment a clock can represent.
> > > Precision is a measure of the quali
On Tue, Jan 26, 2016 at 11:03:01PM +0100, Kurt Roeckx wrote:
> > I haven't found anyplace in our code that messes with the signal mask. I
> > could easily be overlooking something that will be obvious in hindsight.
>
> Maybe getnameinfo() does.
I want to add that
On Tue, Jan 26, 2016 at 01:38:52PM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > It's not clear to me when this longjmp() is called. But if changing to
> > siglongjmp() fixed it, it seems the signal handling got changed in between?
>
> It's called from the ^C signal handler. It's the b
On Tue, Jan 26, 2016 at 01:07:04PM -0800, Hal Murray wrote:
>
> The problem is that somebody is masking off SIGINT. It works if I replace
> setjmp+longjmp with sigsetjmp+siglongjmp.
>
> The SIGINT handler was getting called with SIGINT masked off. That seems a
> bit strange. It was coming fr
85 matches
Mail list logo
