Robust Timing Over the Internet 178
ChelleChelle writes "The NTP (Network Time Protocol) system for synchronizing computer clocks has been around for decades and has worked well for most general-purpose timing uses. However, new developments, such as the increasingly precise timing demands of the finance industry, are driving the need for a more precise and reliable network timing system. Julien Ridoux and Darryl Veitch from the University of Melbourne are working on such a system as part of the Radclock Project. In this article they share some of their expertise on synchronizing network clocks. The authors tackle the key challenge — taming delay variability — and provide useful guidelines for designing robust network timing algorithms."
Re:Ridiculous (Score:5, Informative)
This sort of thing probably has something to do with it:
http://www.nytimes.com/2009/07/24/business/24trading.html [nytimes.com]
Re:Ridiculous (Score:3, Informative)
These guys are probably trying to do sub-millisecond trading. They need to keep their clocks sync'd to the microsecond to keep different machines coordinated.
Me, I wonder why they're bothering. Run GPS-based stratum-1 servers at each site, and sync directly to them across the LAN. Or get a cesium-beam primary time source. End of problem. Or take heed of the current financial meltdown and acknowledge that if you try to create money out of thin air, sooner or later you're going to pay the piper and it's going to hurt so maybe it'd be better to not go there.
Re:PTPd? (Score:5, Informative)
Would make sense (Score:5, Informative)
GPS is accurate to about 50 nanoseconds. All kinds of devices that need precision time get it from GPS. You don't need much more than a standard receiver, just one that is designed to place a high priority on time updates. The GPS system itself keeps very accurate time since each satellite has an atomic clock, and they all sync to the master clock.
To me that would seem the best way, if accuracy is really important and the systems are high end. Have each device have its own receiver and just have them sync to that. Don't sync them to each other, since you aren't going to get anything more accurate.
Re:Mod parent down. (Score:1, Informative)
Arbitrage is only beneficial if the actions of arbitrageurs result in narrowing the spread (i.e. reducing the arbitrage opportunity), which in this case doesn't happen. The fast traders are exploiting a systemic information asymmetry which other market participants can't avoid, so their opportunity for arbitrage is not eliminated by their actions. This particular arbitrage opportunity is a result of a flawed market system and does not depend on outside information. Therefore it can only be (and must be) eliminated by correcting the way the market works.
Re:Ridiculous (Score:4, Informative)
Re:can't trust self if microsoft (Score:5, Informative)
The problem isnt "windows"
Accurate timing on the modern PC is ridiculously difficult due to the hardware situation. The original IBM PC and its clones came with Intel's 8253 or 8254 Programmable Interval Timer (PIT) chip and back then it was pretty good. This timer chip had an internal frequency matching the CPU's of the time of 4.77mhz, and ticks were evenly distributed between 4 internal counters, so each counter had 1193181.81818181.... ticks per second. Pretty damn good.
Many of the old-school people might be familiar with the 18.2 ticks per second of the DOS clock. This rate was a direct consequence of configuring one of those counters to emit an interrupt every 65536 ticks, the longest possible interrupt interval due to these chips using 16-bit words.
Anyways, over time many manufacturers stopped using Intel's PIT's and started emulating them with other hardware (such as PMT.) None of these emulations can be configured to tick at exactly the same rate as the Intel PIT, and even among these emulated timers there wasn't any consistency.
To counter the serious problem of accurate timing on the PC, Microsoft and a few other large companies moved to define a new standard named HPET. Many new motherboards will have an HPET timer, but not all of them, and there are some problems with some HPET implementations as well (such as appearing to tick backwards sometimes.)
The issue of accurate timing on PC's has considerable effect on multi-player game developers.
A reference to some of the issues, and some of the attempts to fix them (source code) [gamedev.net]
Re:make all wall street traders own stock for 1 da (Score:1, Informative)
EVERY PENNY THESE GUYS MAKE COMES OUT OF OUR POCKET.
I see you have not the foggiest idea how "investments" and "fluidity" make the economy work.
But I do.
And I see no reason to believe that the scalping that's been introduced since year 2000 has made the market work any better; it's only happening for stocks that are fluid *anyway*, and consists of transferring money from the non-institutional traders to the institutional, computer-based traders. This may well decrease overall liquidity, since it increase the risk of the main group of people that provide liquidity.
And for all I know, the grand parent may perfectly well understand this, and just didn't feel like going into the details, considering them obvious.
Eivind.
Don't diss NTP! (Score:3, Informative)
The authors of the RADclock article don't seem to realize that most of the issues they "solve" with their algorithm has been considered, and also more or less solved, by the NTP hackers severeal years ago.
I.e. when the article shows that in a variable-latency environment you need to filter the measurements by the minimum rtt: This is of course default behaviour for ntp as well, but only over a limited number of polling intervals (8). If this isn't sufficient then there are a number of configuration options available, like the huff-puff filter which can be configured to maintain rtt history long enough to "coast" past any expected periods of large and asymmetrical network delays.
They also give out some _really_ bad advice, like claiming that "One server is enough": This is only true if you know that this particular server can never be wrong!
If you want to survive the situation where a single servers starts to lie, you shold configure at least 4 independent sources.
Personally I have seen 3 different gps-based stratum-1 black box ntp servers go crazy, suddenly returning timestamps far into the future.
OTOH, my freebsd-based servers with Motorola Oncore UT+ timing optimized gps firmware has never returned bad time, but I still have 6 such servers spread around our corporate network.
Terje
This is still NTP (Score:2, Informative)
Although the summary and the article itself seem to take pains not to mention it, a visit to the RADclock homepage (http://www.cubinlab.ee.unimelb.edu.au/radclock/) will tell you that what's actually being offered here is an improved NTP client. No changes to the NTP servers, server software or NTP protocol are required or are proposed. The client improvements are in an improved filter topology (feed forward with quality assessment) and introduction of separate concepts of absolute and difference clocks optimally supporting the different ways that time is used by applications.