Date: Wed, 11 Sep 2019 15:55:20 -0600 From: Alan Somers <asomers@freebsd.org> To: Ian Lepore <ian@freebsd.org>, Peter Holm <pho@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r352231 - head/lib/libc/sys Message-ID: <CAOtMX2iqc3zLYG1d-dn2gVuFnA3hc9s68PVFhHxZGG0EUTs8qw@mail.gmail.com> In-Reply-To: <63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org> References: <201909111948.x8BJmWZn092483@repo.freebsd.org> <63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 11, 2019 at 3:50 PM Ian Lepore <ian@freebsd.org> wrote: > 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 as > > ancillary data to each IP datagram that is received on the socket. > However, > > 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 > (r352230) > > +++ head/lib/libc/sys/getsockopt.2 Wed Sep 11 19:48:32 2019 > (r352231) > > @@ -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 > received. > > +call may return a timestamp corresponding to when the datagram was > received. > > +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. > > -- Ian > pho discovered how to trigger it. If you start 50 ping processes simultaneously, sometimes a few will fail. Will ntpd be ok with a single failure, as long as the timestamp is received correctly in a subsequent packet? -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2iqc3zLYG1d-dn2gVuFnA3hc9s68PVFhHxZGG0EUTs8qw>