New socket option SO_CLOCKTYPE to pick from several different clock sources to fill timestamps from
ClosedPublic
Actions

Authored by sobomax on Jan 14 2017, 2:21 AM.

Details

Reviewers

gnn
adrian

Group Reviewers

network
manpages
transport

Commits

rS338617: MFC r312296 and r323254, which is new a socket option
rS312554: Improve wording around SO_TS_CLOCK documentation.
rS312296: Add a new socket option SO_TS_CLOCK to pick from several different clock

Summary

This patch adds a new socket option SO_CLOCKTYPE 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_CLOCKTYPE.

Idea for this enhancement has been briefly discussed on the Net session during dev summit in Ottawa last May 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.

Test Plan

There two test cases attached to this patch: one extends unix domain test code to test new SCM_XXX types and another one implement totally new test case which exchanges UDP packets between two processes using both conventional methods (i.e. calling clock_gettime() before recv() and after send), as well as using setsockopt()+recv() in the receive path. The resulting delays are checked for sanity for all supported clock types.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 6759

Event Timeline

sobomax updated this revision to Diff 23977.Jan 14 2017, 2:21 AM

sobomax retitled this revision from to New socket option SO_CLOCKTYPE to pick from several different clock sources to return timestamps.

sobomax updated this object.

sobomax edited the test plan for this revision. (Show Details)

sobomax added a reviewer: network.

sobomax set the repository for this revision to rS FreeBSD src repository - subversion.

sobomax added a subscriber: network.

Herald added a reviewer: manpages. · View Herald TranscriptJan 14 2017, 2:21 AM

Herald added a subscriber: imp. · View Herald Transcript

sobomax retitled this revision from New socket option SO_CLOCKTYPE to pick from several different clock sources to return timestamps to New socket option SO_CLOCKTYPE to pick from several different clock sources to fill timestamps from.Jan 14 2017, 10:54 PM

sobomax updated this object.

sobomax added a reviewer: transport.

sobomax added a subscriber: transport.

adrian added a subscriber: adrian.Jan 15 2017, 12:02 AM

adrian added inline comments.

sys/sys/socketvar.h
133	maybe put this before the spares?

Move so_options before padding. Should not be really necessary, that padding is for lower layers to use I think, not really to protect the structure size. But it does not hurt.

Suggested by: adrian

Herald edited edge metadata. · View Herald TranscriptJan 15 2017, 6:43 AM

sobomax marked an inline comment as done.Jan 15 2017, 6:45 AM

sobomax added inline comments.

sys/sys/socketvar.h
133	Moved, however I don't think this spare is really a padding to protect the structure size in the future. IMHO it's there for lower layers to use. Does not hurt anyway.

hiya,

cool. +1 from me.

can this be used to pass up per-packet timestamps from an underlying hardware device? Right now it looks like it's getting timestamped in the IP stack.

eg, if I craft up a way to say, provide a PHY/MAC timestamp and BSSID from a wifi driver up in the mbufs up to the IP stack, it'd be nice to have a socket option to have that data be attached.

In D9171#189873, @adrian wrote:

hiya,

cool. +1 from me.

can this be used to pass up per-packet timestamps from an underlying hardware device? Right now it looks like it's getting timestamped in the IP stack.

eg, if I craft up a way to say, provide a PHY/MAC timestamp and BSSID from a wifi driver up in the mbufs up to the IP stack, it'd be nice to have a socket option to have that data be attached.

Adrian,

Well, I'd say it needs to be a separate option (SO_TS_HARDWARE?), since PHY/MAC clock is unlikely to be synchronized to any other clock in the system, which would make it difficult to use in practical applications. Unless your application does not care about that or if you can synchronize that clock to primary OS clock somehow.

I agree it should be a separate option. Let's move this code forwards first. I've been talking to other developers about exposing hardware timestamps and that definitely needs to work in a different way.

This revision is now accepted and ready to land.Jan 15 2017, 2:51 PM

One minor change to a name.

lib/libc/sys/getsockopt.2
190	I'd like this to be called SO_TS_TYPE because we might want to use CLOCKTYPE with the new, hardware timestamping, API.

oh absolutely, this doesn't have to be blocked for hardware timestamps. I was just curious!

(And ideally you'd return both MAC/PHY and system clock timestamps sampled at (mostly, within 1uS) the same time so you can over time derive their own offsets. That's what I have to do at work.)

sobomax added inline comments.Jan 15 2017, 7:25 PM