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@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
