On Mon, Nov 03, 2014 at 05:11:53PM -0800, John Stultz wrote: > On Mon, Nov 3, 2014 at 4:58 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > If you're going to add double-stamped packets, can you also add a > > syscall to read multiple clocks at once, atomically? Or can you > > otherwise add a non-perf mechanism to get at this data? Does not need to be "atomic". In fact it cannot be atomic in the general case. Some clocks are read over memory mapped registers, but others are read over slow and sleepy buses like PCIe or MDIO. > > Because the realtime to monotonic offset is really quite useful for > > things like this, and it seems silly to make people actually open a > > perf_event to get at it. > > So this comes up periodically, but I don't think I've seen a interface > proposal that was decent yet. We have ioctl PTP_SYS_OFFSET that alternately reads a dynamic clock and CLOCK_REALTIME a given number of times. This is done without locks or any kind of "atomic" guarantees, and it works quite well in practice. The user can pick the number of repetitions to deal with noisy run time environments, and usually it is a simple matter of picking the reading with the shortest duration. However, the user is free to do statistics over the readings in any way he wants. It would be nice (and people have requested) a syscall that takes two clockid_t arguments but otherwise works like PTP_SYS_OFFSET. We really will never have to support more than two clocks. The application will pick one clock as the reference and then measure each of the other clocks relative to it, one at a time. The performance should be perfectly adequate, even better than reading three or more at once (with the understanding that these are "software" time stamps). Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
