Re: [PATCH for-next V2 0/9] Add completion timestamping support

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]

On Mon, 2015-06-01 at 08:58 -0500, Christoph Lameter wrote:
> On Mon, 1 Jun 2015, Doug Ledford wrote:
> 
> > What's the point?  If it's raw, it's raw.  It's not coordinated between
> > adapters.  Whether it's in ns or ps or flipflops doesn't matter, it's a
> > flat number that has no reference to anything else, so the only thing
> > that matters is < another version of itself or not.
> 
> It can be coordinated between different adapter through the use of time
> software that can work with cycles and frequencies to scale the value of
> the cycles to realtime.

And that is precisely what the cooked values should be.

>  Software like that is available in ptpd,
> timekeeper etc. Each NIC basically has its own clock and the timekeeping
> software would have to track the scaling and the aberration factor over
> time in order to come up with accurate absolute time values derived from
> the cycle counters of these NICs. Since we are dealing here with values
> that need to be accurate to within less than 100ns this is not trivial and
> one can easily get a ns value that is absolutely useless.

Agreed.  The cooked value is not going to be a simple thing.  I fail to
see how this is making a case that we should duplicate that code in
every app that uses a timestamp versus getting it right once in
libibverbs.

> Since it is not trivial its better kept out of the timestamp support in
> the RDMA API. If the app developer wants a trivial conversion then they
> can opencode a simple multiplication by the frequency. At that point it
> should be clear though that this raw time value is of limited use given
> its inaccuracy  and the dependence on the NIC clock.

The raw value is just that: raw.  And it *is* of limited use unless you
only have one adapter.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]