Philippe Vaucher wrote:
class but its useful to have timing that is synchronized across multiple
systems. This is essential for doing things like latency testing as well as for many real-time applications. The typical approach is to use a GPS time signal and an interface board in each system. This results in system-to-system timing offsets of 10-20 uSec out-of-the-box. An a lot better with a bit of tuning. The interface to these timing boards is typically via a vendor supplied driver so it would be nice if there was a spot in the timing class where an adapter could be written to handle special cases like this.
It's interesting but shouldn't be addressed by things like boost::ipc or boost::channel (which could use boost::timers for the implementation) ?
Not really. The fundamental problem that neither of these can address is how to obtain time values that are synchronous across different machines on a network. IPC just communicates between processes or threads on the same machine so they are by definition using the same clock hardware and can get accurate relative timings. IPC works fine for a single machine but doesn't extend to multiple machines. The problem with boost::channel is that even though messages can be sent between machines they can't be used to accurately synchronize the clocks since their latency is both unknown and varies with network load. Its better to get the time values from clocks that have hardware allowing them synchronize to a common super-accurate time reference. It would just be nice if boost::timers could use such clocks if they are available. Glenn Schrader - MIT Lincoln Lab