| |||||||||||||
|
| |||||||||||||
Enterprise realtime and cooperative developmentEnterprise realtime and cooperative developmentPosted Dec 6, 2007 10:36 UTC (Thu) by skitching (subscriber, #36856)Parent article: Enterprise realtime and cooperative development
I still don't understand why financial systems care about real-time. Assume two systems ready to fire a "buy" offer once a stock price drops to exactly the same value ($10.00). One is a "real time" system, and one is a standard-one with the "buy" process running at high priority. The real-time one will guarantee that the buy program runs within a fixed period (eg 100ms). But the non-realtime one will *usually* win the race. Real-time is useful for systems where leaving things too long *even once* leads to physical system damage (eg plant control), or data loss (eg realtime audio/video processing). But in system where the one who completes a process *first* *on average* wins, and where the occasional miss can be tolerated, why use real-time?
(Log in to post comments)
Enterprise realtime and cooperative development Posted Dec 6, 2007 12:20 UTC (Thu) by stephend (guest, #8045) [Link] The problem is you can't really work on averages. Trading activity isn't distributed evenly throughout the day. Chances are on a non-real-time system your latencies would increase when the markets were busiest -- just the time you can't afford to lose opportunities.
Averages DO matter, just in different place Posted Dec 6, 2007 21:28 UTC (Thu) by khim (subscriber, #9252) [Link] The keyword here is "grid". As long as rules were as simple as "buy if less then $10" non-realtime computers worked great. Today we have 1000 computers which calculate complex models. So we have something like this: 990 computers have lighting-fast response (10-50ms, for example), 5 have the same 100ms as realtime computers and the last 5 have latency 200ms. Realtime grid wins. Next round: 995 computers finished in 50ms, 3 in 100 ms, one in 150ms and one in 200ms. Still realtime grid wins. Once per blue moon you have situation when non-deteministing-but-usually-fast response produces answer in less then 100ms and non-realtime grid wins, but in general - you NEED soft realtime there...
Enterprise realtime and cooperative development Posted Dec 6, 2007 14:56 UTC (Thu) by niv (subscriber, #8656) [Link] "The real-time one will guarantee that the buy program runs within a fixed period (eg 100ms). But the non-realtime one will *usually* win the race." Just out of curiosity, why do say that the non-realtime one will usually win? Are you assuming real-time guarantees come at the _expense_ of latency? Isn't it usually the other way around?
Enterprise realtime and cooperative development Posted Dec 6, 2007 17:55 UTC (Thu) by lmb (subscriber, #39048) [Link] Lower latency guarantees usually come at the cost of lower throughput. However, you can scale up throughput by increasing the CPU power you have available (within Amdahl's Law, etc); the same is not, necessarily, true for latency.
Enterprise realtime and cooperative development Posted Dec 7, 2007 23:43 UTC (Fri) by Tet (subscriber, #5433) [Link] I still don't understand why financial systems care about real-time.They don't. As someone that writes trading systems for a living, I can assure you that none of them are real time. The trick is to be as fast as possible, not to have a bounded worst case. As you say, the occasional miss can be tolerated.
Enterprise realtime and cooperative development Posted Dec 8, 2007 11:20 UTC (Sat) by nix (subscriber, #2304) [Link] And some of them are *way* slower than being discussed here. A goodly number of organizations are still expecting people to be impressed that they can get trades out on the same *day* they went in. (I boggle, too, but that's the way it is.)
Enterprise realtime and cooperative development Posted Dec 12, 2007 1:31 UTC (Wed) by da4089 (subscriber, #1195) [Link] They don't care about real real-time systems (or they'd all use VxWorks or QNX or whatever). They care about low latency, which has come to be described as "enterprise real-time". Some of the concerns are similar, but trading platforms care a lot more about minimising latency, rather than just bounded latency.
|
|
||||||||||||