5 ms·
Using ntp or whatever the new variant is is also standard, which as I recall can hit sub-microsecond consistency on a wide area network with good hardware. So y
by tibbetts 10y ago
Using ntp or whatever the new variant is is also standard, which as I recall can hit sub-microsecond consistency on a wide area network with good hardware. So yeah, not new.
- sargun 10y agoPTP - Precision Time Protocol. https://en.wikipedia.org/wiki/Precision_Time_Protocol https://en.wikipedia.org/wiki/Precision_Time_Protocol. It requires hardware support, and a stable isolator inside of the machines.
- Unklejoe 10y agoIt doesn't require hardware, though it really improves the performance. I've implemented 1588 a few times and was able to achieve ~ <30ns accuracies when using hardware timestamping. Also note that there are more and more MACs and PHYs these days that offer HW timestamping. With software, it really depends on how deterministic your packet handling and timestamping routines are (or how deterministic the OS scheduler is). I was able to achieve accuracies of less than a microsecond on a Linux system, but it was "touchy". For reference, there's an open source implementation called "ptpd" and "ptpd2".
- phyalow 10y agoLittle know fact, you can use the GPS constellation to get atomic level precision time nearly anywhere on earth. Using an Atomic clock is purely to show off to investors/a red herring.
- adwf 10y agoI would've thought that GPS is too unreliable due to the deliberate inaccuracy? Only the US military have the clean signal. Particularly if you're using it to sync between two different time zones that could well be looking at different satellites. However, I don't know how much inaccuracy is introduced and whether it would have too much of an effect for the purposes of Google, et al.
- efaref 10y agoBill Clinton turned off the deliberate errors back in 2000: http://www.nytimes.com/2000/06/15/technology/pentagon-lets-civilians-use-the-best-gps-data.html?pagewanted=all http://www.nytimes.com/2000/06/15/technology/pentagon-lets-c... The errors you see in your mobile phone's positioning are due to signal problems (reflections, etc) and the relatively limited capabilities of the cheap GPS radio in your phone. A decent GPS receiver with a well-positioned antenna will get a highly accurate clock.
- Retric 10y agoThat's been removed. But, just for fun. Speed of light is 299,792,458 m/s. So if GPS is off by more than 1/10,000,000 you can't get accurate within 30 meters. Having used a GPS they are better than that, thus the clock must also be at least that accurate. Of note, stationary stations can get into centimeter precision which imply's vastly higher accuracy.
- btilly 10y agoFun fact. GPS is so precise that they can detect the fact from GR that gravity makes clocks run slower closer to the ground.
- Unklejoe 10y agoExactly. GPS is by far an easier way of synchronizing clocks to an atomic reference compared to any master-slave networked approach, especially in situations where we're talking about a small number of stationary, expensive servers which are far apart. PTP is mainly useful for situations where you want to synchronize many cheaper slave devices to a common master and it's not practical for each device to have its own GPS receiver, or for situations where the use of GPS isn't practical (or is prohibited) and you're more concerned about coherency between devices rather than traceability to a primary time reference (e.g. a telemetry network on an aircraft). Although, generally, the grand master of a PTP network is synchronized to GPS anyway. Of course, you could achieve actual phase locked synchronization down to the clock cycle with something like SyncE + PTP, but with GPS, you need not worry about issues with asymmetry regarding messages transmitted over the internet (PTP needs to be routed through PTP capable switches which compensate for the residence time and was really meant for LANs). I guess it really depends on your constraints, but if you’re able to use GPS, that would definitely be my first pick when it comes to synchronizing multiple devices. The latest UBlox timing receiver (LEA-M8F) provides a PPS which is accurate to less than 20 nanoseconds (to the UTC second) and its built in oscillator has a typical holdover spec of 0.025 PPM (25 nanoseconds per second). If you want to get fancy, you can use the PPS to discipline an OCXO and get an even better holdover spec to handle the situations where your receiver may lose lock (which is unlikely if you’re able to have an antenna). Basically, the accuracy of the UBlox GPS receivers (just an example since they're pretty cheap; I found a board for ~$150), is equal to or better than that of a usual PTP link (without SyncE), so you might as well just use GPS on each device if you can. It is simpler, IMO. However, note that comparing GPS to PTP isn't necessarily valid since PTP is purely a method of conveying timing information between devices, and is not a time source itself, where as GPS is both a method of conveying timing information as well as a time source. In other words, a PTP network still needs a master device which itself is synchronized to (or is) an atomic clock.
- SEJeff 10y agooscillator I think you mean? IEEE 1588 v2 is considerably better for financial applications. Source: I work in finance as a techie.
- Johnie 10y agoExcept that the state of art in HFT is sub-microseconds "London-based trading technology company Fixnetix said Tuesday it has the world’s fastest trading application, a microchip that prepares a trade in 740 billionths of a second, or nanoseconds." (WSJ, 2011) http://blogs.wsj.com/marketbeat/2011/06/14/wall-streets-need-for-trading-speed-the-nanosecond-age/ http://blogs.wsj.com/marketbeat/2011/06/14/wall-streets-need... http://stackoverflow.com/questions/17256040/how-fast-is-state-of-the-art-hft-trading-systems-today http://stackoverflow.com/questions/17256040/how-fast-is-stat...
- Bromskloss 10y agoIsn't the relevant delay rather that of a signal traveling from one exchange to another?
- oarsinsync 10y agoThat's one of the factors. Generally the optimisations that happen first are on network path length / network equipment induced delays, as there's relatively cheap and quick gains to be made. The bigger delays are invariably in your applications that are processing or generating data, which are more costly to optimise. That said, the Fixnetix stuff is only talking about one aspect of what's involved, and about as representative of reality as Cisco's published WARP speed figures in their Nexus 3500 range.