On Sat, Jun 06, 2015 at 11:45:46AM -0400, 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.
Right, it is 'parts per million'. Hz, ppm, and a measure of 'phase noise' are the three technical characteristics used to define a communications clock source. > > > That translates into 0.0625 Hz. for a 312.5 MHz ethernet reference clock > > I don't know how this number is derived, but 0.0625Hz sounds like an odd > variance. I used 200ppm for that example, as it is closer to the ethernet worst case. > He's pointing out that the design as specified passes the clock > frequency to the user space library in terms of integer MHz. The > standard Ethernet clock frequency is 312.5MHz. That .5MHz, or > 500,000Hz, must be rounded off as it is passed from the kernel to > the Yes, right, thank you, I thought I was loosing my mind :) > 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. I would use a period in picoseconds to describe a clock.. But really, if you start talking about IEEE 1588 (the PTP standard Christoph mentioned) then even that is not enough accuracy to represent a synchronized clock, and the frequency may change as the NIC adjusts the time base. So, if verbs has a 'time stamp to timespec' driver call back then that would be most general. Userspace that needs high speed self managed conversion can call 'time stamp to timespec' once with the value 1E9 and learn the general clock period, exactly as if it was in query_device. So nothing is lost by this small API change. Which suggest to me, this shouldn't be in the kernel general UAPI at all. That just leaves the mask, I dislike it, but.. if Or says it is too hard to fix then we are stuck with it. I don't think the wrapping can really be fixed unless the HW generates a CQE entry for every counter roll over. At least I haven't had a better idea on the subject this week.. Jason -- 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
