Re: [boost] Proposed boost timers library implementation concerns.

From: Glenn Schrader (gschrad_at_[hidden])
Date: 2007-07-23 09:24:55

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