Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
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" 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
Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
On Tue, 24 Oct 2017 09:00:45 +0200 Victor Stinner wrote: > 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. What does synchronization have to do with it? If synchronization matters, then your PEP should be rejected, because current computers using NTP can't synchronize with a better precision than 230 ns. See https://blog.cloudflare.com/how-to-achieve-low-latency/ Regards Antoine. ___ 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
[Python-Dev] PEP 564: Add new time functions with nanosecond resolution
On Tuesday, October 24, 2017, Antoine Pitrou > wrote: > On Tue, 24 Oct 2017 09:00:45 +0200 > Victor Stinner wrote: > > 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. > > What does synchronization have to do with it? If synchronization > matters, then your PEP should be rejected, because current computers > using NTP can't synchronize with a better precision than 230 ns. >From https://en.wikipedia.org/wiki/Virtual_black_hole : > In the derivation of his equations, Einstein suggested that physical space-time is Riemannian, ie curved. A small domain of it is approximately flat space-time. >From https://en.wikipedia.org/wiki/Quantum_foam : > Based on the uncertainty principles of quantum mechanics and the general theory of relativity, there is no reason that spacetime needs to be fundamentally smooth. Instead, in a quantum theory of gravity, spacetime would consist of many small, ever-changing regions in which space and time are not definite, but fluctuate in a foam-like manner. So, in regards to time synchronization, FWIU: - WWVB "can provide time with an accuracy of about 100 microseconds" - GPS time can synchronize down to "tens of nanoseconds" - Blockchains work around local timestamp issues by "enforcing" linearity > > See https://blog.cloudflare.com/how-to-achieve-low-latency/ > Regards > > Antoine. > > > ___ > 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/wes. > turner%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
Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
2017-10-24 11:22 GMT+02:00 Antoine Pitrou : > What does synchronization have to do with it? If synchronization > matters, then your PEP should be rejected, because current computers > using NTP can't synchronize with a better precision than 230 ns. Currently, the PEP 564 is mostly designed for handling time on the same computer. Better resolution inside the same process, and "synchronization" between two processes running on the same host: https://www.python.org/dev/peps/pep-0564/#issues-caused-by-precision-loss Maybe tomorrow, time.time_ns() will help for use cases with more computers :-) > See https://blog.cloudflare.com/how-to-achieve-low-latency/ This article doesn't mention NTP, synchronization or nanoseconds. Where did you see "230 ns" for NTP? Victor ___ 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
Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
Le 24/10/2017 à 13:20, Victor Stinner a écrit : >> See https://blog.cloudflare.com/how-to-achieve-low-latency/ > > This article doesn't mention NTP, synchronization or nanoseconds. NTP is layered over UDP. The article shows base case UDP latencies of around 15µs over 10Gbps Ethernet. Regards Antoine. ___ 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
Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
Warning: the PEP 564 doesn't make any assumption about clock synchronizations. My intent is only to expose what the operating system provides without losing precision. That's all :-) 2017-10-24 13:25 GMT+02:00 Antoine Pitrou : > NTP is layered over UDP. The article shows base case UDP latencies of > around 15µs over 10Gbps Ethernet. Ah ok. IMHO the discussion became off-topic somewhere, but I'm curious, so I searched about the best NTP accuracy and found: https://blog.meinbergglobal.com/2013/11/22/ntp-vs-ptp-network-timing-smackdown/ "Is the accuracy you need measured in microseconds or nanoseconds? If the answer is yes, you want PTP (IEEE 1588). If the answer is in milliseconds or seconds, then you want NTP." "There is even ongoing standards work to use technology developed at CERN (...) to extend PTP to picoseconds." It seems like PTP is more accurate than NTP. Victor ___ 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
Re: [Python-Dev] iso8601 parsing
On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan wrote: > If one simply replaces the 'T' with a space and trims it after the '.', > IIRC, it parses fine. > sure, but really, can anyone argue that it's not a good idea for datetime ot be able to read the iso format it puts out??? -CHB > -- H > > On Oct 23, 2017 15:16, "Mike Miller" wrote: > >> Hi, >> >> Could anyone put this five year-old bug about parsing iso8601 format >> date-times on the front burner? >> >> http://bugs.python.org/issue15873 >> >> In the comments there's a lot of hand-wringing about different variations >> that bogged it down, but right now I only need it to handle the output of >> datetime.isoformat(): >> >> >>> dt.isoformat() >> '2017-10-20T08:20:08.986166+00:00' >> >> Perhaps if we could get that minimum first step in, it could be iterated >> on and made more lenient in the future. >> >> Thank you, >> -Mike >> ___ >> 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/hasan.diw >> an%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/ > chris.barker%40noaa.gov > > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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
Re: [Python-Dev] iso8601 parsing
On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker wrote:
> On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan wrote:
>>
> can anyone argue that it's not a good idea for datetime ot
> be able to read the iso format it puts out?
No, but the last time I suggested that that datetime types should
satisfy the same invariants as numbers, namely
T(repr(x)) == x, the idea was met will silence. I, on the other hand,
am not very enthusiastic about named constructors such as
date.isoparse(). Compared with date(s:str), this is one more method
name to remember, plus the potential for abuse as an instance method.
What is d.isoparse('2017-11-24')?
___
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
Re: [Python-Dev] iso8601 parsing
On Tuesday, October 24, 2017 5:53:58 PM EDT Alexander Belopolsky wrote:
> No, but the last time I suggested that that datetime types should
> satisfy the same invariants as numbers, namely
> T(repr(x)) == x, the idea was met will silence. I, on the other hand,
> am not very enthusiastic about named constructors such as
> date.isoparse(). Compared with date(s:str), this is one more method
> name to remember, plus the potential for abuse as an instance method.
> What is d.isoparse('2017-11-24')?
Agreed. datetime(s:str) seems like a far more natural and consistent
choice.
Elvis
___
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
