svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Sure, I'll check that out. Thanks for heads up.

-Max

On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers <asomers at freebsd.org> wrote:

> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev <sobomax at freebsd.org>
> wrote:
> > Author: sobomax
> > Date: Mon Jan 16 17:46:38 2017
> > New Revision: 312296
> > URL: https://svnweb.freebsd.org/changeset/base/312296
> >
> > Log:
> >   Add a new socket option SO_TS_CLOCK to pick from several different
> clock
> >   sources to return timestamps when SO_TIMESTAMP is enabled. Two
> additional
> >   clock sources are:
> >
> >   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
> >   o nanosecond resolution monotonic clock (equivalent of
> CLOCK_MONOTONIC).
> >
> >   In addition to this, this option provides unified interface to get
> bintime
> >   (equivalent of using SO_BINTIME), except it also supported with IPv6
> where
> >   SO_BINTIME has never been supported. The long term plan is to
> depreciate
> >   SO_BINTIME and move everything to using SO_TS_CLOCK.
> >
> >   Idea for this enhancement has been briefly discussed on the Net session
> >   during dev summit in Ottawa last June and the general input was
> positive.
> >
> >   This change is believed to benefit network benchmarks/profiling as well
> >   as other scenarios where precise time of arrival measurement is
> necessary.
> >
> >   There are two regression test cases as part of this commit: one
> extends unix
> >   domain test code (unix_cmsg) to test new SCM_XXX types and another one
> >   implementis totally new test case which exchanges UDP packets between
> two
> >   processes using both conventional methods (i.e. calling
> clock_gettime(2)
> >   before recv(2) and after send(2)), as well as using
> setsockopt()+recv() in
> >   receive path. The resulting delays are checked for sanity for all
> supported
> >   clock types.
> >
> >   Reviewed by:    adrian, gnn
> >   Differential Revision:  https://reviews.freebsd.org/D9171
>
> While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
> doesn't work on amd64 under 32-bit emulation.  That is, programs that
> use SCM_TIMESTAMP built for i386 will fail when run on an amd64
> machine.  I don't know whether this commit introduced that bug; on
> stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
> sobomax, since you're obviously familiar with this code, would you
> mind taking a look?
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039
>
> -Alan
>
>