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

[Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>]

On Wed, 3 Jun 2015, Jason Gunthorpe wrote:

> On Wed, Jun 03, 2015 at 07:55:58PM -0500, Christoph Lameter wrote:
>
> > I thknk the raw cycles and the rought oscillator speed are fine.
>
> Time keeping is designed to adjust for 100's of ppm drift between
> clocks.

What time keeping? Ntp? pptp is supposed to be accurate to 10s of ns and
we would need an accuracy in that range.

> A communications clock source will be spec'd to be below 200ppm in
> accuracy. IB clocks are below 100 ppm, and PCI-E is 300ppm (approx, I
> didn't check, order of magnitue is close)

Well that is not usable. ns are a billionth of a second which is the unit
of measurement of these activities here. A send action can be around 600-1000ns.
If we are off by 200ppm then that is 200 microseconds meaning 200000 ns.
And its our experience that these clocks can be off by milliseconds in
practice.

> That translates into 0.0625 Hz. for a 312.5 MHz ethernet reference clock

Ok that is around 3ns per cycle? And you think the accuracy is therefore
in femtoseconds? I have never seen something that accurate. Wish something
like that would exist. Maybe in some labs that provide the source of
global timekeeping?

> Compared to 5,000,000 Hz in error from rounding.

Huh?

> So no, I disagree that rough is fine for anything.

I am sorry but the practical issues that we are dealing with in
timekeeping today shows just the opposite. For a true comparison of clocks
with nanosecond accuracy you would need time corrected values and that is
a challenge due to the variances of the clocks that we see.



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html