On Sat, 6 Jun 2015, Doug Ledford wrote: > The ppm rating is based upon the speed of the clock, not time. It's how > many cycles of variance you are allowed from the target speed given in > cycles / millions of cycles of the target clock frequency. If you have > a 312.5MHz clock, and your accuracy is specified as 100ppm, then the > total clock variability is 312.5 * 100 = 31250 cycles (I suspect that > this is an absolute variance, and so the tolerance would be +-1/2 of the > total amount, but I don't know that for certain).
Ok well then you also have the problem that the clock may be off in general already by a certain factor from the true speed of the flow of time due to manufacturing variances etc. We are only talking about the instabilty of the clock source while operating it seems? > > 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. > > Jason's point, and one that isn't addressed yet, is that this might not > be variance in the clocks and instead might be a design flaw in the API > you are using and the way the clock speeds are passed to user space. > Changing from int MHz to int KHz might solve your problem. That sounds doable. Maybe we need to look at how clock speeds are specified elsewhere? man adtimex gives some ways that this is done in the general API for clock adjustment. Or maybe better look at IEEE 1588 for ways to specify the clock characteristics? http://www.nist.gov/el/isd/ieee/ieee1588.cfm -- 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
