Login Page - Create Account

Support Board


Date/Time: Fri, 03 May 2024 13:10:20 +0000



[User Discussion] - Execution architecture questions

View Count: 738

[2021-02-19 23:56:49]
User5044343 - Posts: 67
I'm looking for feedback on what would be the ideal way to integrate signals into Sierra.

There is a system that generates signals every second. They are not HFT - a few hundred ms delay is fine.

Would like to see these signals on a chart + have Sierra route them for execution. There are also "levels" that would be needed to be shown in Sierra as well.

As I understand it a study could be created to pull in these signals and view them.
Question 1: Does the study need to poll for this data ( from a db, url, file ) or can it be pushed to Sierra say via a websocket?

Question 2: Would it be better to create a fake "instrument" and stream data to a DTC server ? Would prefer to stream vs constant polling for delay/performance reasons.

Question 3: Should the signal viewing, and execution of trades based on signals be separated ? Execute the trades by submitting orders via websockets to the DTC Server vs a study that reads signals and fires off buy/sell signals.

Question 4: If a study is used for trade execution based off of signals would that mean a strategy can be backtested in Sierra?
[2021-02-20 06:35:53]
Flipper_2 - Posts: 57
I've used zmq in a request/reply pattern to get signals from an outside programs into a study. Works fine, have had round trip times around 20-60 ms and most of that was delay from the other end.

All reasonably simple to put them in a study and then make a trading system off them without having to deal with DTC server or a hand coded websocket.

If a few 250-500 ms is of no bother you can just read a txt/csv file every chart recalculation.
Date Time Of Last Edit: 2021-02-20 06:37:51
[2021-02-20 16:22:01]
User5044343 - Posts: 67
Anyone here willing to code the above but maybe use influxdb or mysql as the signal source ?
[2021-02-21 07:51:29]
Flipper_2 - Posts: 57
If you are using something like mysql you wouldn't use any approach you have listed in the first post. You would just use the C++ api as Studies are coded in C+,

https://dev.mysql.com/doc/connector-cpp/8.0/en/connector-cpp-introduction.html

With that said what is writing to mysql? and is it actually needed to be save to a database or would a flat file structure be easier? Is it on the local machine or remote server? because the mere mention of mysql brings on cold sweats.
[2021-02-21 10:24:57]
norvik_ - Posts: 106
In fact any db or file is a passive thing. Maybe at first you will need a data source or parser?
[2021-02-21 16:23:33]
bradh - Posts: 854
Question 4: If a study is used for trade execution based off of signals would that mean a strategy can be backtested in Sierra?

Maybe. If the external signal data can be replayed from a specific date/time then you should be OK. Otherwise, I don't think so.
[2021-02-22 02:42:33]
User5044343 - Posts: 67
The signals are generated and then stored to a file and influxdb.

They can be streamed to other places as well (message queue, mysql, etc).


I can have them in a file on the local machine if it makes it easier.

Signals are every second, but I would like to see them on a tick chart and on a longer time frame chart (1m, 5m, etc). I can have them aggregated as a seperate signal if needed, but I would need to see them intra-bar, no6 after the time interval closes.

Signals in influxdb and the file are stamped, so replay isn't an issue. Exchange timestamps are used from tick data so there no time syncing issues later.


Im happy to pay someone to get on a call to go over what the possibilities are, as that is my biggest gap right now to understand how Sierra can read, store these signals.

Ideally I would push them into Sierra's internal db and then it would get handles by Sierra.

Other ideal situation is I connect as a DTC server and have Sierra fetch whenever it needs to for historical, and serve realtime signals with no delays. But the only way I'm aware that would work is if I pretended the signals are seperate instruments.

Ideal = no delay betwen when the signal is produced to when it shows up in Sierra.


There are different models producting these signals so it complicates it a bit.

Happy to answer more questions to better explain what I'm trying to accomplish and with what.

I have done some basic order execution via DTC and based on order management issues via ASCIL it may be easier for me to do it externally ( moving stops trails, attaching OCOs based on other signals, going flat baed on other external signals)

To post a message in this thread, you need to log in with your Sierra Chart account:

Login

Login Page - Create Account