Help Center Blog Open An Account

How fast are the various Rithmic Configuration Options?


I have a HFT strategy that I am planning to test soon, and I am looking into the various options here from rithmic:

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.



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,, LLC and there is a cost for renting these machines (see
  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.



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:


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?