4 ms·
I was actually reading about this recently and learned about the time problem. Some interesting stuff I remember: * On LAN: NTP can get up to 1ms accuracy and
by Uptrenda 5y ago
I was actually reading about this recently and learned about the time problem. Some interesting stuff I remember:
* On LAN: NTP can get up to 1ms accuracy and on WAN about 10ms accuracy.
* People's 'system clocks' use NTP for synchronization but can still be completely off.
* When you call DataTime.now() in Javascript it returns the unix timestamp in UTC time.
* Since it is UTC it will have the same value anywhere in the world - however since it is set based on the the system clock it isn't guaranteed to be very accurate at all.
* Browsers now have a high-precision API for doing measurements of elapsed time called 'performance.' Don't use DateTime.now() for this.
* HTTP servers seem to return a Date field that has a unix timestamp in it. Some projects have attempted to use this to synchronize time in Javascript.
* There appears to be no good, robust Javascript libraries that can synchronize and keep time accurately. Some libraries exist that use a single server + NTP to try calculate clock drift, however. But this isn't as good as the NTP daemon.
* Researchers HAVE been able to write software to synchronize a clock with better accuracy than NTP using distributed networks -- this should be closer to what a lot of people are interested in. Here's a relevant paper I found on this: https://scholar.google.com/citations?view_op=view_citation&citation_for_view=QmbeOvsAAAAJ:5nxA0vEk-isC https://scholar.google.com/citations?view_op=view_citation&c...
* People have done some pretty cool bench-marking hacks to measure elapsed time in Javascript before the existence of the performance counter API. With performance.now() -- its not a clock but a counter and browsers can intentionally limit its accuracy to make 'fingerprinting' harder. https://stackoverflow.com/questions/6233927/microsecond-timing-in-javascript https://stackoverflow.com/questions/6233927/microsecond-timi...
- paxys 5y agoOne bit of clarification: > it returns the unix timestamp in UTC time Unix timestamp is ALWAYS the number of seconds since January 1st, 1970 00:00:00 UTC. It cannot be in any timezone.
- Dylan16807 5y ago"ALWAYS" is a bit much when we have leap seconds, though.
- zokier 5y agoSpecifically unix timestamp is number of days since 1970-01-01 × 86400 + seconds since midnight. The difference arises from the fact that in utc some days are 86401 seconds long, but unix timestamp just repeats the last second of the day instead of being simple ever increasing counter.
- chrismorgan 5y agoMost software does indeed ignore leap seconds, thereby generally matching UTC for times, but being discontinuous at leap second boundaries, and not matching UTC for durations. Sometimes this matching of POSIX behaviour is spelled out, but mostly it’s not. As an example, since an ancestor comment was talking about JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... says Date.now() “returns the number of milliseconds elapsed since January 1, 1970 00:00:00 UTC”, which wording would suggest the inclusion of leap seconds (since they have certainly elapsed). However, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... mentions that Date.now(), Date.parse() and Date.UTC() ignore leap seconds; what it fails to mention is that actually it’s just that ECMAScript follows POSIX for time measurement throughout, though in a milliseconds base rather than seconds, meaning that everything to do with Date ignores leap seconds. (Citation: ECMA-262 §21.4.1.1 <https://262.ecma-international.org/12.0/#sec-time-values-and-time-range https://262.ecma-international.org/12.0/#sec-time-values-and...>; warning, 6.7MB HTML document, slow to load.)
- necovek 5y agoI think stating it like that is a useful bit if redundancy: it's not overly long, and doesn't require the reader to know the exact definition.
- icelancer 5y agoYeah, until you sync to ~1ms with 99.999% accuracy required for production-specific services, you don't really realize how big of a pain in the ass this particular problem is. And syncing to ~1ms is comparably easy, although annoying as hell. The problem the OP company is trying to solve is quite a bit tougher. Of course it sounds extremely stupid, which is why there are so many drive-by "NTP solved this already" comments from people who don't deal with millisecond precision at high accuracy requirements, god forbid sub-millisecond.
- hansel_der 5y agotbf NTP did solve this already, but then came variable clockspeeds & powersaving and bam back to the stoneage and clocks regularly skew in the order of multiple seconds.
- TheDong 5y ago> With performance.now() -- its not a clock but a counter and browsers can intentionally limit its accuracy to make 'fingerprinting' harder. The primary reason that performance.now()'s precision is limited is for security reasons. Spectre showed that it was possible to perform timing attacks to leak other memory on the system, and having a browser leak memory from other processes is quite a dangerous attack. As part of spectre's mitigations, browsers began limiting performance.now()'s precision. See docs on this: https://developer.mozilla.org/en-US/docs/Web/API/Performance/now https://developer.mozilla.org/en-US/docs/Web/API/Performance... Chromium's impl: https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85... Total aside, but it's also more accurate to say that performance.now() is a monotonic clock rather than a counter. Counters don't necessarily have relationships with elapsed time, but performance.now() does, and it's conceptually the same as 'CLOCK_MONOTONIC'.