svn commit: r352231 - head/lib/libc/sys
Ian Lepore
ian at freebsd.org
Thu Sep 12 20:08:45 UTC 2019
On Thu, 2019-09-12 at 13:02 -0700, Cy Schubert wrote:
> In message <
> 63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel at 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
More information about the svn-src-all
mailing list