21–30 of 128 posts
I've vaguely wondered what it means for clocks to be in synch, when talking about time differences much smaller than the time it takes for light to travel between the various clocks.
I’m curious, who is even the target customer here? Places like FB and Google are working on the problems themselves.
They talked about some “latency sensei” product or something but what is it gonna tell me? How many nanoseconds it took for my API request to go from a load balancer to the web server, with 5 ns precision? Is that precision really needed?
* 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&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-timi...
I've vaguely wondered what it means for clocks to be in synch, when talking about time differences much smaller than the time it takes for light to travel between the various clocks.
If the clocks are programmed to know their distances from each other, you can account for that.
Earlier quoted context omitted.
Makes me curious how accurate a GPS clock is, they must be pretty good given the timing precision needed for accurate positioning.
For GPS precision is much more important than accuracy.
For GPS to work at all, you need very accurate knowledge of the offset between each satellite's signal.
The only way I can think of to have precision but not accuracy is if you design a system where there's a buffer between the antenna and the signal processing and you don't know how long the buffer is. Is a design like that a practical concern?
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…
> 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.
https://www.eecis.udel.edu/~mills/ptp.html
PTP takes advantage of special Ethernet switches and other devices which can decode or manipulate the time tags in hardware because yes your switches add latency.
This just sounds like more horseshit out of SV. I applaud them for convincing someone to give them money for this snake oil.
Wouldn't it be easier to just make distributed servers deal with large 'packets' or large individual tasks on their own?
Interesting. CERN has white rabbit for sub-ns timing. Needs special hardware but is now IEEE 1588 (PTP) "High Accuracy" profile. I wonder how this deals with the numerous retimers and DSPs required for really high speed ethernet.
In hardware that's actually designed to do this, I think it's called "synchronous ethernet" but you can totally duct tape it into pedestrian hardware the way I did.