NexusFi: Find Your Edge


Home Menu

 





High Frequency Trading Adventures with Rithmic's R API


Discussion in Trading Journals

Updated
    1. trending_up 1,413 views
    2. thumb_up 11 thanks given
    3. group 4 followers
    1. forum 2 posts
    2. attach_file 1 attachments




 
Search this Thread

High Frequency Trading Adventures with Rithmic's R API

  #1 (permalink)
 iantg 
charlotte nc
 
Experience: Advanced
Platform: My Own System
Broker: Optimus
Trading: Emini (ES, YM, NQ, ect.)
Posts: 408 since Jan 2015
Thanks Given: 90
Thanks Received: 1,147

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 NexusFi Trade Journal Started this thread Reply With Quote

Can you help answer these questions
from other members on NexusFi?
NexusFi Journal Challenge - April 2024
Feedback and Announcements
ZombieSqueeze
Platforms and Indicators
The space time continuum and the dynamics of a financial …
Emini and Emicro Index
Better Renko Gaps
The Elite Circle
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
 
Best Threads (Most Thanked)
in the last 7 days on NexusFi
Get funded firms 2023/2024 - Any recommendations or word …
61 thanks
Funded Trader platforms
39 thanks
NexusFi site changelog and issues/problem reporting
26 thanks
Battlestations: Show us your trading desks!
26 thanks
The Program
18 thanks
  #2 (permalink)
 iantg 
charlotte nc
 
Experience: Advanced
Platform: My Own System
Broker: Optimus
Trading: Emini (ES, YM, NQ, ect.)
Posts: 408 since Jan 2015
Thanks Given: 90
Thanks Received: 1,147

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 NexusFi Trade Journal Started this thread Reply With Quote
Thanked by:
  #3 (permalink)
imadaitelarabi
Morocco Marrakech
 
Posts: 1 since Aug 2022
Thanks Given: 0
Thanks Received: 0


Hello I am Imad , a Trader who is interested in algorithmic trading.

I read your post about Rithmic API! and i am interesting to know some information about Rithmic System and how HFT trading is working on it!

So basically if you use this Rithmic API , do you will still be affected with slippage?


I have a strategy which is working with stop orders for entries and trailing stops , can that be coded and run with R API ?

Thank you , waiting for your reply my freind

Reply With Quote




Last Updated on August 16, 2022


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
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.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts