Re: svn commit: r352231 - head/lib/libc/sys
On Thu, 2019-09-12 at 13:02 -0700, Cy Schubert wrote: > In message < > 63cf915c92b92b07e19337849269ec6bd0dc0d1b.ca...@freebsd.org>, > Ian Le > pore writes: > > On Wed, 2019-09-11 at 19:48 +, 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.2Wed Sep 11 19:29:40 > > > 2019 (r35223 > > > > 0) > > > +++ head/lib/libc/sys/getsockopt.2Wed 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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352231 - head/lib/libc/sys
In message <63cf915c92b92b07e19337849269ec6bd0dc0d1b.ca...@freebsd.org>, Ian Le pore writes: > On Wed, 2019-09-11 at 19:48 +, 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@? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352231 - head/lib/libc/sys
[ Charset UTF-8 unsupported, converting... ] > On Wed, 2019-09-11 at 15:55 -0600, Alan Somers wrote: > > On Wed, Sep 11, 2019 at 3:50 PM Ian Lepore wrote: > > > > > On Wed, 2019-09-11 at 19:48 +, 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.2Wed Sep 11 19:29:40 2019 > > > > > > (r352230) > > > > +++ head/lib/libc/sys/getsockopt.2Wed 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 > > Yeah, nptd is resilient to missing data and intermittent comms, within > reason. If it goes hours without getting a timestamp, system time > would start to drift. Running 50 concurrent pings sounds like > something that won't come up in the real world. :) I would think this is worth investigation, as the 50 pings are most likely not the only trigger event for this problem. > -- Ian -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352231 - head/lib/libc/sys
On Wed, 2019-09-11 at 15:55 -0600, Alan Somers wrote: > On Wed, Sep 11, 2019 at 3:50 PM Ian Lepore wrote: > > > On Wed, 2019-09-11 at 19:48 +, 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.2Wed Sep 11 19:29:40 2019 > > > > (r352230) > > > +++ head/lib/libc/sys/getsockopt.2Wed 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 Yeah, nptd is resilient to missing data and intermittent comms, within reason. If it goes hours without getting a timestamp, system time would start to drift. Running 50 concurrent pings sounds like something that won't come up in the real world. :) -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352231 - head/lib/libc/sys
On Wed, Sep 11, 2019 at 3:50 PM Ian Lepore wrote: > On Wed, 2019-09-11 at 19:48 +, 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.2Wed Sep 11 19:29:40 2019 > (r352230) > > +++ head/lib/libc/sys/getsockopt.2Wed 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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352231 - head/lib/libc/sys
On Wed, 2019-09-11 at 19:48 +, 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.2Wed Sep 11 19:29:40 2019 > (r352230) > +++ head/lib/libc/sys/getsockopt.2Wed 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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r352231 - head/lib/libc/sys
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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
