On Sun, Oct 28, 2012 at 4:45 PM, Tristan Seligmann <span dir="ltr">&lt;<a href="mailto:mithrandi@mithrandi.net" target="_blank">mithrandi@mithrandi.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, Oct 28, 2012 at 5:22 PM, Christopher Armstrong<br>
&lt;<a href="mailto:radix@twistedmatrix.com">radix@twistedmatrix.com</a>&gt; wrote:<br>
&gt; I think that for *certain* uncommon types of applications, even the very<br>
&gt; minor skewing of ntp can cause problems, but I wonder if gelin yan has<br>
<br>
</div>I&#39;m having trouble imagining such an application. In particular, if<br>
the application is sensitive to such minor fluctuations in the time<br>
source, I don&#39;t see how it could operate on commodity hardware at all;<br>
such fluctuations are present regardless of whether ntp is slewing the<br>
clock or not. You would need to use a separate hardware time source<br>
that is more reliable, at which point ntp is essentially out of the<br>
picture.<br></blockquote><div><br></div><div><br></div><div>I&#39;m not speaking from experience, admittedly. How big exactly are the steps in NTP skewing?</div><div><br></div><div>I&#39;m remembering VOIP applications (or anything else with low-latency streaming or real-time gaming or something like that), where you can have timed intervals of ~20ms, and if you miss one, you drop packets and lower the quality of the audio stream. In a case like that, using a monotonic time source seems like it would be a good decision. That&#39;s why Twisted should provide an API for scheduling calls based on one, if possible (that doesn&#39;t seem like a contentious point to me; just the general applicability of such a scheduling mechanism).</div>
<div><br></div></div>-- <br>Christopher Armstrong<br><a href="http://radix.twistedmatrix.com/">http://radix.twistedmatrix.com/</a><br><a href="http://planet-if.com/">http://planet-if.com/</a><br><br><br>