Help Center Blog Open An Account

How fast are the various Rithmic Configuration Options?


#1

I have a HFT strategy that I am planning to test soon, and I am looking into the various options here from rithmic: http://www.theomne.net/.

I am looking for low enough latency speed to accommodate my strategy. The key thresholds I need to hit are as follows:

  1. I need to be able to read and react to every price level change in real time. In the past I tried this with NinjaTrader / CGQ collocated and the level 1 feed had a lag within ninjatraders various event handlers by design. So the Rithmic API would have to be able to receive and read the data feed in real time.

  2. From an execution stand point, I do not need to be the first guy in the queue, but I do need the ability to place an order on any price level at any point in time, and if every order in that particular queue gets filled, my order would need to get filled as well.

So at this point I am thinking that the Diamond API + a dedicated server collocated at the Omne would be the fastest option and run somewhere in the neighborhood of a few grand a month.

I am not really interested in building my own hardware (Field Programmable Gate Arrays and the likes) at this time. I am hoping that their API with either a high end server or VPS will suffice for my speed use case. Again, not trying to be the first guy in the queue or doing any sort of arbitrage strategy, but I do need to be able to pick my spots and get in and out on any price level when and if the strategy calls for it.

For any users that have worked in a HF space with rithmic in the past what do you think? Do you have any recommendations on a configuration that that you think could accommodate my use case.

Thanks in advance.

Ian


#2

Though its often presumed that faster (lower latency) is better, it is important to understand the different levels of latency, the effort to achieve each level and the cost associated.

Consider the scenario of a trader who is using a commercially available app (R | Trader Pro, SC, NT, MC, …) on his desktop and his desktop is located in the NYC area. The CME’s market data (market data from CBOT, CME, COMEX and NYMEX) originates from the CME’s data center located in Aurora, Il - about 30 miles west of Chicago. The rule of thumb for data traversing the internet is 1 millisecond per 100 miles. The New York Area is about 830 miles from Aurora so data will take at least 8.5 milliseconds to go from Aurora to NYC and the same time to go from NYC to Aurora. So to get an order to the CME based upon market data from the CME, if the decision to place the order took no time at all (figure an automated program made that decision), such an order would arrive at least 17 milliseconds after the market data was published by the CME. If that trader had his desktop in the Chicago area his order would have arrived at the CME about 17 milliseconds sooner.

Now look at the method of getting the market data and placing the order. In the example above the decision to place the order and the mechanism to place it was automated. Suppose it had been based upon the trader looking at the screen, i.e. the trader looks at a screen, sees data that indicates to him that it is a good time to place an order and clicks on that screen to place an order. How long does that take? Well try to blink your eyes 8 times within 1 second - doable but not so pleasant. if you can do it then you can say that the blink of an eye takes about 125 milliseconds. If you can react to data on a screen and click so that an order is submitted within the blink of an eye then such an order to be sent from your screen took about 125 milliseconds and will take another 8.5 milliseconds or so to get to Aurora. Moving the machine from the NYC area to the Chicago area would have limited benefit as the overwhelming time taken for the order to get to Aurora rested with the trader.

When an order is received by our infrastructure, it is checked to make sure that the user who placed the order is known, the user has permission to trade on the account identified in the order, the account has permission to trade the instrument identified in the order, the account has enough credit to place the order, etc. If none of the checks result in the order being rejected then the order is put to out our modules that handle the submission of the order to the exchange. The time it takes from when we get the order so that we can assign an order id to it to the time just after we submit it to the exchange varies, but generally takes between half a millisecond to 1 and a half milliseconds, sometimes more. This variance depends upon many factors including the complexity of the order and the activity of the system at the time the order is received. Now add to it the time taken for the market data to get from our system to the app and the time taken for the user or app making the decision to send an order to our infrastructure.

Orders from R | Trader, R | Trader Pro, all third party screens and all programs written by traders that incorporate R | API+ experience these processing and transit times. With R | Diamond API the total time, from when we get the market data to the time just after an order is submitted to the exchange (such order based upon the market data and submitted automatically by a program) is generally less than 250 microseconds (1 quarter of a millisecond). It is usually much less than 250 microseconds, but we only admit publicly to 250 microseconds and of course, the time taken by the program to get the market data and decide to send an order, which is written by the trader, may affect this 250 microseconds time. So why doesn’t everyone use R | Diamond API?

Just like using a machine that is close to the exchange may not noticeably affect the latency of an order when the decision to place the order rests with a trader (instead of with a program), the use of R | Diamond API may not provide a trader with a higher P&L. First, is the algorithm likely to generate a positive P&L? Second, is the performance of the trading algorithm sensitive to latency or a reduction in latency? Third, can the trading algorithm gets its market data and submit an order back to our infrastructure in a few microseconds? Fourth, can the cost of using R | Diamond API be offset consistently by the profits of the trading algorithm?

Unfortunately most traders cannot answer these questions until they run their programs that incorporate R | Diamond API. Consequently we insist that the trader first incorporate R | API+ into his program, run it, make observations about latency and transit times and P&L. Then, if through observation and an objective analysis of the data, it looks like the program would benefit from a reduction in latency, the trader should port his app to incorporate R | Diamond API (which is a very small effort) and use it for live trading.

Some costs associated with using programs that incorporate R | Diamond API (Diamond Programs):

  1. R | Diamond API has been designed for use with programs that have been developed using C++ on Linux. Programs developed in other languages or run on other operating systems may not benefit from R | Diamond API.
  2. Diamond Programs must run on machines located in Rithmic’s Aurora data center configured and tuned by Rithmic to Rithmic’s specifications. These machines are generally rented from our affiliate, TheOmne.net, LLC and there is a cost for renting these machines (see http://www.theomne.net/dedicated-servers/).
  3. Diamond Programs must be launched as specified by Rithmic.
  4. The FCM/broker may charge fees for using R | Diamond API different from the fees it regularly charges to use Rithmic’s software and the FCM/broker may charge fees for the use of a private session with the exchange.

I realize that this answer is longer than may have been expected but I thought it would be good to provide a comprehensive answer.

jjw


#3

Thank you so much for the comprehensive answer. So it sounds like the fastest option would be the R | Diamond API with a dedicated server using C++. I may or may not need the fastest option, but this is very helpful to know.

My use case is really centered around the ability to read and react to each price level in real time. So while perhaps other options would suffice from an execution standpoint, my main bottle neck in the past was always with getting the data feed in real time. Would you be able to comment on if I could achieve the following fill in this scenario:

I am looking to buy a bid contract and get filled at exactly 200.25.

The price level sequence is as follows:

Bid
199.75
200.00
200.25
200.00
199.75
200.00

The exchange prints the same time stamp on every price level shown above. This implies this entire sequence occurred within 1 millisecond. (Or at least a time interval shorter than the next printed time stamp after this). I see very often 5, 10, 15 price levels of different values with the same time stamp down to the millisecond.

In this example there was exactly one opportunity to jump in and buy the bid at 200.25. Everyone that placed an order at this price level would have gotten filled because the market ultimately traded through it. So this is not a question of queue optimization, or guessing who would have gotten filled. We know every participant that was in the queue at 200.25 got filled. But to be able to place an order to this price level, one would have needed to receive and read the level 1 data feed price levels, then release the order to the exchange.

From the information you provided, one quarter of millisecond sounds like it would be fast enough to cover this use case. But could you speak to the time it would take to read and parse the level 1 feed? Assume the algorithm was optimized for performance, and wasn’t being bogged down by extraneous code in the hot path. Is it reasonable to assume that one could parse the data out, and place and order like in the scenario described above?

Thanks,

Ian


#4

If I understand you correctly in the example above (let me know if I do not) then you are looking to join the bid at 200.25. I am not sure what the table above indicates.

There are many factors that influence your processing time and performance. Too many to provide you with a definitive answer in this conversation. However, with a computer that has a 4 core 3 GHz CPU and plenty of 2400 MHz memory and is only running your program you should be able to keep up with most of the market data most of the time. If write most and most because there are occasions when there is so much market data published and if you happen to be getting it all on some smaller machines, you will not be able to keep current. We have seen this happen with market data for GE contracts from time to time.

But the real issue is : can you keep current with the incoming market data and place an order to join a price on or near the best price before the market trades through it?

Most of the time yes, Sometimes no, not possible. Even if you have the world’s fastest machine with unlimited processing power and throughput, orders may be filled at the exchange but their execution reports and their corresponding market data may not leave the exchange for more than 10 milliseconds. During that period, the activity of the market can trade through your anticipated price.

You can see this in R | Trader, R | Trader Pro and in R | API+. Each market data message we publish contains 3 timestamps: the exchange’s timestamp (which for trades generally corresponds to the time the trade occurred (the time when orders were matched)), the time just before the messages was published (we call this the JOP timestamp - Jumping Off Point) and the time we received the message. Rithmic publishes timestamps granular to the microsecond or better.

During planned news events (non-farm payroll, oil inventories, etc.) when the actual numbers released are significantly different from what the market had expected, I have noticed the time between the exchange’s time and the JOP time to be as much as 14 milliseconds. That means that the data about a trade sat at the exchange for as much as 14 milliseconds before it was released to the pubic. A lot can happen in 14 milliseconds. By the time you get the info, the best price may be far different from what you thought.


#5

Hi, Thanks for your detailed reply. I think you fielded my question fairly well. All I am looking for is the ability to join the best bid / best ask queue in real time and if the price trades through it, I would get filled as well. I take from your reply that this would be realistic to achieve in most of the cases. (And I am sure that this assumes C++ running the diamond API with fairly optimized code). I will be working on porting some code over the Rithmic API in the next few months and once I am ready I will try to give it a go.

Thanks,

Ian


#6

I think you will find reasonable success with R | API+. If you find that you are late to the party, so to speak, build some statistics showing that and the various times of the market data that caused you to submit an order. From these stats you should be able to see if R | Diamond API will be helpful.


#7

@Rithmic Thank you for all the support and the elaborate explanations.

Matt Z
Optimus Futures
www.optimusfutures.com