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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
