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.
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! - DDEthel 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
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.
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.
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.
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.
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.
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?
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