Initial entry
My life's work is real-time everything. From scheduling, to languages, to systems, to education, to specifications, to benchmarks, to standards, to the Real-Time Specification for Java (RTSJ). I've spent the last 15 years thinking pretty deeply about the intersection between general-purpose languages, systems, applications, and market and the real-time counterparts. And, believe it or not, the intersection is not the empty set. Trends in the general-purpose world are generating requirements that can only be met by real-time systems.
I have a lot to say and I'll seemingly be all over the place for awhile until it all comes together, sometime in the not too distant (and not too many entries) future. I'll talk about real-time in general, real-time scheduling, and a lot about the RTSJ and Sun's implementation of the RTSJ, the Sun Java Real-Time System 2.0 (JRTS). It will also be interesting to discuss real-time garbage collection, something currently all the rage in the enterprise systems world. I'll also define terms, debunk myths, and, hopefully, generate lots of controversy.
When customers ask if they need a real-time system I reply, "If all you, or your application, think about is how many transactions-per-second, then no, real-time probably isn't for you. However, if you have a requirement to execute a particular transaction at a particular millisecond (a millisecond that cannot be known until it happens) then, yes, real-time, and especially JRTS, is for you."
Yes, indeed, general-purpose system architects are now concerned about sub-millisecond response time at any, unknown, future, arbitrary millisecond.
The first step to the road to real-time enlightenment:
Real-Time != Real-Fast.
Let's say that again, all together now,
Real-Time != Real-Fast.
Real-Fast is good, yes, but having a fast system does not guarantee that you can depend on executing that particular transaction at that arbitrary millisecond somewhere in the unknown future. Only real-time systems can do that for you.
I'll end this first entry with an example of how customers respond to the RT != RF issue. Typically, real-time systems have lower throughput than non-RT systems and this engineering trade-off is well known and accepted in the RT community. (I'll cover the issue in depth in later entries). I, when presenting JRTS to customers always include the caveat, JRTS does sacrifice throughput to get predictability. When I mentioned this caveat to the CTO of a major financial firm considering using JRTS for an automated trading system he replied, "What? What do I care? If I have predictability I get throughput by simply adding machines!" This comment is great and absolutely right-on-target. I'd only add that the inverse is NOT true, you cannot get predictability by adding machines. Greg
Posted at 10:16AM May 30, 2007 by gregbollella in Sun | Comments[3]
Financial firms need both Predictability and Real-Fast. They do a large number of transactions in a short period of time , scaling by adding machines is not easy. It is not economical, because most of the brokers get only pennies for each transactions they handle for their clients. It makes sense for big technology based hedge funds who trade for themselves to invest in Real-Time systems. I am just curious to know what type of Financial Firm you mentioned in your blog. My feeling is there is market in Wall Street for systems where
Real-Time = Real-Fast and
Real-Time = Predictability
Posted by dhina on August 10, 2007 at 07:34 PM PDT #
We're talking to all the large banks and most of the stock exchanges. Note that *not* all systems in a financial institution need real-time, some need real-fast. Typically, systems that automatically trade financial instruments (stocks, currencies, etc.) need real-time.
Posted by Greg on October 05, 2007 at 11:33 AM PDT #
Amazing blog! I'll be working with JRTS soon.
Posted by Jc on November 03, 2007 at 08:07 PM PDT #