<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 8, 2014 at 10:37 PM, Peter Gutmann <span dir="ltr"><<a href="mailto:pgut001@cs.auckland.ac.nz" target="_blank">pgut001@cs.auckland.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Tom Mitchell <<a href="mailto:mitch@niftyegg.com">mitch@niftyegg.com</a>> writes:<br>
<br>
>A clock that is sufficiently stable for long periods of time and temperature<br>
>deltas is nearly impossible to design.<br>
<br>
</span>You don't need a perfectly accurate clock, you just need to track the drift at<br>
the receiving end.  In fact is you can bound the transmission latency (if it's<br>
an online protocol rather than store-and-forward) you don't need a clock at<br>
all on the sending device.<br><br></blockquote><div><br></div><div>Thanks... I saw UTS and that is a standard that folk get serious about.</div><div><br>A free running tick counter that never overflows is a good thing.   Freedom</div><div>from time of day issues leap seconds and more make it easy.  The frequency </div><div>choice is open and precision and accuracy is open.   An external  map of ticks to </div><div>historic real world time (and temperature) is interesting in the right context.<br>Might be interesting salt and pepper for hashing something for example. <img src="cid:330@goomoji.gmail" goomoji="330" style="margin: 0px 0.2ex; vertical-align: middle;"></div><div><br></div><div><br></div><div><br></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr">  T o m    M i t c h e l l</div>
</div></div>