From owner-svn-src-all@freebsd.org Thu Sep 12 19:51:16 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AC717D8B45; Thu, 12 Sep 2019 19:51:16 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46TqC82YGjz3C70; Thu, 12 Sep 2019 19:51:15 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x8CJp6uw059240; Thu, 12 Sep 2019 12:51:06 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x8CJp6A3059239; Thu, 12 Sep 2019 12:51:06 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201909121951.x8CJp6A3059239@gndrsh.dnsmgr.net> Subject: Re: svn commit: r352231 - head/lib/libc/sys In-Reply-To: To: Ian Lepore Date: Thu, 12 Sep 2019 12:51:06 -0700 (PDT) CC: Alan Somers , Peter Holm , src-committers , svn-src-all , svn-src-head Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 46TqC82YGjz3C70 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 19:51:16 -0000 [ 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 +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 > > 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 rgrimes@freebsd.org