Support Board
Date/Time: Mon, 25 Nov 2024 18:26:59 +0000
Post From: Sub-instance vs standalone folder installation
| [2024-02-15 23:05:01] |
| joshtrader - Posts: 488 |
|
Rui, after giving it some thought, I've decided to just use Denali for both instances. The DOM responsiveness is great with Rithmic, but there are two problems: (1) having yet another (3rd) instance of SC to just host one DOM means I can't quickly recenter my DOMs which I do all day long. I have ES, NQ, and YM side by side (used to have others too) and being able to recenter all is a big part of my workflow. I guess an autohotkey script could do this but it's just one more piece that must be in place for core functionality and not something I want to have to worry about. (2) even with only ES and only one DOM in an instance, at the close today I noted about 3 seconds of delay. This is not a huge deal because I would never trade the close like this, but I know that the same thing could happen during NFP or CPI or FOMC and I just don't want to have to worry about even the possibility that my data feed is lagging by more than a second or so. To be clear, I think the issue here is that SC cannot process the huge flood of data from Rithmic. But when using Denali+Rithmic, my understanding is that the Rithmic connection is only used for execution, not data, so, when an order is placed with Rithmic in this case, it does not matter that SC would be behind processing Rithmic data, because there are no market data updates from Rithmic. I have not noticed any trade execution issues with my current Denali+Rithmic setup. Previously when using only Rithmic during volatility I would sometimes see that with the market at X, I would place a bid at X+4 ticks or so, but it would not fill because the market was already higher, yet the lagging data processing made it appear that the market was lower. So, even though Denali is not as snappy and does not update as frequently, at least it does not fall behind for me, which is most important. So, my plan now is currently to just use Denali on one instance for charts, and Denali+Rithmic on the other for execution, and it will have to be just good enough for now. One change I made (which would not be make sense given my hypothesis that it's the processing of the data, not the updating of the DOMs, which causes the delay) was on the NQ DOM which I may change back now that I'm going to Denali+Rithmic. Previously I aggregated NQ to 0.50 ticks to avoid showing the quarter ticks, and also aggregated depth levels to show a single depth per 0.50. I can imagine that with numerous depth updates in NQ, even with a smart algorithm, it's still at least a few hundred/thousand more instructions and can't help. So, I changed this back to the default 0.25. But since I'm going back to Denali, I think I'll make it how it's better for me trading, which is 0.50. I remember in past years, like, 10+ years ago, that the DOM was always responsive and snappy like it usually is with Rithmic data today. I think one difference today is likely that the number of market data messages has simply gone higher, so during the open/close/volatility, SC has so many more messages to process, and we get the lag. I have previously worked on low latency data feeds and from an engineering perspective, it is not easy to reduce the latency, and depending on the delivery mechanism (in this case the Rithmic API) it may be impossible to split the data in a way that makes it faster. The only thing I can think to try is a 3rd party data feed like IQFeed to see if the updates are snappier than Denali, but I suspect we'd run into the same issue, which is that if the updates are very frequent, SC simply won't be able to deliver the updates without lag. At any rate, I'm going to shift focus on good trading and try to leave the tech part behind for now :) Date Time Of Last Edit: 2024-02-15 23:22:33
|