Richard Cochran <richardcochran@xxxxxxxxx> wrote on 01/04/2013 10:09:46 PM: > Instead of looking for new system calls, why not just solve this > problem at the application level? > > 1. boot machine > 2. start ptp4l > 3. wait five seconds > 4. start control app, and just use clock_realtime > > HTH, > Richard Richard and I talked about this a bit (thank you again Richard). My solution needs to handle a variety of different clock shift scenarios, because I'm not designing the final application but trying to provide a system that can support a variety of applications. I think the two variables that matter most are (1) that the two controllers might be on the same subnet or in different countries, and (2) that they might be synced by 1588 or SNTP. Another possibly important variable is that the time sync server might not be reliably available. Ideally the same system would work on all the combinations. Richard suggested a user-mode solution where I just sample the two clocks in a tight loop and determine the shift between them by the smallest delta across N loops. That solution is nice for a couple of reasons, first, no syscall, second, it supports arbitrary combinations of clockid's really nicely. One drawback of that solution for me is that for the specific clocks I care about (MONO and REAL) it is not optimal. The delta between those two clocks is available in the kernel timekeeping data, so a syscall just handling those two would be able to get the exact offset quickly. I'd still really like to be able to get that offset. One way to do that would be to take a small step along the clock_gettime2 path and just have it return an error if the clockid's are anything other than MONO and REAL. That seems ugly, but it's straightforward to implement, and would work for me and maybe others with basically similar requirements, so I'll throw it out there. Another option is to continue all the way down the clock_gettime2 path, as John suggested: > Basically you need to split the current accsessor functions into two parts: > 1) The clocksource hardware read > 2) The time calculation, given the clocksource value > > Then for the gettime2() implementation, do a *single* read of the > hardware, and pass that clocksource value into the different specified > clockid functions. > > Another important thing to consider here, is that if we are considering > adding a new syscall, we should avoid the 2038 issue, and specify a new > time64_t and timespec64 types, and use them in the new interface. This > way we can provide a 64bit time interface for 32bit systems. This is something I'd like to work on, but it seems like a significant project, and I'm wondering if it might be acceptable to start with the reduced functionality version I mentioned above and work towards this. As a side note, Richard mentioned that the idea of a CLOCK_TAI has been thrown around before. I agree with him that it would be a useful addition for test & measurement applications. -Scot -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
