How fast are the various Rithmic Configuration Options?

Futures Trading Platforms Rithmic Trader (R | Trader) and RAPI
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 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

4 Likes
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

1 Like
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.

1 Like
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

1 Like
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.

1 Like
7

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

Matt Z
Optimus Futures

8

Hi Ian, I followed your conversations at this forum with high interrest. As the latency from my EU country is terrible I’m also trying to find a way to fight slipage as good as possible (within budget) for my algo trading. Could you get your bot running or did you struggle too much with technical issues?

Chris

9

Hi @sonaht,

Thanks for your post and welcome to the Optimus Community!

In my opinion, it’s very likely that the physical distance between you and Rithmic’s default gateways is negatively impacting your connection. In regards to latency, while connected to Rithmic, there are several gateways located in Europe and the surrounding areas that may improve your experience.

Rithmic has gateways located in Europe and Frankfurt that may improve the latency issues you are having. Here are a list of gateways that RIthmic supports when connected to Rithmic 01 live servers:

image

Other alternatives you can consider are obtaining a VPS located in Chicago or co-locating a server in the Chicago area as well. Having a VPS or a co-located server that is located as close to the exchange as possible along with Rithmic servers could potentially reduce the time it takes for your orders to be executed and improve your latency issues.

I hope this helps!
Thanks,
Jake
Optimus Futures Support

1 Like
10

Hi Jake,

thanks for your input.

Indeed I got inspired by this forum to run my program directly on a co-located server in Aurora data center receiving data feeds via the R | API. I would like to point out, that I’m not using the R|API nor receiving Rithmic data feeds yet. So far I have implemented a bunch of Metatrader Experts Advisors (Bots) that run on VPS close to the brokers location but I’m still not happy with delayed CME Market data, restricted order book access and other issues.

Currently I’m playing around with the trial version of R-Trader and the latency seem to be much better, even under bad conditions caused by my location. Thus, I am playing with the thought to port my program to Aurora and receiving data via the R | API directly. Another point is, I don’t need an UI at all but almost every retail broker forces me to use one.

In a first step the purpose is not to be profitable, but to study, explore some opportunities and test some stratgies that worked out good under ideal conditions. Let me provide one example, so maybe you can share your experience if this is realistic from a technological point of view or if I’m a too naive:

One study goal could be to find good entries when trading Index-CFDs via an OTC Broker located in Europe. It is reasonable to ask:

“Why using an OTC Brokers where you potentially have high spreads and high slippage, especially when this broker is not close to your VPS?”

There are two reasons. The first is risk-management: CFDs allow me to experiement with very low volume. Second, market makers can potentially offer better prices than the underlying future market. Index CFDs and the underlying index future are strongly correlated. Market makers located in Europe or other locations need time to receive index data from the CME and compute their spreads. Let’s say the correlated future market moves up very fast, I should be able to respond fast and send my limit orders to the OTC broker hoping I can get filled at their current spread level.

To realize this experiment I have the following requirements:

  • A good located VPS to receive market data early (Aurora DTC)
  • A light weight API (No UI) to respond to market movements early (R | API)
  • A third party plattform running on the VPS like Metatrader or CTrader to send automated limit Orders to he OTC Broker (requires corresponding permissions on the server).
  • Interprocess communication between R | API and the 3rd Party Plattform. (Access to Win32.dll library)
  • Outgoing communication. Eg. Ports like 443 must not be blocked by the firewall.

Would this setup be possible with the Ominet VPS Configuration 2?

Before renting a VPS, I need to dive into the R|API first and get the data feed running. I could not find much info about the API yet but if I get it right, it is possible play around with a trial version of the API when I send an request E-Mail with my data. For now, my requirements on the API are very low. I only need a connection and latest Bid data (maybe also some level 2 data). The rest will be handled by plain C++ or third party bots. I hope the API is well documented and easy things are easy to realize. Even if the support here seems to be very good , I don’t want to bother you guys with pulling information too much.

Thanks in advance

Chris

11

@sonaht, it’s important for us to clarify that we cannot provide insights or commentary on Contract for Differences (CFDs) as they are not supported by our platform and are, in fact, deemed illegal within the USA and certain regions of Europe. Your inquiry seems to pertain to arbitrage, which often demands a level of latency unavailable to retail traders.

We must stress that we’ve encountered numerous instances where traders have been abruptly expelled from CFD brokerages for utilizing such strategies. CFDs function on a broker’s quote rather than a centralized exchange, making them inherently risky and opaque.

In line with our ethical commitment to responsible trading, we highly recommend focusing on exchange-traded products. Though these may present their own challenges, they are generally considered a more transparent and reliable trading mechanism. In our opinion, this approach aligns more closely with best practices and professional trading standards. Your success and safety in the trading market is our primary concern

Best,
Matt Z
Optimus Futures

There is a substantial risk of loss in futures trading. Past performance is not indicative of future results.

12

Hi Matt,

thanks for your response. I’m sorry if I expressed myself to complicated. I totaly agree with your points about CFD trading. I’m aware that many successfull trades got cancelled under the pretext of “abusive trading” , even when market makers and institutions use the same techniques and call it “bringing liquidity to the market”. I would like to state out that I need a VPS and a quick CME data feed API for for research purposes only and I’m willing to pay for it. Research is not about beeing a successful trader. I hope there is nothing unethical to study and observe the market and their participants as this is also done by larger institutions and you won’t find this information in any book. I brought up the CFD topic as one of many potential case studies to explain the special techniqual requirements to the server (Permissions to install apps, win32.dll access, open ports… etc. ). So my questions were primarily directed to server restrictions. I would like to emphasize that this doesn’t mean, that I don’t want to deal with exchange traded products or rate them bad. For serious investments ( not for research) exchange traded products are my first choice.

Thanks

Chris

13

We strongly urge traders to conduct comprehensive research on market behavior, trends, and risk management strategies. However, please note that we are unable to provide access to Rithmic API unless you are an existing customer, as we are not engaged in the business of data vending.

Best,
Matt Z
Optimus Futures

15

I can understand. I thought I can drop some question regarding rithmic technologie and exchange experience here. I also have no issues with opening an live account.

16

Hi Sonaht, I can share a few technical notes with you as I was the one that originally opened the thread and have been using RAPI for quite some time now. The API is pretty straight forward, but you will need to be fairly comfortable with development in general to make good use of it. There is a pretty major gap between getting it up and running and fully optimized. The API has basically a single thread that you can program on, and if you go the single thread route, any I/O stuff will completely bottleneck you. So you will do best going with a a multi-threaded architecture using queues with something like a consumer /producer model. This will keep your I/O and other processing insensitive stuff off your main thread and let your main data feed fly. C# vs. C++ won’t matter as much as this, and you will still hit bottle necks with the feed itself when the market gets too hot. Outside of going multi-threaded, any other optimizations will be sparing nano-seconds, and your main choke point will be the data feed coming over a 1 gig port. Sometimes, you will be within 1 ms (local timestamp in microseconds vs. the exchange timestamp in microseconds), but sometimes this delta will grow to 5 or even 10 milliseconds. It’s not your code or architecture, but the data feed itself being too much, too fast to process in real time. This is what I am trying to solve at the moment. Best luck! Ian

1 Like