<br><br>On Saturday, October 21, 2017, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 October 2017 at 09:32, Victor Stinner <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','victor.stinner@gmail.com');" target="_blank">victor.stinner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span><div class="gmail_extra" dir="auto"><div class="gmail_quote">Le 21 oct. 2017 20:31, "francismb" <<a href="javascript:_e(%7B%7D,'cvml','francismb@email.de');" target="_blank">francismb@email.de</a>> a écrit :<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I understand that one can just multiply/divide the nanoseconds returned,<br>
(or it could be a factory) but wouldn't it help for future enhancements<br>
to reduce the number of functions (the 'pico' question)?</blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">If you are me to predict the future, I predict that CPU frequency will be stuck below 10 GHz for the next 10 years :-)</div></div></blockquote><div><br></div>There are actually solid physical reasons for that prediction likely being true. Aside from the power consumption, heat dissipation, and EM radiation issues that arise with higher switching frequencies, you also start running into more problems with digital circuit metastability ([1], [2]): the more clock edges you have per second, the higher the chances of an asynchronous input changing state at a bad time.</div><div class="gmail_quote"><br></div><div class="gmail_quote">So yeah, for nanosecond resolution to not be good enough for programs running in Python, we're going to be talking about some genuinely fundamental changes in the nature of computing hardware, and it's currently unclear if or how established programming languages will make that jump (see [3] for a gentle introduction to the current state of practical quantum computing). At that point, picoseconds vs nanoseconds is likely to be the least of our conceptual modeling challenges :)<br></div></div></div></blockquote><div><br></div><div><p dir="ltr">There are current applications with greater-than nanosecond precision:</p>
<p dir="ltr">- relativity experiments<br>
- particle experiments</p>
<p dir="ltr">Must they always use their own implementations of time., datetime. __init__, fromordinal, fromtimestamp ?!</p>
<p dir="ltr">- <a href="https://scholar.google.com/scholar?q=femtosecond">https://scholar.google.com/scholar?q=femtosecond</a><br>
- <a href="https://scholar.google.com/scholar?q=attosecond">https://scholar.google.com/scholar?q=attosecond</a><br>
- GPS now supports nanosecond resolution<br>
- </p>
<p dir="ltr"><a href="https://en.wikipedia.org/wiki/Quantum_clock#More_accurate_experimental_clocks">https://en.wikipedia.org/wiki/Quantum_clock#More_accurate_experimental_clocks</a></p>
<p dir="ltr">> In 2015 <a href="https://en.m.wikipedia.org/wiki/JILA">JILA</a> evaluated the absolute frequency uncertainty of their latest <a href="https://en.m.wikipedia.org/wiki/Isotopes_of_strontium">strontium-87</a> optical lattice clock at 2.1 × 10<sup>−18</sup>, which corresponds to a measurable <a href="https://en.m.wikipedia.org/wiki/Gravitational_time_dilation">gravitational time dilation</a> for an elevation change of 2 cm (0.79 in)<br></p>
<p dir="ltr">What about bus latency (and variance)?</p>
<p dir="ltr">From <a href="https://www.nist.gov/publications/optical-two-way-time-and-frequency-transfer-over-free-space">https://www.nist.gov/publications/optical-two-way-time-and-frequency-transfer-over-free-space</a> :</p>
<p dir="ltr">> Optical two-way time and frequency transfer over free space<br>
> Abstract<br>
> The transfer of high-quality time-frequency signals between remote locations underpins many applications, including precision navigation and timing, clock-based geodesy, long-baseline interferometry, coherent radar arrays, tests of general relativity and fundamental constants, and future redefinition of the second. However, present microwave-based time-frequency transfer is inadequate for state-of-the-art optical clocks and oscillators that have femtosecond-level timing jitter and accuracies below 1 × 10<sup>−17</sup>. Commensurate optically based transfer methods are therefore needed. Here we demonstrate optical time-frequency transfer over free space via two-way exchange between coherent frequency combs, each phase-locked to the local optical oscillator. We achieve 1 fs timing deviation, residual instability below 1 × 10<sup>−18</sup> at 1,000 s and systematic offsets below 4 × 10<sup>−19</sup>, despite frequent signal fading due to atmospheric turbulence or obstructions across the 2 km link. This free-space transfer can enable terrestrial links to support clock-based geodesy. Combined with satellite-based optical communications, it provides a path towards global-scale geodesy, high-accuracy time-frequency distribution and satellite-based relativity experiments.</p>
<p dir="ltr">How much wider must an epoch-relative time struct be for various realistic time precisions/accuracies?</p>
<p dir="ltr">10<sup>-6</sup> micro µ<br>
10<sup>-9</sup> nano n -- int64<br>
10<sup>-12</sup> pico p<br>
10<sup>-15</sup> femto f<br>
10<sup>-18</sup> atto a<br>
10<sup>-21</sup> zepto z<br>
10<sup>-24</sup> yocto y</p>
<p dir="ltr">I'm at a loss to recommend a library to prefix these with the epoch; but future compatibility may be a helpful, realistic objective.</p>
<p dir="ltr">Natural keys with such time resolution are still unfortunately likely to collide.</p></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">[1] <a href="https://en.wikipedia.org/wiki/Metastability_in_electronics" target="_blank">https://en.wikipedia.org/wiki/<wbr>Metastability_in_electronics</a><br></div><div class="gmail_quote">[2] <a href="https://electronics.stackexchange.com/questions/14816/what-is-metastability" target="_blank">https://electronics.<wbr>stackexchange.com/questions/<wbr>14816/what-is-metastability</a><br></div>[3] <a href="https://medium.com/@decodoku/how-to-program-a-quantum-computer-982a9329ed02" target="_blank">https://medium.com/@decodoku/<wbr>how-to-program-a-quantum-<wbr>computer-982a9329ed02</a><br><br clear="all"><br>-- <br><div>Nick Coghlan   |   <a href="javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>
</blockquote>