My own experience with this issue has never shown a problem with skew
<br>
between nodes with an active ntp client running.  (Also, I've had good
<br>
experience with the reliability of the ntp client already built into
<br>
OpenWRTs busybox.)  Rather, I've only seen this issue on newly powered-up
<br>
nodes, whose local time delta may be anywhere between -(several minutes)
<br>
and -(several years), and which need a route for their ntp client to
<br>
function.
<br>

<br>

<br>
On Fri, Dec 13, 2013 at 12:45 PM, technosopher <notifications@github.com>wrote:
<br>

<br>
> Are we talking about sensitivities that are sufficiently granular that
<br>
> we may need to think about implementing some sort of mesh time
<br>
> synchronization system (perhaps as part of commotiond)? Or can
<br>
> timestamps be off by as much as, say, 24 hours?
<br>
>
<br>
> —
<br>
> Reply to this email directly or view it on GitHub<https://github.com/opentechinstitute/olsrd/issues/9#issuecomment-30533016>
<br>
> .
<br>
>
<br>

<br>

<br>

<br>
-- 
<br>
Ben West
<br>
me@benwest.name

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href='https://github.com/opentechinstitute/olsrd/issues/9#issuecomment-30533518'>view it on GitHub</a>.<img src='https://github.com/notifications/beacon/3074564__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwMjQ5MzU0NywiZGF0YSI6eyJpZCI6MTg1NzQxMTd9fQ==--32ed2824639af0494e3a24b7d2e97a8bb00db591.gif' height='1' width='1'></p>