 |
|
I would think you would need to include taking the shortest possible route from source to destination, if you take a packet and send it all round the houses it could be slower than storage.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I agree, but I don't think speed is as much an issue as intent.
If I play a game of chess online and the packets get routed via mosambique, it that no longer real time?
|
|
|
|
|
And if you are running a high frequency trading system you are screwed. I'd love to know the details of how that stuff works!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
you're only screwed if yours is slower than theirs!
|
|
|
|
|
_Maxxx_ wrote: you're only screwed if yours is slower than theirs!
Then you're not talking about trading screens but algo/program trading/execution (idx arb for instance)
for user interface, there's no reason why updates need to come in quicker than eye blinks
dev
|
|
|
|
|
Right it depends on the context, I've written real time systems for nuclear power plants, water treatment systems and power plants and data had to be delivered as it was generated without any delays.
|
|
|
|
|
Realtime in trading means "faster than the other firetruckers".
Generally, realtime processing usually means receiving and processing an event takes less time than the time between events. This can be averaged, or not.
A Realtime OS usually allows applications to have certain guarantees, such as deterministic, controllable scheduling.
|
|
|
|
|
Here at work, we talk about Near Real-Time. Since we don't know for sure when new data arrives we try to grab it asap.
|
|
|
|
|
There are very few real time systems, even if people claim otherwise.
Apollo's guidance computer was real-time, the Airbus has real-time flight systems and IIRC the new Eurofighter has real-time avionics software.
What we mere mortals call real time is near real-time or to use a better term low latency. The best we can hope for is to reduce the lag times when the system is doing nothing [cold time] without preventing it from reacting because it is too busy [hot time].
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
devvvy wrote: I think 'without perceivable delay' is the key. Again, from Wiki, eye blink roughly takes 100-400ms[^] - so if your code (whether you're listening to an event/socket or a simple while loop), if your program capture the update within 100ms, it should be considered "Realtime" - agree?!?
In that case, the communication is real-time. Is your UI displaying the information within that same period? If it can update 33 times per second, you got the old TV-quality. That's roughly 30 ms for painting, 250 ms for processing.
Seen two of those systems, one on QNX[^] (the only real-time OS I know) and one on Windows. Windows can not guarantee that your thread will run within 100ms, there will be times when the complete OS decides to halt for a second or two.
"Realtime" was a requirement, in the sense that someone should be able to hit a button and kill all the power to all the machines in the plant. You don't want a second or two delay when someone is in trouble.
In trading, things will have to be "as fast as possible[^]".
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
My understanding of a RealTime system is one where the time of operations is guaranteed. Doesn't necessarily have to be fast. But the OS will specify the time for various operations - eg Allocate a block of memory will return in less than 10ms.
Some operations may be required to timeout rather than take longer than allowed.
It's all about allowing the application programmer complete control over what the processor doing at any time - for tasks that require that level of control.
There are very few true RealTime systems. I worked with iRMX years ago, but we didn't need to get into managing time too precisely.
|
|
|
|
|
I'm in the same industry. I was a performance engineer for 3 years on high throughput low latency systems.
Here are my thoughts. For GUI, times in the milliseconds is fine to send update to paint to screen. There is the limit of screen refreshing, painting time, human eye perceiving, human brain recognizing + interpreting. It is a fine standard for GUI systems to update that slow and be realtime. For automated trading, it should be able to read off the NIC and process / forward / create new message within microseconds, sub 200 is great.
I, unfortunately, have also worked at places where realtime meant seconds.
The slower place paid better.
|
|
|
|
|
wizardzz wrote: For automated trading, it should be able to read off the NIC and process / forward / create new message within microseconds, sub 200 is great.
<200us - that's not fantastic. Are you competitive at that speed? On which markets?
|
|
|
|
|
Wire to wire time-measured via network taps, reading, handling and executing a trade, yes. The CME.
I'll clarify further, this was in 2010, and 200u was the highest acceptable max, most orders were through the system in sub 100u.
|
|
|
|
|
I got your reply via e-mail, but you deleted it, what's up?
|
|
|
|
|
Sorry, my employer is very anal about keeping secrets and I thought its probably better not to discuss in public.
|
|
|
|
|
I don't know where you work. Anyway's, how are you numbers recorded? Post or pre NIC serialization? Being on the perf team it was my job to measure as consistently as possible with recreatable numbers. Unless measurements are taken the same way, comparing 2 firms' numbers is apples to oranges. We measured in the granularity of nanoseconds for machine process, but not from on the wire to on the wire (off machine to off machine again).
Are you in Chicago? It's a small community here. I don't work for latency sensitive company any more, though it's where I started.
|
|
|
|
|
For 'round trip' time we use fancy network taps.
|
|
|
|
|
Good chance you work at my former employer.
|
|
|
|
|
|
Then no. I know who you are talking about though, we are practically neighbors if you work in the Chicago office.
That's cool you guys shelled out for the taps. When I went to FIA last year, Endace had a booth. I talked to a rep that I had known from my previous job about doing contract work for them. It seemed they were just getting into the industry here, so I figured most places didn't use them yet.
|
|
|
|
|
wizardzz wrote:
The slower place paid better.
I heard ya! Same here.
Here's what's interesting - in one place I worked they told me to slow down the polling loop to 15 sec to reduce hits to database, I didn't argue of course.
Anyway, I agree anything sub 200ms be great (not counting latency from Exchange to Data Vendor to message bus, before ticks get broadcasted to trading desks).
dev
|
|
|
|
|
devvvy wrote: How can you precisely define what a realtime system is?
There is no such thing as a 'precise' definition in human endevours.
However I would say that your application does not fit my definition of real time. No more so than 'real time sports scores' are real time.
Real time to me implies a very small variance window around processing time for events. It isn't about when the event arrives but rather the min/max times for an event to arrive and the min/max times that the event can be processed in. Where min/max variance is very small in terms of the overall task processing times in the rest of the system.
|
|
|
|
|
Eagles are Turning People Into Horses: The Movie[^]
PS To answer the obvious questions: "Yes." and "Actually it's even weirder than that."
Go on, click the link. It won't take much: Just 15 minutes and 30 san points. It's not any worse than the first 5 minutes^H^H^H^H^H^H^Hseconds^H^H^H^H^H^H^Hthe rest of your life in a dinner date with Cthulu's sister.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I believe I'll pass on that one. Didn't even make the first minute...weird!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
