Thanks Thomas, it was interesting! You confirmed that time.time_ns() and other system clocks exposed by Python are inappropriate for sub-nanosecond physical experiment.
By the way, you mentionned that clocks are not synchronized. That's another revelant point. Even if system clocks are synchronized on a single computer, I read that you cannot reach nanosecond resolution for a NTP synchronization even in a small LAN. For large systems or distributed systems, a "global (synchronized) clock" is not an option. You cannot synchronize clocks correctly, so your algorithms must not rely on time, or at least not too precise resolution. I am saying that to again repeat that we are far from sub-second nanosecond resolution for system clock. Victor Le 24 oct. 2017 01:39, "Thomas Jollans" <t...@tjol.eu> a écrit : > On 22/10/17 17:06, Wes Turner wrote: > > There are current applications with greater-than nanosecond precision: > > > > - relativity experiments > > - particle experiments > > > > Must they always use their own implementations of time., datetime. > > __init__, fromordinal, fromtimestamp ?! > > > > - https://scholar.google.com/scholar?q=femtosecond > > - https://scholar.google.com/scholar?q=attosecond > > - GPS now supports nanosecond resolution > > - > > Sure, but in these kinds of experiments you don't have a "timestamp" in > the usual sense. > > You'll have some kind of high-precision "clock", but in most cases > there's no way and no reason to synchronise this to wall time. You end > up distinguishing between "macro-time" (wall time) and "micro-time" > (time in the experiment relative to something) > > In a particle accelerator, you care about measuring relative times of > almost-simultaneous detection events with extremely high precision. > You'll also presumably have a timestamp for the event, but you won't be > able or willing to measure that with anything like the same accuracy. > > While you might be able to say that you detected, say, a muon at > 01:23:45.6789 at Δt=543.6ps*, you have femtosecond resolution, you have > a timestamp, but you don't have a femtosecond timestamp. > > In ultrafast spectroscopy, we get a time resolution equal to the > duration of your laser pulses (fs-ps), but all the micro-times measured > will be relative to some reference laser pulse, which repeats at >MHz > frequencies. We also integrate over millions of events - wall-time > timestamps don't enter into it. > > In summary, yes, when writing software for experiments working with high > time resolution you have to write your own implementations of whatever > data formats best describe time as you're measuring it, which generally > won't line up with time as a PC (or a railway company) looks at it. > > Cheers > Thomas > > > * The example is implausible not least because I understand muon > chambers tend to be a fair bit bigger than 15cm, but you get my point. > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > victor.stinner%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
