High Frequency Trading Adventures with Rithmic's R API - futures io
futures io



High Frequency Trading Adventures with Rithmic's R API


Discussion in Trading Journals

Updated
    1. trending_up 166 views
    2. thumb_up 9 thanks given
    3. group 3 followers
    1. forum 1 posts
    2. attach_file 1 attachments




Welcome to futures io: the largest futures trading community on the planet, with well over 150,000 members
  • Genuine reviews from real traders, not fake reviews from stealth vendors
  • Quality education from leading professional traders
  • We are a friendly, helpful, and positive community
  • We do not tolerate rude behavior, trolling, or vendors advertising in posts
  • We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community.  It's free and simple.

-- Big Mike, Site Administrator

(If you already have an account, login at the top of the page)

 
Search this Thread
 

High Frequency Trading Adventures with Rithmic's R API

(login for full post details)
  #1 (permalink)
 iantg 
charlotte nc
 
Experience: Advanced
Platform: My Own System
Broker: Optimus
Trading: Emini (ES, YM, NQ, ect.)
 
Posts: 403 since Jan 2015
Thanks: 83 given, 1,121 received

INTRO / BACKSTORY
This will be a technical Journal dedicated to sharing and discussing some of the technical details behind a trading system I developed with the R|API class library. I would have killed to have found some resources for this back when I started, so I am sharing a few things for anyone else looking to get into this type of thing.

I am still working out some bugs and optimizations, but it's up and running. I'd love to have a second set of eyes on some of the technical stuff, hence the main reason I am sharing.

First: Here is some information from Rithmic on their R|API: https://yyy3.rithmic.com/?page_id=9

Basically this is a class library that you can use to build your own trading system, and do pretty much anything you would like. Why would anyone do this? The main use case is speed. By cutting out all the bloat of charts, plug-ins, Dom's, etc. and keeping the code to a minimum, you can achieve speeds far beyond the reach of any retail software. Combined this with Rithmic's colocation in Arora, and certain types of high frequency trading are possible.

For my strategy I need low latency, but not ultra low latency. I have been working Rithmic and Matt and Jake at Optimus for a few months to get everything up and running.

I am in the very late stages of fine tuning some of the performance aspects of the system, so I figured I would put some stuff out here and see what people think. With that out of the way, let's get into it!

PART 1: MULTI-THREADING

Rithmic's API has a lot of events that can run concurrently. So any bottle neck in one place can cause a bottle neck in another if you are on a single thread. So to this end I came up with the following high level design.




Basically we have two main feeds that run between the application and the exchange.

1. The main data feed that provides bid / ask price updates
2. The main messaging feed that provides order state changes: (Fills, Cancels, etc.)

Each of these feeds need to run with nearly 100% up time, so the calculation intensive work is pawned off on threads in the thread pool.

*** The first point where I am conflicted is with respect to the order routing. My current design has a small but simple Alpha signal detector that picks up either true or false right after new prices come in. From here, I stay on the main thread and send out orders and cancel any unwanted orders. My thinking is that in terms of speed / performance, there is little to nothing that matters more than how fast I can get my orders out the door, so I should in theory stay on the main thread. But the counter argument is that by running anything on the main thread other than the feeds, I can bottle necking future feed events from registering as quickly as possible.

This will be the first topic I punt for discussion.

My next post I will get into the code a little.

Ian

In the analytical world there is no such thing as art, there is only the science you know and the science you don't know. Characterizing the science you don't know as "art" is a fools game.
Visit my futures io Trade Journal Started this thread Reply With Quote
The following 5 users say Thank You to iantg for this post:

Can you help answer these questions
from other members on futures io?
Tick Data Group Buy
Emini and Emicro Index
Help with Scale In ATM strategy
NinjaTrader
value chart indicator by sim22
NinjaTrader
Simpler Trading - Squeeze Pro indicator
Platforms and Indicators
mahDualCandlePattern
NinjaTrader
 
Best Threads (Most Thanked)
in the last 7 days on futures io
Spoo-nalysis ES e-mini futures S&P 500
97 thanks
Most Funding Firms are a Scam
65 thanks
Hedging NQ and MNQ 1-10...
13 thanks
Trading Plan
9 thanks
How many day traders are profitable?
8 thanks
 
(login for full post details)
  #2 (permalink)
 iantg 
charlotte nc
 
Experience: Advanced
Platform: My Own System
Broker: Optimus
Trading: Emini (ES, YM, NQ, ect.)
 
Posts: 403 since Jan 2015
Thanks: 83 given, 1,121 received

CODE BASICS

To start off here is how the main data feed works: (Basically there are 2 things I care about from the bid and ask feeds, the price and the time.
I collect the data and send it to a task method that stays on the main thread for a few lines, then hops onto a thread in the thread pool to process the rest...

public override void BestAskQuote(AskInfo oInfo)
{
Bid = oInfo.Price +-.25;
Ask =oInfo.Price;
TimeStamp =oInfo.Ssboe;
MicroSeconds = oInfo.Usecs;

Task1(Bid,Ask,TimeStamp,MicroSeconds);
}

public override void BestAskQuote(AskInfo oInfo)
{
Bid = oInfo.Price;
Ask =oInfo.Price +.25;
TimeStamp =oInfo.Ssboe;
MicroSeconds = oInfo.Usecs;

Task1(Bid,Ask,TimeStamp,MicroSeconds);
}


public static void Task1(double Bid, double Ask, double PT, double SL, int TimeStamp, int MicroSeconds)
{
// If the Buy Alpha signal is true, jump into the Main method and place a buy order
if (Alpha_L == true)
{
Program.Main(new String[] { "B"});
}
// If the Sell Alpha signal is true, jump into the Main method and place a sell order
if (Alpha_S == true)
{
Program.Main(new String[] { "S"});
}
// Now hop of the main thread and continue processing more complex things. I have two tasks queued up, if one is currently running I will use the other.

if (!PTTask1_L.IsCompleted)
{
if (PTTask2_L.IsCompleted)
{
PTTask2_L = Task.Run(() =>
{
MCB.PT_Hit_L("P2", Bid, Ask, PT + PTadj, PT + -SLadj, Count_L, LEF_MIN, LS, PT, SL, TimeStamp, NanoTime, nowEvent, askcount, Min2);
});
}
}
else
{
PTTask1_L = Task.Run(() =>
{
MCB.PT_Hit_L("P1", Bid, Ask, PT + PTadj, PT + -SLadj, Count_L, LEF_MIN, LS, PT, SL, TimeStamp, NanoTime, nowEvent, askcount, Min2);
});
}

}


TOPIC: CONCURRENT TASKS
This next topic is also an area where I don't know if I am fully optimized or not. There are 3 approaches to handling tasks, they each have some cons.

1. Option 1. Use one predefined task only: This will make it easy to follow the lineage of your code, and avoid any possible duplicate events, but if the task is already in use when it gets called, you will either be too late, or if you force the application to wait for the task to complete, you are introducing latency into your code that can be avoided by other approaches.

2. Task.Run(() => with no predefined task: This will get rid of any potential bottle necks from waiting on a task, but if you hit this block of code over and over by mistake, you will just queue up task after task and potentially end up with duplicates and have no good lineage to trace back from. For initial debugging I decided this was a bad approach, and haven't really pivoted back to this.

3. Create two tasks, and default to run Task1, but if Task1 is busy, then run Task2. From what I have seen Task1 usually get's called 95% of the time. For now, this is the approach I have been going with. It does add a few extra lines of code and require some extra steps to kick things off, but I can trace the lineage anytime I need, and avoid endless duplicates in case something goes wrong.

I have a section of my code that fires every named task during the start up so that the default state of every task will have a value and not be null, so I don't have to add lines to do a null check before looking into their state.


I"ll put up some more stuff as I can think of it, but if anyone wants to see anything specific or has any questions or insights please feel free to respond.

Ian

In the analytical world there is no such thing as art, there is only the science you know and the science you don't know. Characterizing the science you don't know as "art" is a fools game.
Visit my futures io Trade Journal Started this thread Reply With Quote
The following 4 users say Thank You to iantg for this post:


futures io Trading Community Trading Journals > High Frequency Trading Adventures with Rithmic's R API


Last Updated on May 5, 2022


Upcoming Webinars and Events
 

NinjaTrader Indicator Challenge!

Ongoing
     



Copyright © 2022 by futures io, s.a., Av Ricardo J. Alfaro, Century Tower, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada), info@futures.io
All information is for educational use only and is not investment advice.
There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
no new posts