Date: Thu, 12 Sep 2019 14:08:39 -0600 From: Ian Lepore <ian@freebsd.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Alan Somers <asomers@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r352231 - head/lib/libc/sys Message-ID: <20f4e7af5b82e47fddf604975ff3e853c231720d.camel@freebsd.org> In-Reply-To: <201909122002.x8CK2Sxh005042@slippy.cwsent.com> References: <201909111948.x8BJmWZn092483@repo.freebsd.org> <63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org> <201909122002.x8CK2Sxh005042@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2019-09-12 at 13:02 -0700, Cy Schubert wrote: > In message < > 63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org>, > Ian Le > pore writes: > > On Wed, 2019-09-11 at 19:48 +0000, Alan Somers wrote: > > > Author: asomers > > > Date: Wed Sep 11 19:48:32 2019 > > > New Revision: 352231 > > > URL: https://svnweb.freebsd.org/changeset/base/352231 > > > > > > Log: > > > getsockopt.2: clarify that SO_TIMESTAMP is not 100% reliable > > > > > > When SO_TIMESTAMP is set, the kernel will attempt to attach a > > > timestamp a > > > > s > > > ancillary data to each IP datagram that is received on the > > > socket. Howeve > > > > r, > > > it may fail, for example due to insufficient memory. In that > > > case the > > > packet will still be received but not timestamp will be > > > attached. > > > > > > Reviewed by: kib > > > MFC after: 3 days > > > Differential Revision: https://reviews.freebsd.org/D21607 > > > > > > Modified: > > > head/lib/libc/sys/getsockopt.2 > > > > > > Modified: head/lib/libc/sys/getsockopt.2 > > > ================================================================= > > > ========== > > > > === > > > --- head/lib/libc/sys/getsockopt.2 Wed Sep 11 19:29:40 > > > 2019 (r35223 > > > > 0) > > > +++ head/lib/libc/sys/getsockopt.2 Wed Sep 11 19:48:32 > > > 2019 (r35223 > > > > 1) > > > @@ -28,7 +28,7 @@ > > > .\" @(#)getsockopt.2 8.4 (Berkeley) 5/2/95 > > > .\" $FreeBSD$ > > > .\" > > > -.Dd February 10, 2019 > > > +.Dd September 11, 2019 > > > .Dt GETSOCKOPT 2 > > > .Os > > > .Sh NAME > > > @@ -431,7 +431,8 @@ option is enabled on a > > > .Dv SOCK_DGRAM > > > socket, the > > > .Xr recvmsg 2 > > > -call will return a timestamp corresponding to when the datagram > > > was receiv > > > > ed. > > > +call may return a timestamp corresponding to when the datagram > > > was receive > > > > d. > > > +However, it may not, for example due to a resource shortage. > > > The > > > .Va msg_control > > > field in the > > > > > > > So I guess this actually happened to someone... is it a common > > thing > > for the timestamp to fail? I ask because ntpd relies on > > SO_TIMESTAMP > > and if this situation really happens and can persist for a long > > time, > > ntpd would effectively stop working. > > This reminds me, something that's been on my plate for a couple of > weeks. > Our NTP upline pinged me a few weeks ago regarding IEEE 1588 driver > support > for NICs with hardware support. Linux already has it. I was told > that > someone hrtr has attempted this but that the results weren't > optimal. > That's all I know. Should I open discussion on arch@? It's something I've been wanting to do for a while, and something that would be helpful at $work, so a discussion on it sounds like a good idea. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20f4e7af5b82e47fddf604975ff3e853c231720d.camel>